MyNotes: Goodbye Guava

 

I have noticed a few odd build failures lately that were not due to syntax errors.  These were the java.exe failing with error code 2.  This is a big red flag that there is too  much going on library wise.   The root of the problem is that android has issues when an app has more than 65k methods.  This includes all of the libraries that get built into the app.

Guava is a huge monolithic library.  And I brought it into both my common library module and the mynotes module.  In addition, it looks like ButterKnife also brings in a Guava version.  That would be three compilations of a very large library for  very small app.

I tried doing some selective behavior with gradle to minimize the library impact, but none of them work really well and made the files very messy.  I also thought about enabling multidexing, which would also fix the problem, but that seemed ridiculous to do for a tiny app.

So that left me with analyzing whether I really needed Guava.  The short answer is no.  I am only using two classes: Preconditions and Strings.  And I wasn’t even using the majority of the methods in those classes.

As a result, I took out Guava and created my own Preconditions and Strings classes.  I kept the method and class names the same, but spun my own implementations.  I stuck those classes in the Common Library for now.

Ta Da:  weird build problems magically go away.  The moral of the story: be careful bringing in libraries unless you really need them.

Commits

The changes can be found at https://github.com/fsk-software/mynotes/commit/75bd19218d46e23066e067b9506895ab9a56359f.

MyNotes: Fruit Based Libraries

As you might have noted from the last commits, I brought in the Guava library.  There are two schools of thought on Guava with Android:  Do it or Avoid at all cost.

I am ambivalent on the subject.

I don't like bringing in large libraries because they push your app towards the dreaded 65k method limit.  Android has provided ways to mitigate the issue, but I don't like getting close to it. Guava is a big library and that has to be take into consideration.

On the other hand, I don't have the time or resources to reinvent the wheel or keep it turning when it comes to the functionality that Guava gives me.

After waffling for awhile, I decided to include Guava.  This means that I will need to use Proguard ot shrink the library to only those classes that I am using.  It also means I have to be more careful in my release testing to make sure the Proguard minimazation works and that I am not including more of Guava than I need.

To bring in Guava with Gradle, you need to add MavenCentral as a valid repository and then add the dependency.  It ends up looking like this:

allprojects {
    repositories {
        jcenter()
        mavenCentral()
    }
}
...

dependencies {
    compile group: 'com.google.guava', name: 'guava', version: '18.0'

   .... other dependencies....
}

I also need to add a new file into the projects called progurard-guave.pro and add that to the release building portion of gradle:

buildTypes {
  release {
    minifyEnabled true

    // Library specific proguard files
    proguardFiles 'proguard-guava.pro'

    //Default proguard file
    proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
  }
}

Just an FYI:  do not trust the contents of proguard-guava.pro yet.  I am saving the real work on the file for later once the development is done.

Commits

You can find the changes for this entry among the commit at https://github.com/fsk-software/mynotes/commit/a89a3c2d74d7bb5aeff7520a38d417a8ec05a9e3.