Gradle for Android Part 3 (Dependency Management)

Dependency Management

Dependency management is where Gradle shines the most. The best scenario is that you only need to add a line of code in your build file, and Gradle will automatically download the relevant jar packages from the remote repository for you and ensure that you can use them correctly. Gradle can even do more for you, including excluding the same jar packages for you when you add multiple identical dependencies in your project. In this chapter we will learn the following:

• storehouse
• Local Dependencies
• Explain the concept of dependency

storehouse

When we talk about dependencies, we usually mean remote repositories, like those that are specifically provided to other developers. Managing dependencies manually can be a hassle. You have to navigate to the dependency file location, download the jar file, copy it to your project, and then reference it. Usually these jar files don't have specific version numbers, so you have to remember their version numbers so that when you need to update, you will know which version to replace. You also have to put the dependency package on svn or Git so that your other colleagues don't have to manually download these dependency jars.

Using remote repositories can solve these problems. A repository can be seen as a collection of files. Gradle does not add any repositories to your project by default. So you need to add them to the repositories method. If you are using Android studio, the tool has already prepared all of this for you:

 repositories {
 jcenter()
 }

Gradle supports three different repositories: Maven, Ivy, and folders. Dependency packages will be downloaded from these remote repositories when you execute the build. Of course, Gradle will keep a cache for you locally, so a specific version of the dependency package only needs to be downloaded once.

A dependency needs to define three elements: group, name, and version. Group means the name of the organization that created the library, usually this will be the package name, and name is the unique identifier of the library. Version is the version number of the library. Let's see how to declare a dependency:

 dependencies {
       compile 'com.google.code.gson:gson:2.3'  
       compile 'com.squareup.retrofit:retrofit:1.9.0'  
 }

The above code is based on groovy syntax, so its complete expression should be like this:

 dependencies {
      compile group : 'com.google.code.gson' , name : 'gson' , version: '2.3'  
      compile group : 'com.squareup.retrofit' , name : 'retrofit'  
 version: '1.9.0'  
 }

Predefined for your repository

For convenience, Gradle will predefine three Maven repositories by default: Jcenter, MavenCentral, and the local Maven repository. You can declare them at the same time:

 repositories {
 mavenCentral()
 jcenter()
 mavenLocal()
 }

Maven and Jcenter are two very famous repositories. We don't need to use them at the same time. Here I suggest you use jcenter, which is a branch of the maven central repository, so you can switch between the two repositories at will. Of course, jcenter also supports https, while maven repository does not.

The local Maven repository is a collection of all the dependencies you have used. Of course, you can also add your own dependencies. By default, you can find a .m2 folder under your home folder. In addition to these repositories, you can also use other public or even private repositories.

Remote Repository

Some organizations, who have created some interesting plugins or libraries, prefer to put them in their own Maven repository instead of Maven Central or JCenter. So when you need to use these repositories, you only need to add the URL address to the Maven method:

 repositories {
 Maven {
           url "http://repo.acmecorp.com/maven2"  
 }
 }

The same can be done with Ivy repositories. Apache Ivy is a well-known dependency management tool in the ant world. If your company has its own repository, if they need permission to access it, you can write it like this:

 repositories {
 Maven {
           url "http://repo.acmecorp.com/maven2"  
 credentials
               username 'user'  
 password   'secretpassword'  
 }
 }
 }

Note: This is not a good idea, the best way is to put these validations in Gradle properties files, which we have already introduced in Chapter 2.

Local Dependencies

There may be cases where you need to download jar packages manually, or you want to create your own library so that you can reuse it in different projects without having to publish the library to a public or private repository. In the above cases, you may not need network resources. Next, I will introduce how to use these jar dependencies, how to import so packages, and how to add dependency projects to your project.

File Dependencies

If you want to add a jar file as a dependency to your project, you can do this:

 dependencies {
       compile files( 'libs/domoarigato.jar' )
 }

It would be silly if you did that, because when you have a lot of jars like this, you could just write:

 dependencies {
       compile fileTree( 'libs' )
 }

By default, a newly created Android project will have a lib folder and will be defined in the dependencies like this (that is, add all the jars in the libs folder):

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

This also means that in any Android project, you can put a jar file in the libs folder, which will automatically add it to the build path and the final APK file.

native package (so package)

