5 Open Source Android libraries that you should be using

Not much of a preamble here, the title says what this is. If you’re new to Android development, or if you’re just still relying on Google APIs to do everything, these might make your life a bit easier.

The titles all link to the corresponding project pages where you can download/view the source, but if that seems like too much like hard work, just copy-paste the Gradle dependencies (below the name of each library), sync your project, and start playing.

But I use Eclipse, where are the Jars?

*slap* No! Bad developer.

As you appear to have been under a rock recently, you should know that Eclipse is no longer the official IDE for Android, which means you’re making life harder for yourself for no good reason. All of the nice new stuff has moved to a lovely IntelliJ-based IDE. It still can turn a MacBook’s 9hr battery life into a 3hr one, whilst doing a pretty good impression of a hotplate, but hey, that’s Java…

So download Android Studio, then read this, no need to thank me, then read on.


Picasso

compile 'com.squareup.picasso:picasso:2.5.2'

Network image loading made really, really easy.

You probably know this one already, as it’s the easiest solution to loading up an image from a network location, and is the de-facto response to the thousands of “how do I load an image from a url” questions on StackOverflow.

There are tons of tweakable methods and callbacks to use, but if you just want to load an image, it’s as simple as this:

Picasso.with(context)
    .load(url)
    .into(imageView);

Retrofit

compile 'com.squareup.retrofit:retrofit:1.9.0'

If you have an app that connects to a RESTful API (which you do obviously because this is 2015, I think my electric razor has a RESTful API) retrofit makes it easy to turn said server-side interface into a Java interface by using annotations, so that you never have the headache of manually handling every method and call interaction yourself.

These examples are quicker to grok than it would take me to explain it, so check them out.


NexusData

compile 'com.github.dkharrat.nexusdata:nexusdata:0.1.3'

iOS, whilst almost comically flawed and restrictive as an operating system, is a whole lot easier to develop a robust app for due to the well thought out restrictions that Apple place on their developers.

I’ve often seen terror on the faces of iOS developers who try to ‘dip in’ to Android, assuming the SDK-provided libraries to be as well thought out and clean as those they play with in XCode.

It can be summed up thusly:

iOS

It just works

Android

It just works

(for API > 14, except for JellyBeanMR1, or devices that don’t support this undocumented API which we will rename next release anyway, if you’re not using proguard, which is now minify, but has these libraries that are back-ported by the manufacturer, on screen densities that are sort of big, but not landscape, except if they’re fixed aspect, and running the support libraries. On Tuesdays, when it’s not raining.)

…usually. But not on Samsung devices, or older HTCs.

So I’ll freely admit, as an Android developer I am envious of the iOS toolset; GCD, CloudKit, Multipeer Connectivity and last but most: CoreData.

Why can’t we have nice things like that? Oh, we can! (the last one anyway)

Whilst there are a lot of options available that mean you never have to meddle directly with SQLite in your app, NexusData is my personal favourite due to its high-level nature and simplicity of use.

So stop messing around with data persistence code, and get on with making your app.


ButterKnife

compile 'com.jakewharton:butterknife:6.1.0'

If you develop Android apps, you will have typed findView(R.id.something) more often than is healthy.

Stop that.

Jake Wharton’s (if you’re new to Android, you’ll see this name a lot) ButterKnife does away with the need for that extra typing by providing a simple way to generate boilerplate code for the UIs that you define, all via the magic of annotation processing.

 


GSON

compile 'com.google.code.gson:gson:1.7.2'

I use this constantly, and so should you wherever you use JSON in your Android app. I’ve found no better method for turning POJOs into JSON, and back again.

It’s hard to believe, but I’ve seen some very recent examples of code where the developer is still manually writing methods that do this, and in once case a minor mistake that somehow got through to production untested, led to the users of the app being unable to log in at all…

Don’t be that person. Use GSON.