So you decided to write an open-source library, and here you are. What have you got yourself into now, and what’s that header image got to do with anything? Well that lovely header picture up top is a photo I took from my desk of a seagull caring for its young; it has just vomited up some slugs that it collected earlier, and the fledgling gulls are hoovering it all up as if it’s…not a disgusting pile of slugs because they don’t know more delicious things exist in the world, because they’re still too young to even fly off and find food for themselves.

And that, in a metaphor, is a third-party open-source library. End of article.

I’m joking, but I’m only half joking, because that is a pretty good metaphor for some OS-libs I’ve seen, and I still have more software-development-flavoured snark to deliver before my desire to write wanes and I go back to swearing at the habitual, almost wilful, illogic of Facebook SDK developers, under my breath of course – as they still kinda pay the bills for me these days..

So you might be wondering at this point when I’ll just get to the code dump that you can copy-paste somewhere, and rename awesome-omni-util-lib, so that you can become the next Jake Wharton, well hold your horses there young buck. First in order to decide whether or not we should even be making such a library, we must do a little exercise I like to call, the Super Fun Dunning Kruger Stage Self-Assessment Quiz Fun Quiz!

Here ’tis:

1. Are you writing this library because you actually need it? Or because you think that you or someone else might need it at some point, maybe?

If the latter. Abort. You are wasting your time. YAGNI alert! At very least you should need this library that you are creating right now, because the only way that you “shake down” a dependency is when it’s used. In addition, if nobody uses it (not even you), nobody finds the bugs, and the dependency remains rubbish and unusable. Just search the sea of single-commit library repos on GitHub that are tagged “android-library“ to see what I mean.

2. Have you been using the techniques that are in heavy rotation in this library for more than a couple of weeks?

Let’s assume that your library will be a great success, and used by thousands in the first few months. Congratulations! Your repo will be acquired by Google in no time, and your future Silicon Valley career path is a sure thing! Think of all of the people looking at and scrutinising your code in great detail, and adding that unique flavour of warm, supportive and constructive feedback that the internet is known for. Take some time to think about that one for a while and ask yourself if you really want to open up that door.

Do you really want this thing out in the open? Or could it live quite happily as a project-scoped library module, ugly in form and absent in test coverage, but works fine on your machine so who cares?

3. Does a similar thing already exist, written by a developer people have actually heard of/has done a conference talk or two so has dev clout (not to be confused with dev competence, as they are very different things – see Facebook SDK comment above..)

If your library is insufficiently niche, someone else will have already done it better, or is about to. You will never be the smartest person around, and if you think otherwise you, padawan, are so far left on the holy curve of Dunning Kruger that you should stop reading right now and go and do a hard thing that you will fail at, because the world has more opportunities for failure and moments of humility to dish out than you could ever dream of, and if you haven’t fallen hard on your face and had your code quality ego unceremoniously stripped from you, you are missing a crucial lesson in life in general. Certainly one in software development. So you should go and experience said humiliation such that you can be a better, more modest and balanced developer on the other side of that formative experience.

Un-requested life lesson segue aside, do you want to write a second, tenth, or fiftieth best library that does a common thing that other people have done a better version of? To compete with people whose dev clout attracts hundreds of stars and tens of genuinely helpful PRs, which add technological distinctiveness to their own, and makes them look like a competent leader of devs, even if they’re just Developer Advocates who couldn’t hack an actual production-code writing job so retreated to telling other people how to do it, like a school careers advisor – like, dude. Look at yourself. What advice do you have to give me?

4. Do you seek to boil the ocean with a library of such full-functionality that it will serve all purposes?

Everyone who grew up coding, has at some point had that thought – when they were about 13 years old, and the optimism of youth, blissful ignorance of feature creep has yet to rob the ambition from them: I’m going to write my own Operating System! Very, and I mean very few ever actually got something useful working. I’d go as far to say that if you managed to load a hardware driver and get something to work from a line of interpreted code, you’re in the 1%.

Bear in mind that it’s 2020, and there are still only three viable OS’ for personal desktop use – Windows, MacOS and Linux, and that last one is still for nerds, and the guy who “wrote” the first one stole it anyway; come on Bill you’re fooling nobody here, we know you Zuckerberged it. Come clean!

You can keep the money.

5. Do you have a strong (and justified) opinion about how the thing that you’re making this library to do, should be done?

This might be the most important in this super fun quiz fun. If you don’t have a strong opinion about how to do this arbitrary chunk of logic that you’ve cooked up in your head, you’re going to follow the ruts in the road like a SUV on summer tyres on a crisp January morning in Quebec; getting pulled left and right where the tracks cross, and get sidetracked every new article you read on Medium, RayWenderlich or that YouTube one whose name I always forget. You know, the German guy.

If you want to write a LiveData-based random pun generator that updates a ViewModel and punts it out to a TextView element that only displays Comic Sans text in #F00, then you make that library, kid. Don’t let anyone on the issues tab tell you it should support other typefaces.

To use the metaphor from up-top, instead of giving-in to the baby seagulls demands for juicy slugs that you don’t want to puke up, I suggest that you:

Conclusion

Oh right, that code that you wanted to copy paste so you could actually make an Open-Source Android Library module.

Here you go.

No, I didn’t write it myself, because do you really think I can write an example better than the JitPack team already has? Because I don’t.

Thanks for reading. Good day to you. 👋

[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.