A library written in C or C++ is called a so package. The Android plugin supports native packages by default. You need to put the .so file in the corresponding folder:

 app
   ├── AndroidManifest.xml
 └── jniLibs
 ├── armeabi
       │ └── nativelib.so
 ├── armeabi-v7a
       │ └── nativelib.so
 ├── mips
       │ └── nativelib.so
 └── x86
           └── nativelib.so

aar file

If you want to share a library, the dependency package uses Android APIs, or contains Android resource files, then aar files are for you. Dependent libraries are the same as application projects. You can use the same tasks to build and test your dependent projects, and of course they can have different build versions. The difference between application projects and dependent projects is the output file. Application projects generate APK files, which can be installed on Android devices, while dependent projects generate .aar files. This file can be used as a dependency by Android application projects.

Creating and using dependent project modules

The difference is that you need to add different plugins:

 apply plugin: 'com.android.library'   

There are two ways to use a dependent project. One is to use it as a module directly in your project, and the other is to create an aar file so that other applications can reuse it.

If you use it as a module, you need to add it as a module in the settings.gradle file:

 include ':app' , ':library'  

Here, we call it library. If you want to use this module, you need to add it in your dependencies, like this:

 dependencies { 
 
  compile project( ':library' ) 
  
 }

Using aar file

If you want to reuse your library, you can create an aar file and use it as a dependency in your project. When you build your library project, the aar file will be generated under build/output/aar/. To use this file as your dependency package, you need to create a folder to place it, let's call it aars folder, then copy it to the folder, and then add the folder as a dependency library:

 repositories {
 flatDir {
 dirs 'aars'   
 }
 }

This way you can use all aar files in this folder as dependencies, and you can do this:

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

This will tell Gradle to add a file called libraryname with the suffix aar as a dependency in the aars folder.

The concept of dependency

Configuration

Sometimes, you may need to work with the SDK. In order to compile your code successfully, you need to add the SDK to your build environment. You don't need to include the SDK in your APK because it already exists on the device, so here comes the configuration. We will have 5 different configurations:

• compile
• apk
• provided
• testCompile
• androidTestCompile

compile is the default one, which means that all dependent packages are included, that is, in the APK, the compile dependencies will exist.

apk means that it exists in the apk but will not be included in the compilation. This seems to be rarely used.

Provided means that compilation support is provided, but the apk will not be written.

testCompile and androidTestCompile add additional library support for testing.

These configurations will be used in test-related tasks, which is very useful for adding testing frameworks such as JUnit or Espresso, because you only want these frameworks to appear in the test apk, not the production apk.

In addition to these specific configurations, the Android plugin also provides configurations for each build variant, which makes it possible to configure debugCompile or releaseProvided. This is useful if you want to add a logging framework for your debug version. I will introduce these in detail in the next blog.

Dynamic version

In some cases, you may want to use the latest dependency packages when building your app or library. The best way to achieve this is to use dynamic versions. I will now show you several different ways to dynamically control versions:

 dependencies {
       compile 'com.android.support:support-v4:22.2.+'  
       compile 'com.android.support:appcompat-v7:22.2+'  
       compile 'com.android.support:recyclerview-v7:+'  
 }

In the first line, we tell gradle to get the latest production version. In the second line, we tell gradle that we want the latest minor version, and its minimum version number is 2. In the third line, we tell gradle to get the latest library.

You should be careful with dynamic versions. If you allow Gradle to pick the latest version, it may pick a version of the dependency that is not stable. This will cause a lot of problems with your build. Worse, you may get different versions of dependencies on your server and your personal PC, which will directly cause your application to be out of sync.

If you use dynamic builds in your build.gradle, Android studio will warn you about potential issues with dynamic builds, as you can see below:

Android studio UI operation dependency library

In Android studio, the easiest way to add new dependencies is to use the project structure pop-up window. Open the interface from the file button, navigate to the dependency navigation bar, and then you can see your current dependencies:

When you want to add a new dependency package, you can click the small green button. You can add other modules, files, or even search the Internet.

Using the Android studio interface allows you to easily browse all the dependencies in your project and add new dependency packages. You don't have to manually add code in build.gradle, and you can directly search for dependency resources in the JCenter library.

Summarize

In this chapter, we learned about various ways to add dependencies. We learned what repositories are and how to use them. We also learned how to use jar files without using repositories.

You now know how to configure dependency properties, dynamic version control, etc.

We also talked about building variants of your app for multiple environments. In the next chapter, we'll learn what build variants are and why they're important. Build variants make it easier to develop, test, and distribute your app. Understanding how variants work can speed up your development and distribution efforts.