Archive for category debug

How to do Logging

I have been looking into the options available for remote logging. However, before I continue, I should mention local logging is done using log.

e.g. log.v(TAG, "This is a log message");

The TAG is a unique string for your app so you can differentiate it from all the other log messages. You view the log messages in the Eclipse LogCat screen. If it’s not already showing in your workspace then use Window… Show View… Other… Android … LogCat.

A problem with the Eclipse LogCat window is that once it receives too many log messages, they all scroll within a single line overwriting old ones. Also, the LogCat window is unreliable and sometimes shows nothing. Instead you can invoke

adb logcat

from the command line, while in the Android tools directory, that always works as expected.

Back to remote logging. This is logging by your testers when you don’t have direct access to the emulator or device and need logging sent to a  server.

Droddrop seems  the most capable remote logging currently available. There’s also remote stacktrace which does what it says… allows you to view exception information at a server. It can also be configured so that the server can also be your own if you don’t want to share your exceptions with the World.

There’s also an Android version of microlog that has been used available for years under Java ME. The Android version seems to be less capable and currently doesn’t do that much. However, there’s also a slightly more developer version at microlog4android.

Finally, if you need analytics as opposed to logging, you might like to take a look at Flurry.

Tracking Unhandled Exceptions Remotely

androidremotestacktraceNeed to track unhandled exceptions remotely? I came across android-remote-stacktrace today that, with the addition of a trace.jar file, gives you remote logging of unhandled exceptions together with a stacktrace. There’s also a php file that you can put on your server to receive the information and write it to a file.

The only problem I suppose is that end users might question why the application requires android.permission.INTERNET when the core application might not need to access the Internet. Nevertheless, I can see this being a great tool to use when people are testing your application.