What are the benefits of a multi-project build in Android?

Question

I'm reading the source code of Android : Clean Architecture, mostly to learn how to properly organize an application into layers, and for the MVP pattern, and also to match it with what I've been reading on MVP here.

However, as pretty as I find the structure, I don't really understand the benefit of order a single application into multiple sub-projects or modules. Considering they (data, presentation, domain) depend on one another, and eventually will be part of the same executable, it looks more like configuration hell.

dependencies {
  ...
  compile project(':domain')
  compile project(':data')

What are the benefits of compartmentalizing an Android application into multiple subprojects (modules), rather than keep them in one project but separate them merely by packages?

Suspicion

it's more about helping you define the lines between layers (circles) in your architecture. If you try to add something to a certain module that does not have the correct dependencies it will stop you doing so and therefore you will conform to the architecture – Doubt

Answer 1

Actually this question is not Android-specific but more software architecture related as it applies to almost any software you develop (e.g. why does any app consists of several modules and not all in one package).

Splitting the code into modules would provide you at least the following benefits (these are the first 3 that comes to my mind):

1. Clear isolation between the modules. The whole goal of the MVP pattern is to make sure your business logic and presentations layer are not tightly coupled together. By defining these in different modules it makes this separation more clear and encourages you to stick to this pattern.
2. Code reuse - consider the case where you have one application that you'd to sell for several customers, but each of these customers would like to get a different look and feel. If you'll have all of your code in one monolithic project you'll have to either have many forks of your project, one for each customer or otherwise bloat the provided app code with the customization options. Now, if on the other hand you had separated your modules, then you could just prepare a different presentation layer for each customer and bundle it with the other common modules.
3. Splitting your project into sub-project allows more efficient build and testing as you can rebuild and test only the modules that changed rather than recompiling the whole project whenever there's a change in one of the files.

I hope that this makes sense to you.

Lysander

1 and 2 yes, 3 .. not so much with gradle sometimes the multi-module approach actually slows down the build [my opinion - to lazy to ref] – Doubt

Yet you got the option to build just specific modules (e.g. gradlew -p submodule) instead of the whole project. Also, in case of the scenario described in #2 then you're going to compile the common code just once for all distributions rather than recompiling the whole code base for each app flavour. – Lysander

@AmnonShochot 1. - goal of the MVP is not separation of business from presentation logic. It is to make concerned with presentation layer only and the gaol is to make the view logic testable. Separation of business logic from ui (presentation), data and other layers is achieved by implementing the layered architecture. – Daric

Answer 2

The main benefit of using multi-module projects, instead of just packages, is that the code usage between modules goes in one direction only.

Any code inside the module can have a back-and-forth relationship:

A -> uses classes from -> B

and

B -> uses classes from -> A

If A and B are in separate modules, this only goes one-way:

A -> (uses classes from) -> B...

But B can't see anything in A.

This splits up your thinking into smaller, bite-sized chunks. If you need to understand how a class in module B works, you only need to look at the other classes in B. But in the first scenario, you have to look at the all the classes in both A and B.

As an added bonus, if you do want to reuse any code, you can copy that module right over to the next project.

I usually put the bulk of my code in modules, with a thin app layer connecting them all together. I recommend using dependency inversion to make any connections between modules.

Impunity

even though what you mention is true. you can not have dependency in both directions with modules (this is called circular dependency). you can accomplish the same thing with packages. so this is not an advantage at all. this is called poor design. there are many different scenarios where you can use modules. one important advantage to mention is that if you create a library module that will be used by the rest of the app. Then when you compile, if your library module was not modified, it won't have to be recompiled. This could save you lot of build time. (among other usages of modules) – Uball

Answer 3

Another Android specific advantage of splitting into modules apart from faster build time is that the update size of your app will be less.

Pother