[Disclaimer: I wrote and published this on my phone whilst sat waiting in a café; if it reads a bit slapdash, it’s because it is! If you’re after a code rip, the snippets are in helpful little boxes. You’re welcome. :-P]

When working on projects that don’t have a set of “house rules” on logging, it is dangerously easy to be lazy.

I am also an advocate of making life easier for your future self; who hasn’t cursed “yesterday me when their groggy barely-conscious self is confronted with a tight morning schedule and a glowing fuel light? Amiright?

Um, ok… Well aside from arriving on time to appointments, creating good coding habits frees up brain bandwidth for creating cool new things, and produces the collateral benefit of reducing silly mistakes.

As a developer who specialises in object-oriented languages, I’ve been creating my own classes and libraries since I learnt how, back in my early Java days. In my opinion, objectifying code is an incredibly powerful productivity tool, and it worries me when I see beginner tutorials that don’t focus on this aspect; anyone can make a long class containing every function needed, and make it work, but in a production environment you’re doing it wrong! OO language compilers are optimised for object handling and memory clearing methods that favour small, granular components, not vast memory hog objects that are basically procedural.

Procedural is not the way that the world works. If you had a car that failed to start because the wing-mirror had broken off, it wouldn’t sell (in fact it wouldn’t even get through DFMEA analysis prior to a prototype build; I digress). Why then would you write a program that mixed UI functions (wing mirror) with network/data handling (ignition circuit)?!

In the same way that I like to use my favourite pencil when sketching (a Mitsubishi Kuru Toga propelling type, if you’re wondering), I have some little bits of code that I put into every Android app that I develop to make my life easier. It’s not quite boilerplate code, as it’s not part of a template, but a utility library that allows me to give my code consistency without bloat.

Consistent Logging

I know that a lot of people like to bring in external logging libraries to  their apps, indeed I’ve used Log4J a lot in larger pure Java projects, but a  lot of the popular frameworks don’t play nice with Android, and in some cases  (being designed for server-side/desktop applications) are detrimental to  responsiveness and battery life on a mobile device. So I prefer to use the  provided base classes and functions where possible. In fact, my logging function  is tiny.

When you’re logging in Android, you’d normally have something like this:

// This goes where you put your other class-scope declarations.
private static String LOG_TAG = "MyClassTag";

// This goes where you actually log stuff.
Log.i(LOG_TAG, "What I want to say.");

This leaves you wide open for laziness, as a helpful log entry like:

02-28 12:33:47.636: I/MyClassTag(988): Instantiating required variables for MyClass map component.

Rapidly deteriorates into:

02-28 12:33:47.636: I/MyClassTag(988): vars done

This is sloppy, but not technically a problem. However that sloppiness costs you time when you want to try something out quickly, or start to get tired and lose your eye for detail (~3am in my experience). Once you start  copying and pasting code around, you can end up with the wrong log tag appearing  in a class;  if you start to get two classes reporting identical tags, you’re in  for a really frustrating debugging session…

My solution, is this little function.

// This goes where you put your other class-scope declarations.
private String getLogTag(){
    this.mResources.getString(R.string.app_name);
    String log_tag_output = "";
    if (LOG_TAG!=null) log_tag_output = ":" + LOG_TAG;
    return this.mResources.getString(R.string.app_name) + log_tag_output;
}

// This goes where you actually log stuff.
Log.i(getLogTag(),"Stuff you want to say.");

Rather than being a dumb variable, ripe for a fat-fingering, the log tag becomes a mini report of which class it has been called from, and can show you at a glance if you’ve got an erroneous LOG_TAG declaration in a class where it shouldn’t be.

[Note] If you intend to keep logging enabled in a production version, you can reduce the memory cost of this function by assigning the “mResources.getString” response to a string variable in the class constructor. I switch logging lines off for production however, so am ok with the load incurred during the resource retrieval.

[Optional] In addition, I put the usual static string declaration in the class if I want to add  additional information to the tag – this works well if you have more than one  version of an identically-named class; if you’re detecting a tablet as opposed  to a phone form factor device for instance.

// Additional log tag info for this class.
private static String LOG_TAG = "NXD-version";

On its own, this doesn’t save me a lot of time. If I add up how much time I must have saved in aggregate from not having misleading logging errors in my LogCat trace, it comes in at days.