Don't repackage libraries

[MobiDevelop]

It is a well known fact that Android has a limit on the method count within Android's dex format, and repackaging libraries instead of declaring them as proper dependencies makes it more likely to be an issue for apps that use your SDK and also want to use any or all of gson, retrofit, okhttp, or okio. Although multidex can get around the method count limit, it is not without its limitations.

I propose that instead of only providing a "fat-aar" with these repackaged libraries, you also provide a version that properly declares these dependencies in the pom so that we do not have to include these libraries twice when we want to use them in our own code.

[wiktor]

Hi @MobiDevelop, thanks for bringing this topic.

First let me explain why I made this decision in the first place. Before this September SDK wasn't available on Maven Central nor on other Maven repository. If we would like to use pure Gson, Retrofit, OkHttp, Okio, we would need to ask developers to include also them. That creates additional steps for configuration which always creates confusion. I wanted to avoid that at all cost, thus I decided to go with fat library.

Once we are with Maven Central we can discuss reverting this decision. Could you help me with justification?

1. Method limit. I'm very aware of it but have you experienced that in your app? Very few apps have this problem.
2. Instead of going away from fat library, I could run proguard in order to cut down unused methods and even hide used libraries.
3. At Estimote, we like to be on top of new version of libraries (like switching to Retrofit 2 once it goes out of beta). I fear that I'll be creating more harm for other devs with going with new version of Retrofit than good.

What do you think?

[MobiDevelop]

Thanks for the prompt reply @wiktor.

Unfortunately, we do have an app which us running up against the 65k method count limit (largly due to inclusion of some - but not all - of the Google Play Services libraries).

I think that running the SDK through proguard is a good option to meet both your goals of easy integration and to reduce the overall method count of the library. Plus, it will have the added benefit to protect your code from prying eyes.

As far as your ability to move to new versions of libraries, I think that with properly versioned releases that wouldn't ultimately be a concern given the ability to choose the version that best suits the developer using the SDK. That said, I think the proguard option is good for at least an interim step.

I appreciate the openness to discuss.

[pwittchen]

We can try approach similar to Retrofit. There are created separate modules for retrofit-converters and retrofit-adapters, which can be used with Retrofit. These modules are published in Maven Central as a separate artifacts. If developer wants to use specific converter or adapter, he or she can use dependency to such adapter or converter (e.g. Jackson or SimpleXML). Developer can also avoid using such converter and create his or her own custom converter. Maybe this approach will be good for making this library thinner? Of course, removing adapter provided as a separate artifact or avoiding custom adapter at all could reduce library functionality and users should be informed about that. I'm not sure if it's the right way to pursue for this case, but it can be subject of further discussion.

[wiktor]

@pwittchen Your approach is interesting. Though Retrofit/OkHttp/Okio are using in the heart of SDK as they help us with communicating with Estimote Cloud. The only solution I can see right now is obfuscation of dependencies.