Debugger & Tools

« Prev Next »

Logging (previous lesson) shows what already happened. The debugger shows what is happening right now — pausing a running RecipeBox app mid-execution so its variables, call stack, and state can be inspected directly, without adding a single log line.

Breakpoints

Clicking the gutter next to a line number in Android Studio sets a breakpoint. When the app (running in debug mode) reaches that line, execution pauses and the Debug tool window opens with the current call stack and variable values.

public void saveRecipe(Recipe recipe) {
    if (recipe.title == null || recipe.title.isEmpty()) {
        // breakpoint set on the next line to inspect "recipe" here
        throw new IllegalArgumentException("Recipe title required");
    }
    recipeDao.insert(recipe);
}

Explanation: With a breakpoint on the throw line, the debugger pauses exactly when a bad Recipe reaches this method, and the Variables pane shows every field of recipe — including which one is actually null or empty — without guessing from a stack trace alone.

Stepping Through Code

Action	What it does
Step Over	Runs the current line, without entering method calls it makes
Step Into	Jumps inside the method call on the current line
Step Out	Finishes the current method and returns to its caller
Resume Program	Continues running until the next breakpoint (or the app finishes)

Watches and Conditional Breakpoints

A Watch is an expression pinned in the Debug window that re-evaluates every time execution pauses — useful for tracking a value (like recipeDao.getCount()) across several steps without retyping it each time.

A conditional breakpoint only pauses when an expression is true — right-click a breakpoint and add a condition, so it doesn't stop on every iteration of a loop over dozens of recipes.

for (Recipe recipe : allRecipes) {
    // conditional breakpoint here: recipe.category.equals("Dessert")
    processRecipe(recipe);
}

Explanation: Instead of pausing on every one of a hundred recipes and clicking Resume repeatedly, the condition recipe.category.equals("Dessert") makes the debugger stop only when it actually reaches a dessert recipe.

Filtering Logcat While Debugging

The Logcat tag/level/process filters covered in the previous lesson work the same way while a debug session is attached — it's common to keep Logcat open in a split view alongside the Debug window, reading log context around the exact line a breakpoint paused on.

Layout Inspector

The Layout Inspector attaches to a running app and shows a live snapshot of its view hierarchy — every View on screen, its exact bounds, and its attribute values (padding, visibility, text) — which is far faster than reading XML and guessing why RecipeBox's recipe title TextView is being clipped or overlapped.

A 3D "exploded" view of the layers is also available, which is particularly useful for finding an unexpectedly overlapping view buried underneath another one.

Database Inspector

The Database Inspector tool window connects to a running app's SQLite database — including the tables Room generates for RecipeBox's Recipe entity — and lets you browse rows, run ad-hoc SQL queries, and even edit values live, all without pulling the database file off the device manually.

-- Typed directly into the Database Inspector's query box
SELECT id, title, category FROM recipe WHERE prepMinutes < 15;

Explanation: This is a genuine advantage over print-debugging a query result: the inspector shows the live table exactly as Room persisted it, so a wrong category value or a missing row is visible immediately.

Profiler Tabs — Quick Overview

The Profiler window (CPU, Memory, Network, Energy tabs) records what a running app is doing over time rather than pausing it, which makes it the right tool for performance questions like "why does scrolling RecipeBox's recipe list stutter?" — covered in depth in the Profiling & Performance lesson later in this section. For now, it's enough to know the Profiler and the debugger solve different problems: the debugger answers "what is the state at this exact line," the Profiler answers "how is the app behaving over this span of time."

With breakpoints, the Layout Inspector, and the Database Inspector in hand, the next lesson moves to automated checks that catch bugs without a human stepping through code by hand: Unit Testing (JUnit & Mockito).

« Prev Next »