I have been working as a software developer for around 10 years, and during those years I have been looking for patterns and the perfect architecture that will help me to build any kind of product. You will find even in social media that well known developers in the community will have different opinions on what that perfect architecture is. I am not sure if we will ever find the perfect one, but in the meantime my intention is to aim for something that will make life easier in the different aspects of making software.
What is this about?
In this story I will present you the architecture I use for my projects. My intention is to talk about the different concepts involved rather than explaining how to use the framework that is part of this example (RxJava2). Reactive programming is not about any technology in particular, and that is why I am planing to write a Chapter 3 where I apply the same concept with Coroutines.
Here you will find the repository. There you will find how I connect Android MVVM along with RxJava2 in a way that
- The UI is in charge of exposing the different states of the application.
- The View model is responsible of connecting events coming from the UI or external components with the business layer, and sending the states of the application to the UI in a way that the View is only responsible for translating the state into a UI component.
- The business layer is divided in different components in order to apply separation of concerns and reusability, while making the application friendly for unit tests.
- Making the most of sealed classes to represent the evolution of the different states that a View can have.
I think you will find here many similarities to the MVI pattern.
I would like to mention that this post is the second part of a trilogy (what?). You will find the the first post here.
Chapter 2: A world of opportunities
If you have been an Android developer for some time, I guess you have heard about two interesting concepts:
- Memory leaks: happens when your code allocates memory for an object, but never deallocates it. This can happen for many reasons, in my experience is because a GC root is having a reference to an Activity.
- The view should be as passive as possible. The main benefits of this idea is that you may end up with a more maintainable code, and it will be easier to apply unit test to the logic you need to run.
The way I decided to solve these two problems is by having three components:
- The View container: Activity or Fragment.
- The UI: a class that will implement the View interface and will need an Android view in order to exist.
- The View model: the well known view model I guess everyone knows at this point. If not, just google “Android view model”.
Here the View container will create a View, bind the view with the view model and let the view observe events and states coming from the view model.
The bind function will be used to listen for events coming from the UI (user interaction or whatever event the UI needs to emit). This function will return a compositeDisposable that the view container will clear when it is needed. This way we address the first concept I mentioned — memory leak.
The events and UI states coming from the view model to the View will contain all the information that is needed to be presented to the user. This information will contain android component content such as color id, string resource id, view visibility, etc. In this way we address the second concept — The view should be as passive as possible.
It is important to know the difference between events and UI states here as each one has a different purpose.
- UI states are those which need to show the state of the UI (really???). Think about it as a list of transaction, and loading component. The view needs to show this state constantly, after a view recreation or when the user comes from a different view.
- Events are those which need to be shown once and then forgotten. Think about it as a toast message, snack bar, transition to new views, etc. In the repository you will find examples of this.
Modeling through sealed classes
Pay attention on how the UIModel.State is modeled. There you will see that both Loading and Success are part of the UI state. By modeling this way, you declare the information that will be part of that state. For example, a list of todos will not make sense in a loading state in this case, so instead of adding so much information to the State class, I decided to split it in different states.
The same applies for Effect. You can declare different errors wrapped in a Error sealed class.
Also, I think it is a really good idea to consider this to other parts of your architecture if it makes sense. For example, imagine having a transaction which will have different states, so instead of having something like this:
You may have something like this:
The business layer
Here I decided to split this in three components:
- Manager / Use case / etc: This class should be used when logic that is not related to fetch / push data is needed, such as process payment, process orders, upload file that will need some validation (the manager will apply the validations and then call the repository to upload the file), etc. The idea is that this class will be reusable, so that you can interact with it from many view models or from a foreground service, etc
- Repository: This class will provide information coming from different sources (DB / Network). This should provide the information in a way that the consumers do not know anything about where it is coming from. This way, potential changes in the logic will not affect the rest of the components.
- Model: The model that defines your business like transactions, payments, users, etc. This model is used when data is coming to the manager no matter where it is coming from. This means that the view model and the repository will send a business model class.
Other layers
Every layer applies its own model. For example, you will have a TodoDB for the model in the database, a TodoDTO for the model in the network, a TodoUI for the model in the view. The idea is that every model have the meaningful information for each layer, and that every model knows how to map itself to a business model. Here you have an example of the different models for the Todo class:
The reasons of having these different models are:
- To have a better understanding of each layer: in this example the network layer do not know anything about Todo in progress. Also colorState and inProgressUpdateViewVisibility only makes sense in the UI, not in the business or network layer.
- To apply the libraries where they make sense: With this I mean that I should use parcelize in the UI layer because that is needed in order to put things in a bundle, which has nothing to do with the other layers. The TodoDTO uses the annotation JsonClass from moshi, which does not make sense to be applied to the other layers.
For the mapping part, I opted for extension functions. So here you have an example of mapping a Todo to a TodoUI:
Testing: time to have fun
For me it was always hard to make unit test, and I am not talking hard in a technical perspective but in a waste of time sense. The reason why I say “waste of time” is because:
- I had to deal with robolectric sometimes in order to test some logic that somehow was important but connected with an android component.
- Couldn’t decide what to prioritize for testing when times were not so flexible so I could end up not covering important parts of the apps.
- Sometimes unit tests where a mixed of UI with business, making it hard to isolate the test to make it better to understand.
I could feel all of these problems were solved here.
- By not using functions from android components in the view model and layers below, lets me apply unit test using only JUnit.
- Removing logic from the UI, gives me the possibility to cover huge portions of the app without even thinking about android contexts.
- Having a clear definition of responsibilities in each layer, gives me the opportunity to decide where to apply unit tests first. In my case I would apply unit test first in the view model and manager, leaving repositories to the end in case of lack of time (yeah, I am not the kind of guy who will apply unit tests to getters and setters #sorrynotsorry)
I welcome you to give it a look at this test in order to have an idea how I applied testing to the view model.
I hope you find this helpful somehow. I think it is important to mentioned that this was the result of working in different project, reading different posts and talking to colleagues.
Some of the posts that where really helpful:
That is all I have to share for now until Chapter 3. But before that, I will celebrate that I could write two posts in less than six months.
