Apps-android-commons: Introducing Guava library to the project

[maskaravivek]

I was hoping to introduce the guava library to the project. A lot of android apps use it because of the many features that it provides. Some relevant links.

1. Advantages of guava
2. Is guava useful for android apps?
3. Comparison of guava with other library

[maskaravivek]

@nicolas-raoul @misaochan @whym It would be good to have your views on it. :)

[whym]

What is the current status of this? com.google.guava:guava has been adeed to the dependencies, but I don't see it is used anywhere in the source code.

[maskaravivek]

@whym I used it in #691. Will add a wiki soon so that we can start using it instead of async tasks. That would help in handling concurrency in an elegant way. :)

[whym]

That would be great. I missed it because I didn't notice the namespace was com.google.common not something like com.google.guava.

[psh]

Guava is a huge library and Google's guidance is to always use ProGuard if you're going to pull it in. The current master branch is right at 60k methods (of the 64k method limit).

Checkout the interactive version of the graph if you're curious.

The green quadrant in the top right of the graph is 14.9k methods pulled in from Guava. At present Guava is only used for Futures, SettableFuture, ListenableFuture, and FutureCallback.

Another contribution to the large method code is the plethora of networking libraries - Volley, Legacy Apache and a transitive dependency on OkHttp.

The main use of Guava is to do network calls in the background, something that OkHttp does extremely well especially if coupled with RxJava. I believe that a switch to using Rx would also address the downside of #749 (fix to category threading) using its 'debounce' operator. Another solution would be a tactical switch to Kotlin in localized spots in the app as a lot of the beauty of Guava is present in Kotlin at a language level.

My aim isn't to start a "Library X is better than Y" flame-fest, just to highlight a potential size issue before it bites.

Would anyone be opposed to a spike to -

• Unify the networking
• Switch from Guava to Rx (reporting on method count reduction) to simplify threading
• Debounce the category search so it doesn't "create a bazillion executors" (to quote @misaochan )

[misaochan]

Hi @psh ,

Thanks for the insight! I would not be opposed to switching to Rx, personally. I am not terribly familiar with either Rx or Guava, but if Rx can fulfill Guava's current role while also making it simpler to fix #749 (and reducing size in the meantime!), I would be all for it.

@maskaravivek what do you think?

[maskaravivek]

Thanks @psh for the comments. :)

I have no experience with Rx so will have to evaluate it a bit. Yes if it helps in reducing the method count then we can surely consider it.
Anyways we could also enable multidex support if we exceed the 64k limit. One day or the other we will eventually hit the limits. :)

Multidex

[neslihanturan]

Hi @psh
Thanks for the easy fix advise for #667 . Did you done anything related so far or can you please give me some hints about how can I solve it by using RxJava (I have no experience with it yet) . It can be very nice if we can solve the issue in a week or sooner.

[psh]

@neslihanturan The PR I submitted (#782 - For discussion: get upload count using Kotlin & Rx) has the effect of removing Guava and swapping it for Rx and could be the core of a real change (I omitted pesky things like error handling for brevity). There's no hard requirement to include Kotlin: plain old Java 7 syntax works just fine, its just a little more verbose. Another option is to adopt Java 8 syntax (simple change in the build.gradle) if we want nicer syntax.

If it helps with reaching a conclusion then we can untangle the various decisions -

1. Decide if we want to swap Guava for RxJava
2. Fix the category issue (either the debounce operator, or something else)
3. Decide if we want to introduce Kotlin at a later date and tidy up the code we wrote for step 1

My person preference is a "yes" to Kotlin and a "yes" to using Rx for whatever that's worth!

Sorry if I conflated too many things and made the decisions harder than they needed to be.

[maskaravivek]

Closing this issue as we are using RxJava instead of guava.