Tips and tricks to hone your debugging skills
As an Android developer, there are days when we spend more time in the debugger than in the code editor. Here I have mentioned some of the best tips and tricks to debug and squash bugs much faster in Android Studio.
Adding Custom Log filter
We already know if we want to search for a particular log, but if we have to use that search filter regularly, Android studio provides the functionality to add a custom search filter. You can save a search filter from Edit Filter Configuration.
Then, add the details of your filter.
To reduce the log clutter, use the fold lines feature, which groups and collapses lines that are similar. Select the text from a log, right-click, and select Fold Lines Like This.
When the Console dialog box opens, click OK and similar messages containing the selected text are collapsed.
If you find that you have set a breakpoint at an inappropriate place, rather than clearing and resetting the breakpoint, you can drag it to the line you want to debug. This is useful because it preserves the settings on the breakpoint.
Trigger breakpoints based on conditions
Often we need to stop at a breakpoint when certain conditions are met. To set a conditional breakpoint, right-click on a breakpoint and add the condition. The condition can be any code expression that equates to a Boolean. When the code hits the line and if the expression is evaluated to true, the breakpoint activates. For example, here in the logic, the breakpoint will trigger when the value of i is 5.
Trigger breakpoints depending on previous breakpoints
If you want to debug a method/line of code that only happens along one particular path, then setting the breakpoints in the code can result in many unnecessary breaks. To avoid this, you can use dependent breakpoints, which trigger only after another specified breakpoint was hit. For example, you can create a breakpoint that is triggered only in the path you want and then use it as a dependency, so your other breakpoint only triggers in that path.
To set a dependent breakpoint, right-click on the second breakpoint and open the More menu. In Disable until hitting the following breakpoint, choose the breakpoint you want to depend on. You will notice a change in the breakpoint icon.
You can also use this feature where you have a conditional breakpoint elsewhere and want to avoid copying and pasting that condition to a new location.
Debugging on the go
Sometimes, rather than stopping at a breakpoint, you want to see some information associated with the app state. You might add
println to the code to accomplish this. As this approach requires a recompile, you can use the breakpoint itself to evaluate and log. To achieve this, in the breakpoint options disable Suspend and enable Evaluate and log.
You can add any code expression, and it will be evaluated and logged to the console. If you just want to quickly verify that your breakpoint was triggered, use the “Breakpoint hit” message to log that the breakpoint has been hit.
There is even a quick way to create this sort of breakpoint: just press the Shift key and click on the line number you want to debug.
While the Variables and Watches windows are useful to keep tabs on explicit values, you sometimes want to explore your code more freely, which is where the feature to evaluate expressions comes in. When you’re at a breakpoint, access this feature from Evaluate expression in the debugger toolbar.
In the Expression text input, enter any expression and press Evaluate to evaluate it. Moreover, after evaluation, you can browse the object in the Result section.
Drop Frame — The savior
Often while debugging, we accidentally step over a method instead of stepping into it, If you’re running Android 10 or higher, you can now backtrack by clicking Drop Frame in the debugger toolbar.
This feature pulls you out of the current method and puts you back to the point before it started, giving you a second opportunity to step into the method. It saves a lot of time.
Analyzing stack trace
When you receive bug reports, the reporter may have sent a copy of the exception’s stack trace. You can turn these into meaningful information in Android Studio using the Analyze menu, Analyze Stack Trace or Thread Dump.
You can paste your stack trace, or it can prefill it from the text present in your clipboard.
Likewise, you can see what is from your codebase (highlighted in blue) versus the code that you probably don’t need to pay attention to (highlighted in gray). And, you can click on the links to quickly jump through your codebase.
Thank you for reading, stay tuned for amazing articles!