Building for scale at d.light Solar, our Android Journey : Modularization [Part 2]

Building for scale at d.light Solar, our Android Journey : Modularization [Part 2]

Single module android applications will most likely do the job and there’s nothing wrong with that at all. But in cases where our applications may grow, modularizing our applications can help us to achieve many things.

Modularization helps the app scale – builds are faster, tests are faster, and it’s easier to understand how the app works. If the app is modularized in a logical way, then individual modules will be the responsibility of a particular team, and when working on a feature, only a few modules would be affected, maybe even only one. This impacts how effectively developers can work on the app. For example, developers no longer have to build the entire app when they make a change.

Furthermore, it helps conceptually group related code in the app, making the app easier to understand. In essence, instead of needing to deal with problems at the scale of the entire app, you can now spend most of your time only considering a small amount of the codebase, which will become increasingly valuable as the app scales. A good feature module should be whatever structure the feature teams find to be beneficial.

Modules will hold features or logical pieces of features, and these are likely to vary greatly in size (although a one class module is probably too small). However, we want to have modules be the smallest self-contained unit of functionality that a person is likely to work on at a given time. That way, a developer sees the highest benefit: they see the smallest possible build time and test time for the amount of code they’re working on.

Another consideration is that you want to avoid having dependencies between your feature modules. Dependencies mean that if you change one feature module, other modules have to be built or tested. While dependencies can be eliminated using the base class trick, it’s something you want to keep to a minimum – it somewhat obscures how the code works and adds an invisible dependency that might come back to haunt you later (for instance, if you run tests based on what modules appear to have changed).

The Application Module

This is essentially the main module of your application and will often be under the app module. It’s likely a module that you’ve already encountered or used at some point during your development career.  It’s usually under the app module, using the application plugin in the modules build.gradle file

Now if you’re building a single module application then this will be the only module-type plugin that you will be using throughout your project. In single module projects, this base module will contain all of your applications responsibilities — be in User Interface, Networking, Data etc

If you’re building a multi-module application, then the application module will still be the installed module, but the way this application module operates will vary depend on what it is you are building.

Common/Shared Modules

You can essentially use these modules to separate out related areas of your project so that they are decoupled from the main module of your project. Let’s call this the core module.

This core module will contain all of the shared business logic, data operations, caching etc that is used by all dynamic modules. In this case, you are promoting code re-use as all of these aspects can be shared between your dynamic modules. Separating core logic can also help to create a clear separation of concerns that makes your code easier to understand, test and maintain across your team

Core modules that contain android framework references will need to use the library plugin:

Dynamic Feature Modules

These feature modules are going to contain specific features of our application which can help us to again decouple different responsibilities. Now, the way that these are defined will depend on the kind of multi-project application that you are building.

Dynamic App Modules can be used to decouple specific features and resources of your application into their own module, to then be used as part of the new App Bundle format which allows us to dynamically deliver individual features to users. This means we can reduce the initial install size of our applications, instead allowing users to download specific features at run-time as and when they are required.

Dynamic feature modules will contain pure feature implementations whilst still having a reference to the base module of the application. The manifest file contained within it has some additional information regarding the distribution of this module.

We can define a module as a dynamic feature module by using the provided plugin below:


I will be building a demo sample with you ground up in the next articles, to try and explain the above concept in a practical manner. Most of what I am blogging about is still work in progress, and I would appreciate PR’s and guest comments on these articles moving on.

Remember to share and leave comments 🙂

Happy Coding!

5 Replies to “Building for scale at d.light Solar, our Android Journey : Modularization [Part 2]”

  1. Hi Code Ninja.
    Is a module similar to a microservice? A development team independently creates a service, without affecting other application features.

    1. Hi Cheppar,

      Modularization is similar to a micro-service architecture, but in the android world. Basically breaking down your one codebase into smaller chunks that can be installed/shipped independently

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.