In the first entry of what’s turning out to be a multi-part series on logging, I explained why using Proguard to strip logs (i.e. android.util.Log) is a bad idea. I had recommended using Timber for android-only projects. But we left off looking for a solution that would work with projects that have pure java / kotlin libraries, that would also facilitate excluding the source code entirely for release builds.
Let’s take a quick detour to think about what logging is. It’s something that we want to do anywhere in our code base, but something we don’t want in our release builds. Wouldn’t it be great if, instead of taking it out for release builds, we inject it or ‘weave it’ in for debug builds?
Enter Aspect Oriented Programming, or AOP. There are several great articles explaining this paradigm. The basic gist of AOP is that there are “cross-cutting concerns” that apply to many different parts of your program, which have nothing to do with the code around it. Logging statements are great examples of this. One easy-to-use AOP logging library is Hugo, which is a Jake Wharton library. With Hugo, all you need to do to log a method/constructor/type is to annotate it with @Debuglog.
A more complicated way to using AOP for android development is aspectjx, which is an unofficial plugin for AspectJ for Android Studio. Annotation-style AspectJ works out-of-the-box with the plugin, but if you want to use .aj files (which as used by AspectJ to define different ‘aspects’, or code that can be injected), you’ll need to add some compilation steps via e.g. gradle. To be honest, I haven’t tried adding the gradle steps, but I’m hesitant to recommend them to most users. Any time you add extra steps to a build that each developer will do many times a day, I see it as a big red flag. Build time is money. And if you’re adding a step for every debug build, a step that requires maintaining gradle scripts, as well as maintaining .aj files written in a specific syntax, then you can imagine the costs quickly building up to a point where it might not outweigh the benefits for most organizations.
Even with Hugo or aspectjx, our original quest remains incomplete. Neither of these libraries can be used from pure java/kotlin libraries. Furthermore, due to the limitations of what you can annotate in Java, you can only used them to log methods, types, and constructors. To be really useful, we really want a statement-level logging. And while you would have more flexibility if you were to add the extra steps of .aj files, I’d venture to say that the costs of doing so are significant, especially when there are other alternative solutions available… which I’ll talk about in the next post!
So stay tuned for the next part in trying to find a more suitable method of logging!