Gradle: How to manage dependencies


Gradle makes easy to include external binaries or other library modules to your build as dependencies. The dependencies can be located on your machine or in a remote repository, and any transitive dependencies they declare are automatically included as well. Dependencies are usually managed at the Module-level inside dependencies block in build.gradle file.

Once you have lots of modules, build.gradle file can quickly get messy from dependencies. So In this article, I’ll show a quick way of making Gradle clean and easy to maintain.


Manage dependencies versions

Let’s say our Module-level build.gradle looks like as mentioned below in that you can see most of the libraries have similar library version.

apply plugin: 'com.android.application'
android {
      ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {...}
}
...

dependencies {
    // Android supported libraries
    compile 'com.android.support:appcompat-v7:25.0.0'
    compile 'com.android.support:design:25.0.0'
    compile 'com.android.support:cardview-v7:25.0.0'
    compile 'com.android.support:gridlayout-v7:25.0.0'

    //Google play services
    compile 'com.google.android.gms:play-services:10.2.0'
    compile 'com.google.android.gms:play-services-fitness:10.2.0'
    compile 'com.google.android.gms:play-services-wearable:10.2.0'

    // other dependencies
    ...
}


It is very difficult to manage versions of different libraries. Here we can leverage Gradle’s extra property. For this Gradle provides ext block where we can define our common property values and use those property values in dependencies.


apply plugin: 'com.android.application'
android {
      ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {...}
}
...

ext {
    supportLibraryVersion = '25.0.0'
    playServiceVersion = '10.2.0'
}

dependencies {
    // Android supported libraries
    compile "com.android.support:appcompat-v7:$supportLibraryVersion"
    compile "com.android.support:design:$supportLibraryVersion"
    compile "com.android.support:$supportLibraryVersion"
    compile "com.android.support:gridlayout-v7:$supportLibraryVersion"

    //Google play services
    compile "com.google.android.gms:play-services:$playServiceVersion"
    compile "com.google.android.gms:play-services-fitness:$playServiceVersion"
    compile "com.google.android.gms:play-services-wearable:$playServiceVersion"
   
    ...
}


In above sample code ext block contains two property field playServiceVersion and supportLibraryVersion. Notice that instead of version number, we added $ with its version property and also changed single quotes to double quotes.

When you have multiple modules and you want to use similar version to them also then just move ext block from Module-level build.gradle to Top-level (root) build.gradle.


buildscript {
    ...
}

allprojects {
    ...
}
...

ext {
    supportLibraryVersion = '23.4.0'
    playServicesVersion = '9.2.1'
}

Now your different modules build.gradle will looks like:

apply plugin: 'com.android.application'
android {
      ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {...}
}
...

dependencies {
    // Android supported libraries
    compile "com.android.support:appcompat-v7:$rootProject.supportLibraryVersion"
    compile "com.android.support:design:$rootProject.supportLibraryVersion"
    compile "com.android.support:$rootProject.supportLibraryVersion"
    compile "com.android.support:gridlayout-v7:$rootProject.supportLibraryVersion"

    //Google play services
    compile "com.google.android.gms:play-services:$rootProject.playServiceVersion"
    compile "com.google.android.gms:play-services-fitness:$rootProject.playServiceVersion"
    compile "com.google.android.gms:play-services-wearable:$rootProject.playServiceVersion"
   
    ...
}

Here "com.android.support:appcompat-v7:$supportLibraryVersion" changed to   
"com.android.support:appcompatv7:$rootProject.supportLibraryVersion"

This is just the basic use of ext block. You can also configure other common properties like – versionName, versionCode, minSdkVersion etc in it.


Manage File Dependencies

Adding JARs

To add the JARs dependency in your module you simply kept it in the libs folder and add the below compile dependency:

apply plugin: 'com.android.application'
android {
      ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {...}
}
...

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    ...
}



Adding specific JARs from defined folder

Gradle also provides the flexibility to configure and only import the JARs from our choice and also from defined directory. Let’s say we want “first.jar”, “second.jar” from “mylibrary” directory. This directory is located at project level. So this can be achieve like:

apply plugin: 'com.android.application'
android {
      ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {...}
}
...

dependencies {
    // Import selected JARs from mylibrary folder
    compile fileTree(include: ['first.jar','second.jar'], dir: '../mylibrary')
    ...
}

Adding AARs

Let’s say we have kept AAR file (mylib.aar) in libs folder, so in Top level build.gradle we need to specify flatDir as following:

buildscript {
    ...
}

allprojects {
   repositories {
      jcenter()
      flatDir {
        dirs 'libs'
      }
   }
}

And add the below compile dependency in the Module level build.gradle:

apply plugin: 'com.android.application'
android {
      ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {...}
}
...

dependencies {
       compile(name:'mylib', ext:'aar')
    ...
}

This is all about Gradle dependencies. In general to maintain your Gradle, define your properties in the root level/ top level build.gradle and use it into different modules. You can also read my previous articles on Gradle for more details.

To find more interesting topics on Software development follow me at https://medium.com/@ankit.sinhal.

Twitter: https://twitter.com/ankitsinhal

Comments

Post a Comment

Popular posts from this blog

Android O: Impact On Running Apps And Developer Viewpoint

Image
It’s been just about a year since Google released Android Nougat. In the next version of its Android operating system, it revealed the first developer preview of Android O (Hoping it’ll named Android Oreo) on 21 March 2017. In this article, we are going to discuss all the important features and changes of Android O from developer’s perspective. The Android O release will be known as Android 8.0. The final version of Android 8.0 will be out sometime in Q3 of 2017 and before that Google has plan to rollout DP #4. Based on DP #1, here are list of major behavioral changes which will impact on all currently running applications when run on Android O platform. ·        Background execution limits ·        Background location limits ·        Handles identifiers(Android ID) differently ·        Account Access ·        Notification Channel ·        Logging of uncaught exceptions ·        Locales and internationalization ·        Security changes
Read more

Android Performance: Avoid using ENUM on Android

Image
What and why we use ENUM? Enum in java is a data type that contains fixed set of constants. When we required predefined set of values which represents some kind of data, we use ENUM. We always use Enums when a variable can only take one out of a small set of possible values. For example: public enum Season {   WINTER, SPRING, SUMMER, FALL } Instead of using Integer or String constants, we generally use ENUM to increase compile time checking and avoid errors from passing in invalid constants. Drawback of using ENUM Each value in an ENUM is an object and each declaration will take some runtime memory simply to reference the object. So ENUM values will take more memory then Integer or String constant. Even in old android devices (<=2.2), there were some performance issue related to ENUM which were solved in JIT compiler. Adding a single ENUM will increase the size (13x times than the Integer constant) of final DEX file. It also generates the pr
Read more

Smart way to update RecyclerView using DiffUtil

Image
Say Good Bye To notifyDataSetChanged() We generally use List in any of our day to day development. It also requires to update the list data when user scrolls the list. To achieve this, we often fetch the data from server and update the newly received items. If there is a small delay during this process it impact on the user experience so we want this to be done as soon as possible with along with less resources. When the content of our list gets changed, we have to call notifyDataSetChanged() to get the updates but it is very costly. There are so many iterations for getting the job done in the case of notifyDataSetChanged(). Here DiffUtil class comes into picture and Android developed this utility class to handle data updates for a RecyclerView. What is DiffUtil As of 24.2.0, RecyclerView support library, v7 package offers really handy utility class called DiffUtil. This class finds the difference betwe
Read more