ViewModel Internal Working

The ViewModel is a core component of Android Architecture Components, designed to store and manage UI-related data in a lifecycle-conscious way. One of its key features is the ability to retain data across configuration changes, such as screen rotations. This is made possible by the ViewModelStore, which plays a critical role in ensuring that ViewModel instances survive configuration changes. Let’s dive deep into how this works, including the role of ViewModelStore, NonConfigurationInstances, and the lifecycle of ViewModels.

Key Concepts

1. ViewModel: A class that stores and manages UI-related data, surviving configuration changes.
2. ViewModelStore: A container that holds ViewModel instances and ensures they are retained across configuration changes.
3. ViewModelStoreOwner: An interface implemented by components like Activity or Fragment that own a ViewModelStore.
4. NonConfigurationInstances: A mechanism used to retain objects (like ViewModelStore) across configuration changes.
5. Lifecycle Integration: ViewModel is tied to the lifecycle of the Activity or Fragment. When the Activity/Fragment is created, the ViewModelProvider checks if a ViewModel instance already exists in the ViewModelStore. If it does, it reuses it; otherwise, it creates a new instance. The ViewModel remains in memory until the Activity/Fragment is permanently destroyed (e.g., when the user navigates away or the Activity is finished).

How ViewModelStore Retains Data Across Configuration Changes

1. ViewModelStore is Retained by the Component

• The ViewModelStore is owned by a ViewModelStoreOwner, such as an Activity or Fragment.
• When a configuration change occurs (e.g., screen rotation), the Activity or Fragment is destroyed and recreated. However, the ViewModelStore is retained by the system and is not destroyed.
• This retention ensures that the ViewModel instances stored in the ViewModelStore remain available to the new Activity or Fragment instance.

2. ViewModelStore is Stored in a Non-Configuration Retained Object

• The ViewModelStore is stored in a special object called NonConfigurationInstances, which is retained across configuration changes.
• Before the Activity or Fragment is destroyed during a configuration change, the system calls the onRetainNonConfigurationInstance() method. This method allows the Activity or Fragment to save the ViewModelStore in the NonConfigurationInstances object.
• After the configuration change, the new Activity or Fragment instance retrieves the ViewModelStore from the NonConfigurationInstances object using the getLastNonConfigurationInstance() method.

3. ViewModelProvider Uses the Retained ViewModelStore

• When you request a ViewModel using ViewModelProvider, it checks the ViewModelStore associated with the Activity or Fragment.
• If the ViewModelStore already contains the requested ViewModel, it returns the existing instance. Otherwise, it creates a new ViewModel instance and stores it in the ViewModelStore.
• This mechanism ensures that the same ViewModel instance is reused across configuration changes, preserving its data.

4. Lifecycle of ViewModelStore

• The ViewModelStore is retained only for configuration changes. It is not retained when the Activity or Fragment is permanently destroyed (e.g., when the user navigates away or the system reclaims resources).
• When the Activity or Fragment is permanently destroyed, the ViewModelStore is cleared, and all ViewModel instances are cleaned up. This prevents memory leaks.

Example Code in Kotlin

Here’s an example of how ViewModelProvider and ViewModelStore work together in Kotlin:

// In an Activity or Fragment
val viewModel: MyViewModel by viewModels()

• viewModels() is a Kotlin property delegate that simplifies the process of obtaining a ViewModel.
• Under the hood, it uses ViewModelProvider to retrieve or create the ViewModel instance from the ViewModelStore.

If you want to explicitly use ViewModelProvider, you can do it like this:

// In an Activity or Fragment
val viewModel = ViewModelProvider(this).get(MyViewModel::class.java)

• this refers to the ViewModelStoreOwner (e.g., the Activity or Fragment).
• The ViewModelProvider retrieves the ViewModelStore from the ViewModelStoreOwner and uses it to store or retrieve the ViewModel.

Detailed Flow During Configuration Changes

1. Initial Creation:

• The Activity or Fragment is created, and a ViewModelStore is initialized.
• A ViewModel instance is created and stored in the ViewModelStore.

2. Configuration Change (e.g., Screen Rotation):

• The Activity or Fragment is about to be destroyed. The system calls onRetainNonConfigurationInstance() to save the ViewModelStore in the NonConfigurationInstances object.
• The Activity or Fragment is destroyed, but the ViewModelStore is retained in the NonConfigurationInstances.

3. Recreation After Configuration Change:

• A new instance of the Activity or Fragment is created.
• The system retrieves the ViewModelStore from the NonConfigurationInstances object using getLastNonConfigurationInstance().
• The ViewModelProvider retrieves the existing ViewModel instance from the ViewModelStore, ensuring data continuity.

4. Permanent Destruction:

• When the Activity or Fragment is permanently destroyed (e.g., the user navigates away), the ViewModelStore is cleared, and the onCleared() method of each ViewModel is called to release resources.

Summary

The ViewModelStore is the backbone of ViewModel retention across configuration changes. It survives configuration changes because it is stored in a retained object (NonConfigurationInstances) that is not destroyed during the process. This allows ViewModel instances to retain their state and data, simplifying the management of UI-related data.

When the Activity or Fragment is permanently destroyed, the ViewModelStore is cleared, ensuring that no memory leaks occur. By leveraging this mechanism, developers can build robust and efficient Android applications that handle configuration changes seamlessly.