Snazzy git blaming

Sometimes, you can't help it. You need to look at what happened in the past to understand what is happening in the present (wow).

If you know the specific line you are interested in, showing history for selection is the way to go.

Change can be confusing. Filter history to actual piece of code you're interested in. #AndroidDev pic.twitter.com/nd27tgv20f

— Zarah Dominguez (@zarahjutz) July 28, 2015

However, if you want to look at how the file has changed over time, showing annotations (the nice way of saying git blame) might help you. To enable it, right click the gutter then choose Annotations.

From here, you have a ton of options on how you want to display the summary in the Annotations gutter. It's always fun to see which line has been there since the beginning of time.

** Source code is Roman Nurik's Muzei that we forked for an Innovation Day project last year.

The most recent version of the file is marked with an asterisk, like so:

Hovering over an annotation will show the full commit information, including the commit message.

 And clicking on it will open a list of the paths affected by this particular revision.

Look at all those options at the top of the dialog! Have a play and enjoy diff-ing!

In which I was in a podcast

It has been a month since IO and in case you missed it, I got to chat with Kaushik of Fragmented. And by golly, I made it into an episode! At that point I was about to lose my voice, so I sound really husky. :p

There are some big names in the episode I am in (I still have no idea why I'm there, but I'll take it!), so please give it a listen!

PS: I travelled quite a bit after IO, but I did start a draft of my recap. I hope it sees the light of day eventually!

More Watches Love and a note on Context

I have previously written about debugging and how Watches can help make inspecting things in your code easier. Today, I would like to reiterate how powerful Watches can be.

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 Logs or Timbers or 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 getRandomSublist() in 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!