When something fails in my code and I’m lucky, I would have a vague idea of what may be causing it. So I launch my app then attach the debugger (NO! to the green bug!); I am stopped at a breakpoint and while staring at the offending line, a “Wait, what if it’s this other thing that’s causing it?” pops into my head.
If you are used to debugging by peppering your code with
Toasts (and there’s nothing wrong with that!!), you would have to stop debugging, add the logs, and re-launch your app (thank God for Instant Run!).
However, we can leverage Watches to make this process a whole lot easier. While stopped at a breakpoint, just add a new Watch (⌘+N or click the + in the Watches pane) and start typing.
Let’s say for some reason I wanted to see what Intent extras, if any, had been passed into the current Activity. I just add a new Watch and put in the usual way of getting an Activity’s extras –
getIntent().getExtras() and now I can inspect what I have been given when this Activity was launched. Easy peasy.
Now in the IntelliJ documentation, there is a quote that says:
Watch expressions are always evaluated in the context of a stack frame that is currently inspected in the Frames pane.
Similar to the way “context” is defined in the real world (and in the Android world too, I guess) this means that Watches will only make sense if they are in used in the correct circumstance where it can be fully understood. Still confused?
Say I am now stopped at a breakpoint in a Fragment (The Frames pane says I am in the method
CheeseListFragment.java) and I would like to see the extras passed into this Fragment’s host Activity. The previously added Watch will not work since in our current context – that of a Fragment – there is no such method
getIntent(). To do what I want, I would need to call the Activity first –
getActivity().getIntent().getExtras()= null, there are no extras received!).
Pretty coooooool. I think in a sense, you can think of Watches as coding without actually coding. Happy debugging!