Coming from a Windows environment, specifically the .NET space, I’ve been used to a pretty easy and seamless debugging approach. If I’m working on some source code in the IDE and I want to debug it, I hook up some sort of executable aspect and press F5 and click things until I get to my breakpoint (let’s pretend I’m ignorant of unit tests, and concentrate on just getting a debugger to fire). So when I started dabbling with some Android development, you can imagine my surprise when pressing F9 did nothing (that sets a breakpoint in Visual Studio). You can further imagine my shock when pressing the Debug button in Eclipse ran my app but didn’t really let me, well, debug.
So here I am, all in a tizzy, unable to debug my android app, facing the proposition of having to do poor man’s debugging – namely, throwing up a message box at key points in the app to see what was going on. And then, I got a new perspective.
So one of the differences between Eclipse and Visual Studio is the concept of perspectives, defined as:
A perspective is a visual container for a set of views and editors (parts). These parts exist wholly within the perspective and are not shared. A perspective is also like a page within a book. It exists within a window along with any number of other perspectives and, like a page within a book, only one perspective is visible at any time.
And this was all that I was missing when it came to debugging Android apps. Let’s say we want to do some code spelunking in the ApiDemos Android demo app. We fire up Eclipse and do all the proper importing and what not. We then click the Debug option to debug the app in the emulator.
Our app fires up in the emulator in all of its glory. How, then, do we actually perform debug actions such as inspecting variable values and setting breakpoints? This is where the concept of Eclipse perspectives comes into play. Tucked away in the Window menu is a handy option called Open Perspective.
That’s right, there is a Debug option in that submenu. Clicking that reveals, well, a whole new perspective.
As you can see, there’s a lot of window action going on here. Let’s stay focused on our initial goal, which is simple debugging and breakpoints. You’ll notice in the middle of the IDE I have the Link.java file open. Let’s say I want to study this example so I can see how it works. I scroll down to the onCreate method in this class and set a breakpoint by double-clicking in the left margin on the line I want to break on.
And then I navigate to the Text –> Linkify menu option in the ApiDemos sample app.
The green line in the Link.java file shows where our execution is currently stopped. The selected tab in the top right portion of the IDE named Variables shows us the current local variables. Finally, you can see lots of yummy messages in the LogCat window at the bottom right, as well as the Console window in the bottom left.
That’s it – bare bones debugging of an Android application. And all it took, at least for me, was a slight change in perspective.