Photo by Etienne Girardet on Unsplash

What you do, if your class becomes fat? You usually try to split it to several pieces, extract common methods to interface, and so on. I’ve seen many projects with great architecture, SOLID principles implemented, high code coverage… However most of them has terrible configuration files.

Maybe there is a way to treat your configs more like you treat your production code? Let’s find out.

build.gradle & app/build.gradle

When we are starting new project, Android Studio creates two build files — project level build.gradle, and module (app) build.gradle.

project build.gradle

module (app) build.gradle

As we develop our app, the dependencies block can become huge.

In short words — a lot of ugly dependencies, and sometimes comments what does specific library do, because not all of them has meaningful names.

Forget about wondering what specific dependency does and why is it even in the project. We will try to make build.gradle human readable and developer friendly.

Define variables in gradle

First thing what comes to mind is to extract Retrofit and OkHttp versions to variable — if we change version of library, we will change version of every lib module.

libraries versions extracted to variable

Ok — it is little bit cleaner now. But can we do better? Yes! Let’s introduce layer of abstraction for network dependencies. In gradle scripts you can use Groovy data structures:

network dependencies in separate block

We can go even further — extract dependencies definition to separate file.

To achieve that, create file named dependencies.gradle with following structure:

dependencies in a separate file

And then attach it to your build.gradle using apply from. You must provide relative path.