Dependencies in android projects

How to manage Gradle dependencies in an Android project properly.

Introduction

If you’re reading this article, you probably did at least one android project. It means you’re familiar with the Gradle build system, and pain that comes up with management Groovy files. What if I say that you can minimize this pain a lot? Moreover, you can do this with Kotlin ❤️.
Gradle dependency management can be done in at least three various ways. Let’s review each of them in detail.

Summary

• Plain dependency management;
• Dependency management via ext;
• The right way;
• Managing repos;
• Keeping dependencies up to date;
• A few words about Kotlin DSL.

Why should I even care?

As soon as your project will grow, the count of its dependencies rise, and build.gradle files will become such a mess and error-prone. As soon as you will modularize your project, you will get many build.gradle files with the same content and will have to manage each file manually.

1) Plain dependency management ❌

The worst approach you can manage your Gradle dependencies is to perform no special workaround and use plain strings alike:

Everybody managed dependencies this way at least once, but it requires a lot of manual changes whenever you upgrade your libraries. Keep in mind that many dependencies are come from one group and have the same version. Moreover, the project may include more than one module, and you’ll have to update dependencies in other modules too (look at the samples below).

As you can see, it has a lot of boilerplate code which can be reduced. It would be great to put these dependencies and their versions in variables and all of them in one place. Let’s see what we can do.

• None… Except for the case, when you’re making a very simple project — you’ll save a little time.

• Your build.gradle files become messy when the project grows;
• In multi-module projects, you have to update the dependencies manually for each module;
• Strings are “dangerous” and error-prone.

2) Dependency management using ExtraPropertiesExtension (ext) 🆗

Another very popular method is to keep your dependencies in ext. This method is OK. Furthermore, it’s recommended by Google. Despite this, I wouldn’t recommend using this method and let’s see why.

The core of this method is to keep all of the dependencies and their versions in one place — ext object by key/value pairs.

What is ext?

From Gradle docs: Extra properties extensions allow new properties to be added to existing domain objects. They act like maps, allowing the storage of arbitrary key/value pairs. All ExtensionAware Gradle domain objects intrinsically have an extension named “ext” of this type.

For example, you can create ‘ deps.gradle’ (or any other name by your choice) file in the project’s root folder. And its content will look something like that:

As you can see, dependencies and their versions are stored in a Groovy map by key/value pairs. Versions are taken out, cause different dependencies from one package/group have the same version number. And we all like to reuse the code, don’t we? 😎

Then you can apply these dependencies whenever you need by specifying “ apply from: ‘[name].gradle’” in necessary buildscript (top-level in our case):

And using these dependencies in action looks like this:

You are supposed to notice a lack of autocomplete, navigation and highlight. It becomes a game-changer for me, so I decided to dig deeper and discovered the third method — buildSrc.

• All of your dependencies are stored in one place;
• Build.gradle files look neat.

• Lack of the highlight, autocomplete or navigation;
• IDE will not show you a warning if dependency is out of date;
• You’re still using error-prone strings, as you get the dependency by string key from ext, and you never know you’re using the right key till building the project, because of lack of the IDE highlight.

3) Dependency management using buildSrc ✅

As Madis Pink wittily noticed in ZeroTurnaround RebelLabs blog about what buildSrc is: If somebody asked about the Gradle feature that everybody should know about, I would probably point them towards buildSrc. It is a magic Gradle Java/Groovy project inside your repository, available as a library to all of your build.gradlefiles.

It allows you to write custom build logic (declare dependencies, writing tasks, and plugins, etc) using your lovely Kotlin🤘, so stop wasting time and let’s go!

First, you need to create a folder named ‘buildSrc’ in the root folder of your project:

Then, to be able to write Java/Kotlin code you have to create a default for java projects src/main/java structure inside just created folder:

Last preparation step: create build.gradle.kts file to enable kotlin support in Gradle.

Now you just need to create a kotlin file inside a newly created folder and move all of your dependencies and versions inside. This way you’ll get full code completion, highlight and navigation support right in the IDE! Here’s a very simple example:

And now we can reference these in our build.gradle files:

