Integrate Version Catalog in Android

Introduction 

A version catalog is a list of dependencies, represented as dependency coordinates, that a user can pick from when declaring dependencies in a build script. Version catalog was introduced in Gradle 7.0

Sponsored

We are what we repeatedly do. Excellence, then, is not an act, but a habit. Try out Justly and start building your habits today!

So let’s get started and add some life to your app’s UI with a typewriter animation!

Why do we need Version Catalog?

Version catalog basically focuses on aim of sharing dependencies between modules. Consider a scenario when we have only single module in our app. In that case we can easily manage dependencies and its version in module level build.gradle file (as we need to update version in one module only).

Gradually, when our app grows, the app may contain multiple modules. In this case, if we try to manage dependencies manually, at some point, it becomes a tedious task to manage modules manually.

Here, is a small example of how generated dependency coordinate will look like:

dependencies {
    implementation(libs.timber)
    }

In the above example libs is the name of the catalog and timber is the dependency. We can use this dependency coordinate across multiple modules.

One of the great advantage of using version catalog is defining Bundles. Bundles are nothing but group of dependencies that are commonly used together. Essentially you can now bundle different dependencies that are commonly used together and define them as a single dependency in your build script.

Let’s take a look at Retrofit library, when declaring dependency we usually need to add multiple dependencies like gson, rxjava3 etc.

 dependencies{
  implementation(libs.retrofit)
  implementation(libs.converter.gson)
  implementation(libs.adapter.rxjava3)
  }

While this doesn’t seem bad. But, think about the project where we have multiple modules. And within the module-level build.gradle file, we have multiple dependencies like above.

However, with bundles, we can define the bundle with dependencies in our config file (in our case settings.gradle) and then reference that bundle in our build script.

dependencies{
implementation(libs.bundles.retrofit.bundle)
}

So instead of defining 3 different dependencies, we have now a single dependency in form of bundle. We can now declare this single dependency at various module level build.gradle files. Adding the single bundle is same as defining them individually.

Setup

Now, let’s learn how to setup version catalog in our app. Before we can create a dependency configuration file like settings.gradle, we need to enable the version catalog feature. To enable it just add this to your settings.gradle file.

enableFeaturePreview("VERSION_CATALOGS")

Once you run the Gradle sync, the feature is enabled. Now we can start adding various dependencies in catalog.

Creating the catalog in settings.gradle file

Here, we used Timber library for reference. For Timber dependency to be available, we need to associate an alias with group, artifact, version coordinates.

dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
          version("timber", "4.7.1")
            alias("timber").to("com.jakewharton.timber", "timber").versionRef("timber")
           }
         }
       }

Here, “libs” is a name of a version catalog. But we can provide name as per our convenience like deps or dependencies etc. Version(“timber”,”4.7.1”) declaration is optional and we can directly use version in versionRef, but it will be suitable when we have multiple dependencies and all are using the same version like:

 dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            version("dagger", "2.37")
              alias("dagger-android").to("com.google.dagger", "dagger-android-support").versionRef("dagger")
              alias("dagger-compiler").to("com.google.dagger", "dagger-compiler").versionRef("dagger")
              alias("dagger-processor").to("com.google.dagger", "dagger-android-processor").versionRef("dagger")
              }
            }
          }

Now let’s take a look at how to define bundles. As you can see, we have aliases for retrofit, gson, and rxjava3. So, we just need to pass these aliases to the bundle.

 dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            version("retrofit", "2.9.0")
   
            alias("retrofit").to("com.squareup.retrofit2", "retrofit").versionRef("retrofit")
            alias("converter-gson").to("com.squareup.retrofit2","converter-gson").versionRef("retrofit")
            alias("adapter-rxjava3").to("com.squareup.retrofit2","adapter-rxjava3").versionRef("retrofit")
            
            bundle("retrofit-bundle",["retrofit","converter-gson","adapter-rxjava3"])
            }
          }
       }

That’s it, now we can reference our bundle in module level build.gradle file like:

dependencies{
implementation(libs.bundles.retrofit.bundle)
}

Our settings.gradle configuration file will look something like this:

include ':app'
enableFeaturePreview("VERSION_CATALOGS")

dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
        
          version("timber", "4.7.1")
            alias("timber").to("com.jakewharton.timber", "timber").versionRef("timber")
            
          version("retrofit", "2.9.0")
              
            alias("retrofit").to("com.squareup.retrofit2", "retrofit").versionRef("retrofit")
            alias("converter-gson").to("com.squareup.retrofit2","converter-gson").versionRef("retrofit")
            alias("adapter-rxjava3").to("com.squareup.retrofit2","adapter-rxjava3").versionRef("retrofit")
            
            bundle("retrofit-bundle",["retrofit","converter-gson","adapter-rxjava3"])
            }
          }
        }

Note that if we add any module then we need to add it in settings.gradle configuration file using include. Currently we have only single module called app.

Conclusion

Version catalog is effective way to manage our dependencies when we have multiple modules (as we need to update dependencies at one place only) and everything else will be managed by version catalog. As version catalog is still a preview feature, it’s subjected to change and may also be unreliable in certain cases.

Hope, this will help you start with Version catalog.

Thanks for your support!

Related Articles