Architecture patterns in android

This tutorial is written with the assumption that the reader has prior experience working in Android

One of the widely asked topics in interviews is about architecture and different architecture patterns in Android.

So, what exactly is architecture and why do we need any such thing in Android or any other software development?

A software architecture introduces constraints on implementation and restricts design choices. This reduces the complexity of a software system and prevents developers from making incorrect decisions. If the implementation of an element conforms to the designed architecture, then it is abiding by the design decisions made by the architecture. Software architecture, when done properly, enables developers to accomplish their objectives and prevents them from implementing things incorrectly. Also having a design choice uniform across the codebase helps new developers easily get onboarded to the entire codebase once they are familiar with the architecture pattern used.

Having constraints also leads to less probability of bugs as the developer cant manipulate the code a lot and it helps in achieving things like SOLID principles, DRY(Do Not Repeat Yourself), and Unit Testing as well.

So now, when we are clear about why do we need architecture, let’s discuss a bit about what are some of the architecture patterns widely used

Clean Architecture (By Uncle Bob)

Clean architecture has the objective of separation of concerns, which is achieved by dividing the software into layers.

So let's understand this via a simple example which we use in Gojek partner app.

Our architecture consisted of four main layers — data layer, domain layer, presentation layer, and the UI layer.

The “data layer” talks to the framework directly and is responsible for managing all data-related operations in the app like making network calls, accessing the database, reading/writing files, etc. We use the Repository Pattern in our data layer to manage multiple data sources easily.

The “domain layer” is responsible for holding the business logic. We ensure that this layer has pure Kotlin code and we do not introduce any framework-related dependencies in it.

After that, we have the “presentation layer”, which takes care of all the presentation-related logic in our app. We try to keep all these layers free from any framework dependencies so that we can exhaustively unit test them.

We finally have the “UI layer” which mostly comprises the activities, fragments, and other custom views. This is the layer with which the user can directly see and interact. We try to keep this layer as dumb as possible and push all of our logic to the other layers.

For more information about our architecture, please check out this blog by our architect Aritra Roy on our rewrite.

Essentially clean architecture consists of concentric circles where each circle represents a layer and the innermost circle represents the entity layer which consists of business logic and the outer-most circle represents the UI layer which is the actual output on the devices which the user sees. This enables us to properly test like we can have UI tests using Expresso for UI layer as unit tests wouldn't help much here and for other layers, we can have unit tests that have all the logic.

Now we would discuss the three most commonly used architecture patterns in Android i.e MVC, MVP, and MVVM. Please note that these patterns can be used alongside clean architecture and using one of these patterns alongside clean architecture would be the perfect combination and would make the code more scalable.

1. Model View Controller (MVC)

So in the MVC architecture model consists of business logic like an API call or storing something in the database, and here model interacts with the view directly to update it.

Let's understand this with an example, let's say we are designing a mobile app that shows top-rated movies, and clicking each movie item expands to a new screen that shows all details about the selected movie.

So here Model layer in our codebase would be responsible for calling the API for top-rated movies, and when the API would return with a response, the model layer would call the view layer directly to show the list of movies obtained using the API. Now when the user clicks on a movie item, the view layer sends the input from the user to the controller layer i.e view layer would have a setOnClickListener() which would call the method of a controller, something like controller.showMovieDetail(movie Movie). Now the controller would manipulate the model and would call its method that deals with calling the API for fetching details for a particular movie, and on successful response, the model would update the view to show the expanded details of the movie.

2. Model View Presenter (MVP)

This is an extension over MVC architecture where the controller is replaced by the presenter and the model can no longer update the view directly hence totally separate business logic and UI logic. Here model and view both interact with each other using an intermediary layer called the presenter. So this ensures separation of concerns and helps us in unit testing and dependency injection as now the model doesn't need to know anything about the view can contain pure business logic facilitating testing and reducing the probability of bugs.

Now let’s discuss how we would implement the same example discussed above using MVP

So this would be the flow chart of actions for the first part of our problem using MVP architecture

View (Screen Opened) -> Presenter (Fetch Movies) -> Model (Call API) -> Presenter ( Update View with Movie List) -> View (Show Movies)

The flow chart of the second part which deals with showing details for a particular movie would be as follows:

View (Item Clicked) -> Presenter (Fetch Movie Details ( movie Movie)) -> Model (Call API) -> Presenter (Update View with Movie Details) -> View (Show Movie Details)

Companies like Uber uses MVP with clean architecture in an interesting way which they call RIBS architecture. Interested people can read more about it here

3. Model View ViewModel (MVVM)

This is the framework-supported architecture pattern, i.e it is quite similar to MVP, i.e the responsibilities of ViewModel are quite similar to a presenter in a way that it is responsible for interacting between View and the Model. But the android framework itself gave a component ViewModel which can be used as a coordinator which is lifecycle aware and can hold data for configuration changes. So using a ViewModel it's quite easy to handle lifecycle-related changes i.e when the app goes away from the foreground let's say when a phone call comes or moves to the background or some changes in configuration, i.e changing from portrait to landscape mode.

Interested readers can check how Shopify uses MVVM with clean architecture here

Thanks for reading this!