The world of software engineering is becoming more and more fascinating as the teams expand in size, the scope of the project gets more extensive, and there are many opinionated solutions that are designed for any tech requirement. When it comes to Android, you notice a lot of trends, libraries, and architectures around the world that are attempting to solve specific problems. As the owner of Android, Google itself also comes with many suggested and opinionated conventions of implementing principles. So, Should we go with the flow, or should we rethink our custom business implementations?

One of the main controversial topics of Android development is Modularization. Back then, it wasn’t strange at all if your project had only one app module. You would have to concentrate on your app’s layers, separate them and follow some principles of some famous architecture. But these days, maintaining the projects is getting out of hand when you have a big team working on a monolithic project that confronts many issues like build time, code conflicts, and running your app per change. Because no matter your project is designed with the most cutting-edge architecture in the world, you might get frustrated while developing and running a huge project.

This article aims to give you a big picture of turning a big monolithic project into a multimodule one, clarifying the complicated situations that challenge your team while starting the Modularization tasks.

Modularization Mindset

Modularization was one of my favorite topics in Android, and not only did I read the blogs about how to modularize, but I also watched approaches of well-known companies like Square, Spotify, Airbnb, Soundcloud, etc. for modularizing their android apps. So Before jumping to the details of how to implement the modularization techniques, it made me think of sharing some fundamental topics that help to know what you’re getting into. Let’s make a long story short.

There are many reasons for Modularization:

• Build time: It takes forever and a day to compile and build your project.
• Reusability: You need to share some of your Features among multiple apps.
• Maintenance: There is no Separation of Concern. A big, spaghetti codebase that each Feature has many side effects on the other ones. also, it appears that your colleagues are not into respecting SOLID principles in action and be willing to open PRs that contain logic that accesses the world as a whole.
• Test: You can’t write a simple test scenario for a self-contained Feature, and you need to mock the whole world.
• Demo Apps: You are fed up with running the entire project for a slight change, and you have no idea how to run only a single Feature isolated from the whole app.

Fixing all the issues above sounds so cool, right? What about the other side? Is there any reasonable reason for not going into it? No! You have to. Do you hate Gradle? That makes sense because Gradle is not so cool at all unless you use it for a multimodule project.

Many people think that numerous Feature modules are an over-engineering thing, and it couldn’t help increase the build time, and it generates a lot of boilerplates. But the undercover point missing is that you no longer run the whole project each time you implement a Feature. In contrast, you implement your Feature, make your tests pass, run it through a small demo app, and then ask your CI system to build a real app for you or your QA team.

Layer vs. Feature Separation

One of the most common ways of Modularization in the old days was to separate the presentation and data layer (aka domain-data-presentation). It took the developers a while to find out that the domain-data-presentation layer was no longer enough to apply Modularization. Separating only these layers will target the small projects, and you wouldn’t benefit from the reasons mentioned above. Because when you develop a Feature, you will touch all the layers, and guess what? You will turn a lot of heads, and all of your layers will recompile every time.

That’s why I want to demonstrate how the incremental build works in the next section. You may be surprised that this layering in your project (without Feature separation) wouldn’t help you have isolated Features.

By incremental build, the build process can run independently in a shorter time than when you only have three modules for your data, domain, and presentation of the entire app. Instead, by Feature separation, you will have more isolated modules, and then you can apply these layers on each Feature module if you are interested. You can read more about these topics here and here.

Gradle Incremental Build

An incremental build is a build that avoids running tasks of building modules that have not changed since the previous build, no matter whether you enabled offline sync or not. It will help if you consider it while wiring your app’s modules. You never know what can come up when a bad wring between internal modules of your project is applied if you don’t see how Gradle works.

A lousy modularization structure will cause unnecessary builds and won’t help you increase the build speed. Gradle marks the cached modules by the “up-to-date” tag, and you can see them while tasks are running in the build output window. But how could the wiring cause a problem in the process of the incremental build? First, let’s find out about the “implementation” and the “api” keywords you usually use in your Gradle. Here is the official document:

api : dependencies which are transitively exported to consumers, for compile time and runtime.

implementation: dependencies which are not meant to be exposed to consumers.

I want to show only an example of a project wiring with a classic modularization structure. I’m sure there are many possible wirings in a project with many modules. But let’s look at one example that I illustrate in the figure below. As you see, we have an app that depends on Feature1 and Feature2 modules. The dependencies between them are defined here. The main point of this wiring is that the Location is exposed to Feature1 and Feature2 as well as the Core module.

//App dependencies in Build.gradle
implementation project(path: ':feature1')
implementation project(path: ':feature2')
//Feature1 dependencies in Build.gradle
implementation project(path: ':core')
//Feature2 dependencies in Build.gradle
implementation project(path: ':core')
//Core dependencies in Build.gradle
api project(path: ':location')
api project(path: ':network')
api project(path: ':resources')

So let’s change a line of code in the Location module. We have an apidependency for Location, and not only dit it exposed to the Core module but it is also exposed to Feature1 and Feature2. So by modifying a module in this hierarchy, Gradle will recompile four modules. You can track compile tasks by searching “compileDebugKotlin” in your build window (the project is written with Kotlin).