Basic concepts of software architecture patterns in Android
As I mentioned on my previous article on Medium (Do you want to start in Android development? I tell you my story) …
I strongly recommended reading and learning about software design patterns and architectures for improving your Android development skills. I want to clarify that this article is based on my experience and things that I’ve learnt by having different projects (personal and for companies) that I helped to develop.
Is very common to start using MVC (Model View Controller) as the default pattern for developing Android applications and probably not well used. But…
“Why is important to learn about different patterns? The answer is simple: all of them make your app scalable, maintainable, testable and allow you to write high quality code.”
But what is a pattern in terms of software development? Well, a pattern is like a model that has been created to solve a problem that occurs concurrently, thus allowing developers to follow a structure so that they do not have to solve it from scratch, but rather by guiding themselves on something already existing and previously tested.
An architecture pattern allows us to define a guide for the ‘architecture’ of a software system, making it scalable, maintainable and testable. Differing from design patterns, these have a major abstraction level.
Note: this could be a controversial topic because some developers clarify that MVC, MVP, MVVM (or any other) are not architecture patterns but design patterns for the presentation layer (because the true architecture as such is ‘the layers architecture’).
MVC (Model View Controller)
Let start with the most basic pattern. Model View Controller concerns about 3 layers that allow you to have control about the model and user interactions separately. However, it’s not the best option and I’m going to explain why.
First, you need to understand what’s the meaning of every component of this architecture and this will helpful for getting concepts from the next patterns that are going to be mention on this article.
- Model: contains models of business logic, i.e. the classes that will model the solution for the problem and objective of the application. For example, if you are developing an app for a library, the ‘Book’, ‘Author’ and ‘PublishingHouse’ classes should be in this package. All of them should be independent from any Android component.
- View: is an interface that is going to be implemented by all the UI views, that’s it. Activities, Fragments, Adapters, Dialogs, etc. All of these are in this package and are responsible on displaying the data to the user.
- Controller: is responsible for ‘listening’ user inputs and update the model and the view. Normally, the view and controller are involved in the same java class, I mean, an activity accomplish the functions as a view and controller at the same time because it is listening (for example) user clicks and shows answers for them. The best idea is to have the controller in a separate class. However, this relationship makes the activity hard to test because the Testability best practice is not being used and we have user interactions and view responses at the same class. Moreover, the view and the controller can both access to the Model, which is not a good practice at the end because you have the model relationship with more than one class and this is not (too) scalable.
MVP (Model View Presenter)
This was my favorite for a long time. It separates your code in three main layers which allow you to have different abstraction layers for different responsibilities.
- As the MVC pattern, the Model is responsible for having business logic and communicate with the data source (sometimes a Repository layer is added to this pattern to make the data independent from any source, e.g. Realm, SQLite, REST or Firebase).
- The View is the interface that your activity or fragment java class will implement. It will contain certain methods for view actions, like fetch a list, show a progress bar, hide sub views, etc.
- The Presenter acts as a communicator between the View and the Model (I like to call it as a View Logic manager too). It will handle view actions and will make a request to the model, when the model has finished the work it will send a response to the presenter and then it will call any of the view methods for show the answer to the user. Most of the ‘if’ conditionals for view behaviors are here.
Is very often to use java interfaces for having a model of every layer. This is very important because when a requirement totally changes you can use the interface for creating a new one inheriting from the original or simply create a new implementation for it.
For example, the application must have a functionality for showing a movie list. The main (basic) UML should be something like this:
The View instantiate a presenter implementation object and calls loadBooks() method. The presenter calls showProgressBar() view method and calls loadBooks() model method. The model will use its data source for retrieve books list and when a response is gotten it will inform to the presenter calling its onBooksLoaded() method passing the list as a parameter for finally pass it to the view and then fetch it to an adapter for showing to the user. However, what happens if we want to load the list of books of a specific author? We simply should create a new interface inheriting from ShowBooksPresenter and add the method loadBooks(String: authorId) and then implement that new interface. So, the new UML Diagram is like this:
We have created a new ShowBooksModel implementation: ShowAuthorBooksModelImpl. This will have an attribute (passed inside the constructor) that will be the author id. This model is going to implement the loadBooks() method but using the author id attribute value.
Clean Architecture
About Clean Architecture, there is no a rule or specific layer-best-implementation, it depends on your requirements, time, resources, etc. Clean Code is something that Uncle Bob talked about on his blog many years ago:
In my opinion, when we refer to clean architecture, we are referring indirectly to SOLID principles for high quality software development. If you want to read about it I recommend this fantastic article of Arthur Antunes:
Clean separate your project code in three main layers:
- Presentation Layer: Here all the logic from the view is regarded. You can implement a MVP, MVC or MVVM (Model View ViewModel) pattern (remember the note at the first part?). Inside the model I like to put my business logic models like: Car class, Book class, User class, and others, but it format to be consumed by the views. Classes are tested using Espresso, Robolectric and many other instrumented unit test frameworks.
- Domain Layer: All business logic is implemented here. This layer is totally independent from any Android API or framework, i.e. is like developing your application as a simple Java (or Kotlin) project. You can test all of the classes here with local unit tests.
- Data Layer: All data is gotten from here. You can implement a cache strategy, repository pattern and data sources classes on this layer. SQLite, Realm, Retrofit, Sugar ORM and many other libraries are used on the data layer.
When you read about clean probably an onion graph is going to be shown on every site you visit. Well, that is like ‘the default layers’ but there is no a rule for it. However, there are some minimum packages implementations you should keep in mind and that I recommend for having a scalable application. I will show my common Clean Architecture package structure I use for my android projects:
- Presentation: where three main packages are located: model, view and presenter. Of course, you can use any other structure like: view, viewmodel, and model.
- Domain: here I create a model package for the main model classes and its mappers, a repository interface (that will be implemented on the data layer), and interactors packages that will contain all Use Cases classes.
- Data layer: it will contain classes for the repository pattern implementation. It also can have model classes but it depends on you if want to have more classes because you must use a mapper for passing objects to the domain layer.
I created a sample in Kotlin and uploaded it on Github, check it out:
Conclusions
In fact, there is no a specific architecture implementation you must use. All depends on your business requirements, time, software team, resources, etc. I like to use MVP when I do not want to write too much code; on the other hand, I like implementing Clean Architecture when the project is big and changes could be requested on the future.
If you want to implement Clean, you should do it thinking of your application scalability, size and many other factors. Do not use it as a dogma. Implementations depend on your requirements! The same for MVP and many other patterns. First the context and then code.
In the end, the goal is to separate your code into layers in such a way that you make it testable, maintainable and scalable.
Patterns will help you to do not reinvent the wheel and also, having maintainable code. Every developer should learn about this for creating really good code and as an old quote says:
If in a year you read your code and it does not disgust you, something is wrong.
Is something that am I missing? Please add a comment, I will really appreciate it!
References
Uncle Bob. (2012) The Clean Architecture, retrieved from: https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
Antunes, Arthur. (2016) SOLID Principles: The Definitive Guide, retrieved from: https://android.jlelse.eu/solid-principles-the-definitive-guide-75e30a284dea
Sánchez, Jorge. (2017) Consejos sobre Clean Architecture, retrieved from: https://blog.kirei.io/consejos-sobre-clean-architecture-98df898b8068
Jhordan Rey, Erik. (2016) Aplicando Clean Architecture en Android, retrieved from: https://blog.kirei.io/consejos-sobre-clean-architecture-98df898b8068
