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. (That's the only reason I'm considering anything else.) The deprecated API was originally from a third party, and it's open source. The library developer has announced plans to bundle this third-party API into his own library to guard against its eventual removal from the Android API. 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.

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.