ViewModel: What, Why & How (Part-1)

I know…I know, you might have heard a lot about ViewModel during your learning phase. I got to know more about it during my ongoing Internship with HealthifyMe and trust me, it is such a saviour. It is highly used in the Android World plus without this, learning Android Architecture is going to be so confusing. But no worries, I’m here to the rescue :)

So, without any further ado, let’s hop into the material:

Part -1 is focused on What and Why.

Part -2 will focus on the How part of the story.
(Building a small project basically)

(Feel free to jump into any of the parts)

What is a ViewModel?

ViewModel is a part of android architecture components(More on android architecture in a different blog). ViewModel class stores and manages UI data in a lifecycle-conscious way.

But wait…! Why we need a view model when we can use onSaveInstanceMethod(). Let’s find out.

Why ViewModel?

The primary reason would be to survive configuration changes and not lose data.

During configuration changes, the activity recreates itself i.e. onDestroy() gets called, then again onCreate() is called. Hence, any change to the activity’s view like changing value of textView will be lost and it’d change back to its default value.

ViewModel comes to the rescue.

ViewModel objects are also lifecycle-aware i.e. they are automatically cleared when the Lifecycle they are observing gets destroyed permanently. Henceforth, viewModels are not destroyed if the activity gets recreated... its instance remains (Except on low memory situation, keep an eye on this).

Here’s a diagram to help you visualize as how things work:

ViewModel’s instance is destroyed when onCleared() is called.

Yes… onSaveInstanceState() can save the data and then it can be restored from savedInstanceState bundle in onCreate() method. But, this is suitable only for simple data…not for a data which contains a list of users, employee or any other large amount of data.

Second reason as to why ViewModel is that it helps in pursuing separation of concerns. This is one concept which is religiously followed in Android Architecture like MVVM.

Overview to this concept would be delegating the tasks and not overloading the activity or fragment classes. According to the Android Architecture, UI…UI logic…Business logic should be contained in separate classes. UI contains activity and fragments whose sole purpose is to display the data.
ViewModel contains the UI logic i.e. it takes the data that needs to be displayed in UI components.

Third reason would be better testing. Since, each class would be responsible for something, it is way easier to run tests with more than 70% of code coverage.

Important Points to take care of …

* ViewModel does not know to which view it’s setting the data.

* ViewModel notifies UI through observers like LiveData.

* ViewModel should not contain any reference to a view. This may cause memory leaks since viewModel has a different lifecycle scope than activity & fragments.

* Extend AndroidViewModel if you still need to use context in your code. We can pass application context to AndroidViewModel.

I’ve created a simple project to explain how the viewmodel retains its state during configuration changes like screen rotation.

Thank you for reading! Please give it a clap, this would motivate me to make more of medium blogs.
Until then, Happy Coding :)