Well, dependencies, flavors, sourceSets, versions.. All fly around in our build gradle files, right ?

Let’s tidy it up a little bit and make ourselves a helper dependency file which’ll make versioning things around the project easier and make our gradle files look tidier by grouping dependencies.

Let’s not use the root build.gradle file for the extension, instead, create a new folder on the root and name it anything you like. I think scripts would be a suitable name.

Let’s paste it under scripts. In this screenshot, “dependencies.gradle” is the file I’ve been using for a while now.

I’ll be giving what it looks like down below. You can create a new .gradle file and paste it and modify as you like. But before that , let’s complete one last step, apply it to our root build.gradle. Just open it and type

apply from: "scripts/dependencies.gradle"

Aaaaand we’re ready to use our gradle file. Beware, you should update your path, if you change naming or where the file is later on.

Now, it’s a bit long but there’s a little to tell about it. What I have is 3 different arrays. One is versions, the other is libraries and one for testLibraries ( just because I wanted to separate them :D )

Versions array also has library versions, so when I change it from here, all dependent library versions are upgraded.

Now, let’s see how build.gradle looks after using this values here:

Some Benefits

But what are the benefits ? This is not a “super duper awesomeeeee” thing but still keeps things tidy and easy to manage.

You can group dependencies as an internal array, you can name it anything and add any dependency in those

retrofitRx : [ “com.squareup.retrofit2:retrofit:${versions.retrofitVersion}”, “com.squareup.retrofit2:converter-gson:${versions.retrofitVersion}”, “com.squareup.retrofit2:adapter-rxjava2:${versions.retrofitVersion}”
]

I believe just adding libraries dependent to each other should be implemented as one tho. This’ll make your dependencies look tidier and grouped.

Let’s say I have 5 modules and I’m using same minSdkVersion in all of them. By using versions.minSdkVersion, when you change minSdkVersion on your dependencies.gradle, all of them will be changed.

Also, implementing libraries and versions from one place will ensure I’ll be using same versions of libraries on all modules, as well as same configuration versions.

Better then opening up all the files and typing all over huh ?

Drawbacks

There are also couple drawbacks. First of all, you should change all the fields to “versions.whatEverItIs” manually. Tho you can create some live templates to solve this.

There is no autocomplete. It’ll autocomplete “libraries”, “testLibraries” or “versions” array names, but it won’t suggest / complete values you wrote in them.

But biggest drawback is, you should check library versions. I generally do this before I add a dependency and update the file accordingly. The “Project Structure” won’t show your dependency when added this way and won’t generate a message about new versions. I don’t know why tho. I asked it on StackOverflow here, waiting for answers.

P.S.: I used to have a warning here about Android Studio is not asking for a sync after updating anything in this gradle file. As of Android Studio 3.2, any change made on external gradle file causes Studio to pop a “sync now” warning. Still, just in case, keep an eye on the External Libraries if the versions are correct.

Well, that’s it. Have fun with your gradle !

P.S.: I couldn’t find a proper way to add “exclude”, “annotationProcessor” or “implementation” commands to file I prepared. That’s why I add “AP” suffix at the end of annotation processors. If you know how, let me know !

Android Engineer @IKEA