Build a Modular Android App Architecture

This article is a summary of the “Build a Modular Android App Architecture” presentation from Yigit Boyar and Florina Muntenescu in Google I/O’19.

In Google I/0 19, they talked about how to create a modular Android Application architecture. They emphasize the fact that developers should be segregated to specialise in different aspects when developing the application in order to provide a clean and organised application.

Faster Compilation

If you have a monolithic layouts folder, it’s going to be very hard to look at it and understand what’s going on.

Instead, If you group those layouts, it will be so much easier. When you’re looking for something, you’ll find it there.

By the way, you have this monolithic application on the left and the modularized application on the right, if you want to change the same file in both of these scenarios, this is how it’s going to invalidate.

Faster CI

It is possible to run your continuous integration service faster by having small modules which have bigger modules depending on them. For example, if you need to test module 5; you would only need to run the modules that depend on it. As the other modules are not impacted, there would be no point running any other module.

Good for Business

From the Play Store statistics, it has been determined that the number of users drops between the moment they install the app and the moment they can start using the app. To prevent this; you can modularize your application with app bundle in order to reduce the installation size.

Module

The Android App Bundle packaging concept involves the greater library modules as well as the dynamic feature modules. For example, we can have a base app which is dependent on module 1, also known to be the android library. This means the app can reach the code and resources from module 1. Furthermore, we can have other modules i.e. module 2 and module 3 which can be the dynamic feature modules. These can be used for on-demand code loading via dynamic delivery.

Developers are able to decide the dynamic feature module based on the 80/20 principle that state; “80% of the users are using 20% of the app”. This way it is wise to look into the un-used 80% features that are not part of the core flow of the app. These un-used features can be downloaded and/or uninstalled later which would make the on-demand false, cleaning up more space within the app.

Layer Modularization

We have two options to modularize our application. One of them is based on features, the other uses a layer modularization. The two options have different advantages. Let me put it this way, feature modularization provides you encapsulation, and also the possibility of on-demand delivery. On the other part, layer modularization provides you isolation, allows you to isolate your third-party dependencies or the layers in your app, and also brings structure to your app. By the way, you can use both together, however, if you have a monolithic application for your app, you should use layer modularization first, as time goes by, add the feature modularization.

Working with Dynamic Feature Modules

Working with dynamic feature modules brings a few challenges even if you use on-demand delivery. One of these challenges is with navigation. For example, we have the MainActivity and want to navigate to the AboutActivity.

Normally, you can navigate something as above but you’ll get the compile error. To overcome this, what you can do is just use Intent.setClassName and pass the component name.

I know this looks a bit strange because it’s hardcoded. And indeed, it means that when you have to refactor your code, you need to make sure that you’re also updating this string.

Discovering Dependencies

You can skim through the structure that I will tell you through the following images. For example, we have a search activity that is part of the search module, and we want to be able to search for news in Designer News and Dribble. However, Designer News, Dribble and search are three completely different modules, for this reason, we don’t know how to do it.

We should use the Common Core library that is shared between all of these defining the DataSource interface implemented by the Designer News and Dribble. Thereafter, the search holds a set of these DataSources and knows how to query the data. But things are not that easy because there are a lot of classes that you need to instantiate when you create a module.

Databases

When you start modularizing your application, you will probably face problems with databases, which you can solve using two different ways. One option is you can just have one database for all of your application, which is what you usually do when you’re in a monolithic application. The other option is creating a core database for the common functionality, and then have separate databases for your features.

Android Free Modules

Android free modules have advantages and disadvantages, the first of the advantages is that you could reuse the modules. We need to implement only a unit test for having Android free modules.

When you read about the architecture and the theory around architecture and clean architecture, one of the things that you’ll see, one of the guidelines is that you should minimize dependencies to make sure that you’re not depending on classes that you’re not using. This also means that you’re able to do a clear separation of concerns, making sure that your business logic doesn’t depend on any UI classes.

If you would like to watch the video this topic is about you can find the link below.