Handling Configuration Changes

If we have an activity where we show a user profile and we implemented a web service that can return that data as a LiveData, Which we can safely observe without risking leaking over activity, What happens if the user rotates to the device?

But then the new activity starts, which make new call.This is OK but not great, We want retain that data, so the data it holds is immediately available to the next activity or fragment instance. we are already making that reques why remake it?

View Model


Lightweight ViewModel which is all of our effort to take out that code outside of your activities and fragments, and put it somewhere else where you can easily test it.The ViewModel class is designed to store and manage UI-related data so that the data survives configuration changes such as screen rotations.

We create this new class it extend the ViewModel class.Whatever data we had inside the activity, we move it into ViewModel class.   

The very first time you make this call, ViewModel will give you a new Instance.When the rotated activity come back, It’s going reconnect to same ViewModel.

ViewModel is the one which prepares the data for the UI and holds on it.This where the data for the UI lives.ViewModel know how to get that data Usually, it has LiveData.It survives configuration changes.


That’s why we put the data into the ViewModel, and it is also the gateway.You can also consider it as your UI controller only ever talks to the ViewModel to reach to the rest of the application.The ViewModel serves as a data store for UI controller.

ViewModel example

The example uses the Architecture components, Retrofit and the Github API. Requires Android Studio 3.0 canary 1

Android ViewModel

Adding ViewModel to your Project

Architecture Components are available from Google’s Maven repository. To use them, follow these steps:

Add the Google Maven repository

To add it to your project, open the build.gradle file for your project and add the highlighted line as shown below:

Add Architecture Components

Open the build.gradle file for your app or module and add the artifacts that you need as dependencies:


For the example we’ve mentioned above, it would be the ViewModel’s responsibility to acquire and keep the list of users, not the activity or the fragment.ViewModel’s only responsibility is to manage the data for the UI. It should never access your view hierarchy or hold a reference back to the Activity or the Fragment.

Tt should never reference a View, or any class that may hold a reference to the activity context. If the ViewModel needs the Application context, it can extend the AndroidViewModel class and have a constructor that receives the Application in the constructor.

Now we modify UserListsFragment to observe the data and update the UI.

If the activity is re-created, it receives the same UserViewModel instance that was created by the previous activity. When the owner activity is finished, the Framework calls ViewModel’s onCleared() method so that it can clean up resources.

Sharing Data Between Fragments

Imagine a common case of master-detail fragments, where we have a fragment in which the user selects an item from a list and another fragment that displays the contents of the selected item.

ViewModels can be used as a communication layer between different Fragments of an Activity. Each Fragment can acquire the ViewModel using the same key via their Activity. This allows communication between Fragments in a de-coupled fashion such that they never need to talk to the other Fragment directly.

These fragments can share a ViewModel using their activity scope to handle this communication.

Now we modify UserListFragment to share the data.

Notice that both fragments are using getActivity() while getting the ViewModelProvider. This means both of them will receive the same SharedViewModel instance which is scoped to the activity.

Lifecycle of a ViewModel

ViewModel objects are scoped to the Lifecycle passed to the ViewModelProvider when getting the ViewModel. The ViewModel stays in memory until the Lifecycle it’s scoped to goes away permanently—in the case of an activity, once it finishes; in the case of a fragment, once it’s detached.

viewmodel lifecycle

Download this project from GitHub.

Related Post

Lifecycle Aware Components

Room Persistence Library


Fragment Tricks

ConstraintLayout 1.1.x

Leave a Reply

Your email address will not be published. Required fields are marked *