I am novice on Android application development, slowly starting to understand the architecture. I particularly like that communication between applications and data storage are resource centric. But anyway…
If you have been developing mobile applications for Android you have most likely seen some exceptions in the Eclipse debugger that you don’t understand, maybe not the tiniest bit. This mostly has to do with lack of experience with the API combined with the strict way that Android sets up views and restricts which threads that are allowed to draw and control the views, along with other concurrency issues.
Starting up your application in the emulated Android environment is not the fastest thing to do, so how can you debug your applications in a little more snappier way? – In short, I really don’t know.
What I want is a sane error message with a stack trace of my application code, but since I can’t get that, I have to debug my application in other ways.
Break points
By setting a breakpoint in your code on places where you think the bug might exist, you can step through your source code until the application fails.
The cons of this are that it is time consuming to do all the manual step by step operations, it’s a boring way of debugging and the exception message you get might not be understandable to you.
Logging
The Android API provides a Log class that can be used to log messages and exceptions. It took me some time to figure out how to read the log messages, but the Android Eclipse plugin provides a LogCat view.
To show the LogCat view in Eclipse, you go to “Window”, “Show View”, “Other …”, expand the “Android” category and then open the “LogCat” view.
Example output from the LogCat view.
01-09 16:56:52.069: ERROR/Listings(1064): Failed to get trip listings
01-09 16:56:52.069: ERROR/Listings(1064): java.lang.RuntimeException: Example of exception logging
01-09 16:56:52.069: ERROR/Listings(1064): at no.ut.trip.Listings$ProgressThread.run(Listings.java:112)
The example above shows an error message on the first line, the exception class and message on the second line, with the stack trace on the following lines. Might be helpful.