Android ViewModel: Survive Screen Rotations

Why it exists

Before ViewModel, developers struggled with state during configuration changes like screen rotation. Rotating the phone would destroy and recreate the Activity, wiping out all its data and triggering expensive re-fetches. This led to complex onSaveInstanceState bundles or clunky workarounds. ViewModel was created to provide a simple, lifecycle-aware way to preserve UI state across these events.

The mental model

Think of a ViewModel as a durable data safe for your UI. Your Activity or Fragment is like a temporary worker on a shift. When a configuration change happens, the worker is replaced, but the data they were working on remains secure in the safe (ViewModel) for the next worker to pick up. The safe itself is tied to the UI's overall lifecycle, not the temporary worker's.

How it works

When you request a ViewModel for an Activity or Fragment, the system provides an instance scoped to that UI controller's lifecycle. If the Activity is destroyed for a configuration change, the ViewModel instance is retained in memory. When the Activity is recreated, it receives the exact same ViewModel instance, complete with its data. The ViewModel is only cleared from memory when its owner (the Activity or Fragment) is permanently destroyed, for example, when the user navigates back or the app is closed. It exposes its data via observable data holders like LiveData or StateFlow so the UI can react to changes automatically.

When to use it

Use a ViewModel to hold data that the UI displays. This includes user input in forms, lists of items fetched from a repository, or the current state of a UI element (e.g., which tab is selected). It's the standard place to house UI state and the logic that transforms business data into that state.

When not to use it

Never store references to UI components (Views, Fragments, Activities) or any Context in a ViewModel. This creates memory leaks, as the ViewModel can outlive the View, preventing it from being garbage collected. For long-term persistence that needs to survive process death or app restarts, use a database like Room, DataStore, or SharedPreferences, often accessed via a Repository pattern from the ViewModel.

One canonical example

A user is on a product details screen. The ViewModel fetches the product information from a repository and holds it. The user rotates their phone. The Activity is destroyed and recreated, but it reconnects to the existing ViewModel. The product data is instantly available to the new Activity instance without needing another network call, providing a seamless user experience.