4 Rules to Picking Android Libraries
The top tip I can give any aspiring Android developer is simply… “Someone has already made a library for that.”
More than most other languages I play around with, Java is heavily dependent on third party libraries. With the proliferation of Android, I’d say the third party game has been kicked up a notch. All of this convenience doesn’t come without a price, but I’ll talk about that later.
How many Android libraries are out there?
I couldn’t even take a guess at that question, as new ones are popping up every day. Looking at this semi-curated list on Github, we can quickly see that there are hundreds of popular libraries just on THIS list. This list only covers Android libraries on Github that someone has stuck on there manually. Here is a list I prefer, as the libraries seem to be curated slightly.
Add to those guys this list of Android UI libraries and we can see there is something for everyone.
Note: Here is a corresponding list of iOS libraries and a list of iOS UI libraries. You’ll find that when you search Github for “Awesome”, a lot of curated library lists pop up (Python, Ruby, and a few others have similar equivalents).
How do I choose?
Everyone has their own set of rules on when to use a library, when not to, what version to use, when to update, etc… I can only share some of my rules of thumb - none of which are hard and fast - but are used in all my development (regardless of language).
One caveat I’ll mention is that when I’m playing around and doing my own prototyping or demos - absolutely anything goes, and it’s bleeding edge versions all the time. However, most of what I write is production-grade, which means I have to be more careful.
1. It is open-source with commerical-friendly licenses
- Since I write most of my code for my clients, whatever libraries I bring in MUST be commercial-friendly (Apache/MIT/similar) - otherwise my neglect will put my clients in a legally precarious position. Personally, I like to open-source under MIT and Apache as well.
- I understand the spirit and the benefits of GPL, but it just doesn’t sit well with me to be handcuffed by it (this is a huge flame-war topic, which I want to stay out of).
2. It has more than 1,000 stars on Github
- To me, 1000 signifies enough traction that the library won’t suddenly go away. There is often enough of a community to keep it going, keep updating, finding bugs, etc…
- Also, when you’re > 1000 stars, you can sometimes start calling that library the ‘de facto XYZ library’ which I find comforting.
3. It has made it past v1.1.0
- I know according to SemVer and other systems, 1.0.0 means production-ready, but it really doesn’t. v1.0.0 is when the masses start using a library, and that’s when a lot of flaws come out of the woodwork too. I like to first see some patches come out (and maybe a small feature addition or two), before I use it.
- Keep in mind, I’m referring to third party libraries, not platforms/frameworks/languages, which are usually pretty solid when they hit 1.0.0 (NodeJS is a great example of a prolific platform in production that hasn’t even hit 1.0.0!).
4. It is maintained by people/companies I trust
- When Google, Twitter, Facebook, etc… are putting libraries out there, you can bet they’re used internally a fair amount. My take away from this is that these should be battle-tested libraries, with a commercial backing that won’t disappear overnight.
- A prime example of this is protocol buffers. I can use protobufs in production without worrying that Google with suddenly stop supporting it, or make massive, non-backwards-compatible API changes
- because they just can’t do that, as protobufs are used extensively internally.
- A potential downside of libraries with massive backing is that they’re not really updated as often, which I personally don’t view as a downside. If I’m putting something in production, I don’t want to see 5 patches come out within a week! That’s a library that’s not ready for prime-time (aside: take a wild guess what happened to a ‘production-ready’ library I was using last week that caused 14,000 crashes in the field in three days).
What about Android land?
The Android libraries they put into the field are just incredible, and make my dev life so much easier.
Without further ado:
- Android Saripaar - “Android Saripaar is a simple, yet powerful rule-based UI form validation library for Android.”
- I use Saripaar for validating my profile pages and other EditTexts. This is a rare situation where I’m pretty comfortable using the 2.0 Snapshots, because it’s not a library that’s tightly ingrained in my code. If something goes wrong, I just hand-roll some text validation - maybe a day or two of time lost.
- ButterKnife - “Field and method binding for Android views which uses annotation processing to generate boilerplate code for you.”
- When I see code using findViewById, I shake my head, put ButterKnife in Gradle, and go to town… The thing is, it’s not necessarily that I save lines of code, but I just save brainspace by knowing that if I’ve got a member variable pointing to a View, I know it’s also inflated.
- Also, with the @OnClick, I can save all that embedded, anonymous, nested junk that I would otherwise need when setting click listeners.
- Couchbase Lite - “Couchbase-Lite-Android is a lightweight embedded NoSQL database engine for Android with the built-in ability to sync to Couchbase Server on the backend.”
- Oh Couchbase… You and I have had our differences friend… My first experience with Couchbase Lite (iOS and Android) was before they hit 1.0.0, and man were those unstable times. However, now, it’s like a gem.
- To use CBL, you naturally need to be using Couchbase (or maybe CouchDB) on the server-side and Sync Gateway to handle the synching. I’m not necessarily the biggest fan of NoSQL, but man do I like Couchbase. If you’ve ever had to write a mobile-server replication system, and then realize it’s built-in with Couchbase, you’ll like them too.
- Crashlytics - “Introducing the most powerful, yet lightest weight crash reporting solution.”
- So, not open-source, but incredibly valuable. If you’ve ever had a crash in the field (e.g. if you’ve ever written code that made it to the field), you’ll immediately know the value of a tool that throws all of your stack traces onto a website for easy perusal.
- Since becoming a part of the Twitter Fabric platform, there is a sweet integration into the various IDEs to streamline your workflow even more.
- Dagger - “A fast dependency injector for Android and Java.”
- I won’t talk too much about Dagger, as I’m still on the fence about it. Not that it’s not amazing, but I feel it’s still missing -something-. It handles and cleans up a lot of boilerplate code, but I also feel like it causes me to write a lot of boilerplate to start using it - but maybe I’m just doing something wrong?
- Flurry - “Industry leading mobile analytics. For free”
- Another non-open source one, but a pretty fun analytics tool. You can track whatever you want, and it shows up very nicely on their dashboard, and it’s free! A good way I’ve made use of it is to add a beta feature, see how much usage/traffic the feature gets, and then I determine whether to release it or not.
- Otto - “Otto is an event bus designed to decouple different parts of your application while still allowing them to communicate efficiently.”
- Their own Readme says it very well. It’s an event bus intended to decouple code (e.g. as an alternative to using a LocalBroadcastReceiver and piping that code everywhere… yuck…). A similar solution would be EventBus - they each have their own use cases, and I particularly like Otto’s API, but you can’t go wrong with either.
- One thing to watch out for though… When using an event bus, it’s REALLY easy to overdo it and use a bus to pass information in every circumstance (imagine every class/activity/fragment had 10 publishers and 10 subscribers… How could you track what was going where? And how could new developers do it?)
- Having the ability to do this doesn’t preclude the necessity to design and architect your application correctly. A library like this should be used to reduce boilerplate, not to handle every message passing scenario in the app (contrived example - use it to replace a LocalBroadcastReceiver, don’t necessarily use it to replace passing information between activities using intents).
- Picasso - “A powerful image downloading and caching library for Android.”
- Exactly what it says… Use it for image downloading, caching, and display. It has a fantastically simple API, you can do some custom transformations, and show placeholder images. So slick.
- A friend brought a similar library by Facebook to my attention Fresco - I’ll probably play around with this in my next project, as it looks fun.
- Also, about 8 months ago, I wrote a post talking about integrating Picasso with Couchbase Lite attachments - seems relevant right now: Couchbase Lite Attachments in Picasso
- Retrofit - “Type-safe REST client for Android and Java.”
- Retrofit let’s you define your REST API, determine whether you want calls to be synchronous or asynchronous, and that’s all in a handful of lines of code. Best of all, it uses OkHTTP under the hood and plays nicely with other libraries (like RxJava).
- Retrolambda - “Backport of Java 8’s lambda expressions to Java 7, 6 and 5”
- Ever since I learned about lambdas, I can’t stop using them. They’re SUCH a good way to get rid of annoying boilerplate code. They’re perfect in those situations where you have a Listener which takes in an object with a single overloaded method - saves like… 10 lines of code… Also super handy in RxJavaland.
- Robospice - “RoboSpice is a modular android library that makes writing asynchronous network requests easy!”
- I’ll be honest, I didn’t really grok RoboSpice until a few days ago. I’ve used it in the past, I kinda understood why it was good, how it tied into Activity lifecycles, but I just thought there was wayyy too much boilerplate that needed to be written for the functionality it provided when tying in with Retrofit.
- As it turned out, I was making my life much harder than it needed to be, and once I figured out the correct way to tie Robospice and Retrofit together, it was super smooth sailing from there on in.
- RxJava - “A library for composing asynchronous and event-based programs by using observable sequences.”
- Okay… I don’t think I can get into this one right now, this is a blog post of it’s own. In short, RxJava (and RxAndroid) facilitate reactive programming. If memory serves correctly, a lot of the Reactive Extensions stuff started with Microsoft and .NET and has flourished into most other languages. The goal is essentially asynchronous, functional, concurrent programming.
- Timber - “A logger with a small, extensible API which provides utility on top of Android’s normal Log class.”
- Another Jake Wharton gem. A clean API that runs atop Android’s Log and reduces some boilerplate code.
- Wire - “Clean, lightweight protocol buffers for Android and Java.”
- I’ve mentioned protocol buffers once before already, so it should be pretty clear I like them. What I don’t like about them is that there is a TON of generated code that goes into them. Wire helps out by reducing and removing a lot of the cruft. Why is this even an issue? Keep reading…
What’s the catch?
Remember I said there is a price to pay with all of these libraries?
Compiling protobufs in Java is a great way to really see the price you pay. The Wire library documentation says it well: “Code generated by Wire has many fewer methods than standard protocol buffer code, which helps applications avoid the notorious 64k limit on methods in Android applications.”
Never seen the “notorious 64k limit”? Consider yourself lucky. It’s a pain in the ass.
In my next post on the subject, I’m going to show the impact of all of these libraries on the 64k method limit and what you can do about it when you run into it (and you will run into it).