The death of Presenters and the rise of ViewModels (AAC).

Hello everyone! 👋 In this story I will quickly go over ViewModel and LiveData from Android Architecture Components (AAC) and will present you with some perks you should consider.

First of all, why would we want to use AAC ViewModels with LiveData to ditch our beloved Presenters? ❤️

ViewModel preparing for the fight.

ViewModel survives rotation & other configuration changes.

ViewModel keeps running while the activity is on the back stack.

ViewModel is Lifecycle agnostic. You can override onCleared (to clear disposables for example) just before the ViewModel is about to get killed.

ViewModel promotes simple and concise code.

ViewModel promotes reactiveness based on state down to the view by letting the view observe the live data inside the view model.

ViewModel promotes immutability.

ViewModel promotes testing.

Let’s imagine a simple example for those who haven’t done anything related to AAC ViewModels and LiveData from Google. 👯

1. First, we add these dependencies to our build.gradle ✔️

2. Then, we create a class named CounterViewModel that extends ViewModel class from AAC. ✔️

counter is a MutableLiveData of type Int.
number is already initialized to 0.
onButtonClick() will add +1 to number and set it to counter.

To push data to MutableLiveData we can use setValue (when we are on the main thread) or postValue (when we are on a background thread).

The postValue will just post a task to the main thread and there is only one so be aware that posting several values before the main thread executes will only actually post the last value. 😅

3. Finally, we create a new Activity. ✔️

ViewModelCounter is obtained through ViewModelProviders which might be an existing one or not depending if the Activity has just rotated or suffered any other configuration changes. 😲

The counter : MutableLiveData<Int> is now being observed 👀. Whenever we start observing LiveData with an existing value or the data changes while being observed the method inside the lambda will get triggered (in this case we are just setting the new number to a text view).

The ViewModel will keep running when your activity is in the back stack. 😲

• Any API call from your ViewModel can finish while your screen is in the background. ☑️
• When you pop back to this screen it will update from the latest value inside the live data. ☑️
• You should pause any continuous stream of data to avoid unnecessary waste of bandwidth while you aren’t displaying this data. ☑️

4. To end with let’s test our ViewModel. ✔️

The test rule is to make sure our LiveData postValue() method runs instantly in our test. In this specific case it isn’t needed because we are using setValue() in the CounterViewModel implementation. 👍

setUp will create our ViewModel and in our test we will just call the ViewModel method onButtonClick() and we just check the new value of our MutableLiveData which is the counter.

In a more realistic example testing would look pretty much the same but everything external that the ViewModel uses (use case or repository directly) would be mocked and under the given you would tell the mock what exactly to return when it is called with any specific parameters if any.

🔚

Easy right? Let’s imagine a more realistic example.

Fetch and display a list of GitHub users.
When loading, show a loading indicator.
When data is ready, show the users in a list.
When there is any error, show a snackbar with the error message.

Breaking this down we can think of 3 states:

We will also have the data and the error message which might be optional.

To end with, we will create 3 extension functions to improve readability & to help carry out the data object throughout the different states (if present).

This is really useful to make sure that during a Loading/Error state (after any configuration change) any previous data is carried out to the new state.

Let’s see an example of UserListViewModel class.

We made users of type MutableLiveData<Resource<List<User>> and we will push values to this with these 3 functions (depending on the case).

From the activity we will then observe the LiveData users and will control the loading visibility, displaying data and error handling with a method like below! 👇

Done! 👏 👏 👏

sanogueralorenzo/Android-Kotlin-Clean-Architecture

You can check my sample app by clicking up here ☝️

In case you are wondering how ViewModel with Dagger2 looks like: https://proandroiddev.com/viewmodel-with-dagger2-architecture-components-2e06f06c9455

Remember to follow, share & hit the 👏 button if you’ve liked it! (:

GitHub | LinkedIn | Twitter