How do you debug successfully in Android?

Question

I understand there is the LogCat view to check the messages logged but I can't make sense of it.

When debugging (I use Java primarily) I've been accustomed to stepping over each line of code and finding out the exact point where the program crashes and then doing something about it.

How can I do this with Android development? Is there a way to precisely locate the line which is causing the application to crash?

I can't understand what to make of/how to read the LogCat messages and when I try to step over (using the F9 key or the 'Debug' option in Eclipse) it keeps opening new tabs for inbuilt classfiles (like Instrumentation.class etc) and after pressing F6 a few times over again the app crashes showing 'The application has stopped unexpectedly. Please try again'

Can someone tell me if there's something to be done in a way that I'm not doing here? Thanks!

Btw if it helps, here's the generated log: http://pastebin.com/EaqaWUdS

Answer 1

It is the same like in java. Basically you need the sources to open the java files instead the class files. Google shows you how to add the sources.

Basically you debug android while staying in your own classes. I barely look into the android classes as the most issues are, of course, located in my own classes.

So just debug like you already do but don't step into methods/classes you don't own unless you have the sources added to your sdk. Even if you have, there might be some classes that aren't open source, so you can't step into the sources there. (Basically all Google API classes)

Answer 2

You are using a resource id that doesn't exist at line : 93 of com.site.custom.ModAdapter.getView(CustomListProjectActivity.java

--EDIT : add explanations

You will read a logcat stack trace in the same way as you did in Java : read bottom up and the culprit is the last line of your classes (before the code gets into the android sdk code).

You can do it the other way around, and start from top, stopping at the first class of yours and discarding android classes.

The same reasoning applies when debugging : step into your methods if needed and step over all methods of the SDK unless you want to debug them (and usually you don't, if you really suspect a bug inside the SDK, check the source at grepcode to see the inner mechanics of the android sdk class you are interested in).

Sometimes it gets difficult to track bugs on android, especially for widget layout related bugs because you can only see the code that is executed by the android platform, no code of your is executed, only your data are read from an xml file for instance. If something breaks here, it can be harder to debug. In that case, apply the dichotomy method : remove half line, if the bug doesn't show up, then readd your lines, remove half of them, etc...