At first glance it may feel wrong to put build configuration inside the buildSrc module, though the benefits are still worth it.

• All of your dependencies are stored in one place;
• Build.gradle files look neat;
• You get full of the IDE highlight, autocompletion, and navigation.

• IDE will not show you a warning if dependency is out of date;

4) Keep your dependencies up to date

As you can see, the big downside of both ext and buildSrc methods is IDE will not show you a warning if dependency is out of date, so let’s turn it into a significant advantage.

Default newer version check

By default, IDE checks for the newer version by the ‘Newer Library Version Available’ lint inspection:

It isn’t compatible with both ext and buildSrc methods but nothing to worry about as it’s far from ideal. Sometimes it works a bit incorrect and doesn’t warn some outdated dependencies:

After a very short research, I decided to use the Gradle Versions Plugin developed by Ben Manes.

Gradle Versions Plugin

It’s more stable than Lint inspection and can be configured to match all of your needs. I will not focus on how to add this plugin to the project, its GitHub page has an exhaustive instruction.

To make the magic happen you need to run dependencyUpdates task by prompting this command in terminal:

And task’s default output looks like this:

As you see, it suggests updating the dependencies to beta, alpha, and RC versions. To make it focus on release versions only — some task configuration is needed.

Just add this function to your ‘Dependencies.kt’ file:

And place this code to the bottom of the top-level build.gradle file:

That’s it! It suggests release versions only now:

If you want some fine-tuning, check the GitHub page. You can even configure the task to save its report in the file and use this file with Danger in your CI/CD pipelines to warn you about newer versions automatically.

5) (Bonus) Managing the repositories alongside dependencies

If you read up to this point, I’d like to share with you one of the ways to manage your repositories alongside dependencies. It could be done by gradle interface — RepositoryHandler.

From Gradle docs: A RepositoryHandler manages a set of repositories, allowing repositories to be defined and queried.

Doesn’t matter what method you use, whether ext or buildSrc, you can do that trick with both. All you need is to create a method that receives RepositoryHandler as a parameter like this:

Then just call it inside the build.gradle file and pass the ‘repositories’ handler inside:

Now you can keep all of your build configurations in the same place, which made its management as simple as never before. And how do you manage the repos? Write in the comments below.

6) Kotlin DSL

You may notice, Kotlin DSL used in the buildSrc module. It’s needed to support Kotlin code inside. It’s natural to use it in some modules but not to use it in the entire project. If you’re a Kotlin fan like me, I have to suggest that you at least try Kotlin as the main Gradle language.

From Gradle Kotlin DSL samples at GitHub: The Gradle Kotlin DSL provides support for writing Gradle build scripts using JetBrains’ Kotlin language. It aims to provide Gradle users with a rich, flexible and statically-typed approach to developing build logic in conjunction with the best IDE and tooling experience possible.

So, Kotlin DSL gives you an ability to write your Gradle files, tasks, and so on in Kotlin. It makes Gradle files much more readable and simple. But it isn’t fully supported yet and has a build speed issue at first build with cold Gradle daemon. But Kotlin DSL has official support by the Gradle team, and they teamwise with the JetBrains do their best to make it better.

Conclusion

I’ve described all the methods I know, please, tell me how you’re managing dependencies in your project. Also, I would appreciate, if you let me know how you’d like the story, it’s my first attempt at writing. Feel free to use comments below or ping me on social media. Thank you for your attention.

Источник

How to Display Dependency Tree of Your Android Project with Gradle?

For Starters, simply run the command “gradlew :app:dependencies” in your terminal

Recently, in one of my projects, we were stuck at a very annoying exception IllegalStateException: WorkManager is already initialized . We were pretty confident on we have only initialized WorkManager only one time, then why Android Studio is throwing this exception.

The initial hunch we had was there’s some other dependency in our project, which is using WorkManager and that’s why this conflict is popped up. We looked at the build.gradle file and realized that we haven’t added any such dependency in our project which might use WorkManager in any way.

Looking into different solutions like updating / removing dependencies, and plugins, and debugging the app line by line to see where and how it crashes, we simply couldn’t crack the problem. And that’s where it hit me suddenly.

