Android Log wrapper

The Android util Log class is a very valuable tool at a developer’s disposal. I use the Log class to log the important steps in a flow that I am building or even printing out the server responses for important API calls. I also use it when I catch an exception or when I’m reporting an error state. When I run the app, I can see exactly what is happening in the app by just looking at the logs. It also becomes easy for QA to accurately hunt down the cause of a bug they might be seeing. Overall it is a great tool to help speed up the product development process.

Although useful, Logs can become an overhead to maintain if you don’t want data to be printed in release builds. I’ve seen developers hesitant to use Log class for the same reason. And if they have to use, it’ll be wrapped around an if(Build.Debug) flag. Imagine having to wrap all the Logs with that if condition. And to avoid that, I’ve seen some try-catches like:

try {
//does something
} catch(Exception e) {
// empty block!!
}

The exceptions are ignored and it wastes time in debugging if there is an exception thrown.

Here comes the Log wrapper class to the rescue. It is, as the name suggests, a wrapper around the Log class from the Android util package. 
Example:

public class CLog {

public static void i(String tag, String message, Throwable throwable) {
if (BuildConfig.DEBUG) {
if (throwable == null) {
Log.i(tag, message);
} else {
Log.i(tag, message, throwable);
}
}
}

public static void i(String tag, String message) {
i(tag, message, null, DEFAULT);
}

public static void i(String tag, String message, Throwable throwable) {
i(tag, message, throwable, DEFAULT);
}
}

As you can see above, all what CLog does is wrap the Log calls in the Build.Debug flag. That way, you can call CLog in your application from all the places you want without having to worry about logs printing in production. One thing to note is that I intentionally named the class CLog(short for CustomLog). I wanted the class name to be short so that it doesn’t feel like I’m doing something fancy instead of Log ;)

Since this creates a bottleneck for all the Log printing, it becomes easy to add third-party logging services. You only have to add at one place. For example, I also send some logs to Crashlytics. Here is how I deal with that

public class CLog {

/** Default value to print logs w/o sending to any service */
public static final int DEFAULT = 0;
/** Integer value identifying Crashlytics service */
public static final int CRASHLYTICS = 1;

// Info Logs
public static void i(String tag, String message, Throwable throwable, int service) {
if (service > DEFAULT) {
sendToService(tag, message, service);
}

if (BuildConfig.DEBUG) {
if (throwable == null) {
Log.i(tag, message);
} else {
Log.i(tag, message, throwable);
}
}
}

public static void i(String tag, String message) {
i(tag, message, null, DEFAULT);
}

public static void i(String tag, String message, Throwable throwable) {
i(tag, message, throwable, DEFAULT);
}
    private static void sendToService(String tag, String message,     int service) {
switch (service) {
case CRASHLYTICS:
Crashlytics.log(1, tag, message); //default priority
break;
}
}
}

If I wish to add another service here, its just a few lines of code in this class. Of course this is just a snippet and I wrap all the priority levels i.e, i,d,e,w, and v.

As you can see, one simple solution saves a ton of time while debugging without having the overhead to make sure that important logs are not being leaked in a production release.