I'm faced with the question of what library to use in an Android app. For the sake of generality and objectivity, I'll avoid mentioning what the libraries actually do. I've narrowed the field down to three options based on the criteria mentioned in the description of each.

My question is not which library is "best" for this or any other situation. Rather, I'm interested in your insights into what other criteria I might apply to my decision, or anything else I might not have considered.

Whatever I choose, I'll be stuck with it. The paradigms of the two libraries are different enough that I don't think it would be practical to wrap them in a common API and switch between them later.

Option #1: The old standby

The good: I've used this library in other apps and I'm quite comfortable with it. The Javadoc is thorough. The jar is only 95 KB.

The bad: Google recently deprecated the entire API that this library depends on. This API is open source and still supported by the original developers, but Google's deprecation indicates that they plan to remove it from Android's standard library. The developer of the library I'm using has announced plans to fork the third-party API and bundle it into his own library to guard against its eventual removal from Android. Napkin math says this will bloat the library to at least 1 MB, and maybe twice that, since I don't know exactly which libraries it depends on.

Option #2: The shiny new solution

The good: This library has a lot more features than the one I've been using, and would replace an additional 163 KB of other libraries (258 KB total).

The bad: No Javadoc. Normally I would consider that an instant deal-breaker, but my back is to the wall. Without proper documentation, I expect it to cost at least a week or two to get comfortable with. Weighs in at 573 KB, plus another 216 KB for an optional higher level abstraction. So three times the size of what it's replacing, but potentially a third of the future size of what it's replacing.

Option #3: Roll my own

The good: It would be based on the API that Google is keeping, so it would be very small. There would be Javadoc. Other developers may be facing this same dilemma, so my API could become a product in its own right.

The bad: It would not be as feature-rich as option #1, let alone option #2. It would cost me at least two weeks to write.

  • 1
    Architecture don't stay forever. No matter what choice you make today, the software written on it will eventually wear out and be replaced. Quote 1: "If you don’t end up regretting your early technology decisions ...", Quote 2: "The best code you can write now is code you'll ...". Both quotes can be found here (slideshare.net). That will stay true until you finally have a multi-million-dollar company which can invest in the longer term.
    – rwong
    Commented Apr 28, 2015 at 23:44
  • @rwong I think you should flesh out your comment as an answer for proper discussion. Commented Apr 29, 2015 at 0:09
  • Why include the library sizes? At 1MB or smaller, that's insignificant, even for mobile devices.
    – Telastyn
    Commented Apr 29, 2015 at 0:23
  • @Telastyn It adds up. I'm thinking like the backpackers who cut the handles off their toothbrushes. Commented Apr 29, 2015 at 0:31
  • ProGuard's shrink feature can remove from the libraries all the unused code, so size should still not matter.
    – bigstones
    Commented Apr 29, 2015 at 5:37

2 Answers 2


Only you know what your resources are: time, associated headaches, etc. However, this is the approach I advocate in the general case:

  • Avoid deprecated APIs unless there is no other alternative and they are not going away anytime soon. I could name several deprecated or otherwise unfavored APIs that have been sitting around 10+ years with no plans of being removed. Android is much more prone to those deprecated APIs going away, so in this case, avoid them like the plague.

  • Unless space really is at a premium (embedded), why bother unless a library is outrageously huge, like 100 mb? As an aside, I wish there were an easy way to prune libraries in Java/Dalvik the way C and C++ linkers do.

  • Prefer to use a built-in API when available: failing that, prefer to use a third-party (preferably free/open source) library if it is actively maintained. Abandonware helps no one. Finally, as a last resort, roll your own. I would open it up and maintain it, which helps others and gives back to the community.

  • To be clear, the API is not deprecated; it's still actively supported by the original developers. Only its inclusion in Android's standard API is deprecated. Commented Apr 29, 2015 at 1:32
  • 2
    @KevinKrumwiede I was referring to "Google recently deprecated the entire API that this library depends on." If the developers update it to use a non-deprecated API then the point is moot.
    – user22815
    Commented Apr 29, 2015 at 1:33

Option #1: The old standby

Deprecated stuff should never be used if there is another option. Any libraries built using this deprecated library will technically be deprecated. So your product would be deprecated before it was even finished.

It was deprecated for a reason. Typically that reason is that there is something better in every aspect, and you should use that.

Option #2: The shiny new solution

It sounds like this is the something better. I think you should bite the bullet, and climb that learning curve. This allows someone else to do the heavy lifting of creating it, updating it, and maintaining it. You don't want that on your plate.

Option #3: Roll my own

This is probably what I would do (despite my own advice). It does exactly what you want with zero overhead. You know exactly how it works. But...you have to make it. Making it will probably take longer than learning #2. Don't reinvent the wheel.


I think #1 and anything deprecated should be avoided like the plague. #3 sounds the most appealing, but I would advise #2.

  • To be clear, the API is not deprecated; it's still actively supported by the original developers. Only its inclusion in Android's standard API is deprecated. Commented Apr 29, 2015 at 1:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.