How to decide what library to use?

Question

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.

Answer 1

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.

Answer 2

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.

Summary

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