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 ·     ...
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 th...
Read more

Local Broadcast, less overhead and secure in Android

Image
Broadcast receiver is an Android component which allows you to send or receive Android system or application events. All the registered application are notified by the Android runtime once event happens. It works similar to the publish-subscribe design pattern and used for asynchronous inter-process communication. For example, applications can register for various system events like boot complete or battery low, and Android system sends broadcast when specific event occur. Any application can also create its own custom broadcasts. Basics of broadcast Let’s discuss some basic concepts of broadcast receiver. Register Broadcast There are two ways to register broadcast receiver- Manifest-declared (Statically) : By this receiver can be registered via the AndroidManifest.xml file. Context-registered (Dynamically): By this register a receiver dynamically via the Context.registerReceiver() method. Receive Broadcasts To be able to receive a br...
Read more