When to load data in ViewModels |
![]() |
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.
Navigating through a Reactive Android MVVM — Chapter 2
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
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 opportunitiesIf you have been an Android developer for some time, I guess you have heard about two interesting concepts:
The way I decided to solve these two problems is by having three components:
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.
Modeling through sealed classesPay 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 layerHere I decided to split this in three components:
Other layersEvery 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:
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 funFor 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 could feel all of these problems were solved here.
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.
Android News
droidcon News
Tech Showcases, Developer Resources & Partners
EmployerBrandingHeader
jobs.droidcon.com
![]() Latest Android Jobs
Kotlin Weekly
![]() Your weekly dose of Kotlin
ProAndroidDev
![]() Android Tech Blogs, Case Studies and Step-by-Step Coding
Zalando
![]() Meet one of Berlin's top employers
Academy for App Success
![]() Google Play resources tailored for the global droidcon community |
Droidcon is a registered trademark of Mobile Seasons GmbH Copyright © 2020. All rights reserved.