Is it possible to view the whole dependency tree of our project?

Answer is yes. It is possible in Android Studio and even terminal too. This article is about different methods to see how you can view the whole dependency tree of your app.

How Gradle Dependency Tree Can Help You?

The Gradle Dependency Tree or Graph can tell you the about all the dependencies being used in your app in hierarchical way. It can help you with the version resolutions of same dependencies.

For example, your app is using Retrofit version 2.1 but there’s some other dependency in your app which is using Retrofit version 2.2. So, Android Studio will try to upgrade the dependency to the latest version i-e 2.2 for your whole project. Now, if there’s the big difference between old version and new version and require refactoring changes, this can be a problem for your app.

Gradle dependency tree can help you detect these kinds of issues. It can also help you in detecting the dependencies which are not being used directly in your app but rather these are being added by nested dependencies.

Now, let’s see different ways to view the Android app’s Gradle dependency tree or graph.

1. Through Android Studio Gradle Panel

This is the most easy and accessible method directly through Android Studio. Click on the Gradle tab on the right side and then expand :yourmodule -> Tasks -> android . Finally, double click on androidDependencies to run it.

This task will print the whole graph in your Android Studio console like the image below:

2. Through Dependencies Command

This is similar to 1st option. Only difference is that you will be doing it manually by running a command in terminal. You can use either Android Studio terminal or your own choice terminal at the root directory of your project. Simply enter this command.

The yourmodule is the name of the module you want to see dependencies for. For example, for your app, you can use it as app .

Additionally, if you want to check if something is compile , testCompile , androidTestCompile , implementation , testImplementation , or androidTestImplementation dependency as well, you can do so with the configuration parameter like this:

3. Through Gradle Build Scan

If you don’t know about Gradle build scans, these are the “X-ray for your Gradle and Maven builds” according to their website. They were introduced in Gradle 4.3 plugin.

Using Gradle Build Scans is probably the most easiest and clean way to analyze not only the dependencies of your project but also other build information.

All you have to do is add —scan at end of any Gradle command in terminal. For example, for viewing the whole dependency tree, you can use this command:

After the command ends, you will be asked for a confirmation on whether the build report should be generated or not. Type yes and you will get a link to the report.

Open this URL and enter your email. And you will get access to your build in your inbox in a few minutes. Open the build and head for Dependencies tab, and you will see something like this:

You can see that this has many other options like Performance, Tests, Plugins etc to provide you detailed insights about your build in a very nice formatted HTML page.

4. Through Project Report Plugin

If you don’t want to put email every time you compile your project and see the report in the Android Studio IDE, you can use Project Reports plugin. This requires a little code modification in your app’s build.gradle file. First, put this on top of your app’s build.gradle file:

And after syncing your project, run this command in Android Studio terminal.

This will give you a local HTML file link in your console. Click on it and you will see a nicely formatted dependencies tree with expand/collapse options.

Special Mention — Gradle Dependency Graph Generator Plugin

There’s also this awesome third-party plugin created by Niklas Baudy which shows the visual dependency graph of your Android project like this:

You can learn how to generate this graph by following the instructions available on his Gradle Dependency Graph Generator Plugin library at the following link:

vanniktech/gradle-dependency-graph-generator-plugin

Gradle plugin that generates dependency graphs from your project

github.com

At the end, please Subscribe to my newsletter DroidUp to learn learn about the latest things, tips, and skills in Android development manually handcrafted and curated by Wajahat Karim.

If you liked this article, you can read my new articles below:

Becoming a Google Dev Expert (GDE) in Android

TLDR: Are you the passionate about community work and giving back? If yes, you can become too. The welcome email I got today from Google It’ date 02–20–2020.

February 2, 2020

The Best Features in Android Studio 4.0 Beta

A basic overview of most interesting features in the Android Studio 4.0 Beta Android Studio 4.0 Launcher Screen Last week was somehow a good week for Android developers like me.

February 29, 2020

7 years experience. 💻 Creator of various Open Source libraries on Android . 📝 Author of two technical books and 100+ articles on Android. 🎤 A passionate Public Speaker giving talks all over the world.

Источник