rememberSaveable for configuration changes in Android Kotlin - Deep Dive

Overview - rememberSaveable for configuration changes

What is it?

rememberSaveable is a tool in Android's Jetpack Compose that helps save UI state across configuration changes like screen rotations. It keeps your app's data safe so users don't lose their input or selections when the device changes orientation. This works by automatically saving and restoring values using a bundle-like system behind the scenes. It is easy to use and improves user experience by making apps feel stable and reliable.

Why it matters

Without rememberSaveable, when a user rotates their phone or changes device settings, the app would lose all temporary data like typed text or selected options. This would force users to start over, causing frustration and poor app reviews. rememberSaveable solves this by preserving state seamlessly, making apps feel smooth and professional. It saves developers time by handling the tricky parts of state saving automatically.

Where it fits

Before learning rememberSaveable, you should understand basic Jetpack Compose state management with remember. After this, you can explore more advanced state handling like ViewModel integration and saving state across process death. rememberSaveable fits as a bridge between simple in-memory state and persistent state that survives configuration changes.

Mental Model

Core Idea

rememberSaveable remembers UI state and automatically saves it so it survives device rotations and configuration changes.

Think of it like...

It's like writing a quick note on a sticky pad before moving your desk; even if you rearrange your room, the note stays visible so you don't forget what you were doing.

┌───────────────────────────────┐
│       UI State in Compose      │
├──────────────┬────────────────┤
│ remember()   │  Lost on rotate │
│ (in-memory)  │                │
├──────────────┼────────────────┤
│ rememberSaveable()             │
│ (saved & restored automatically)│
└───────────────────────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding UI State in Compose

Concept: UI state holds data that changes in your app's interface, like text input or toggles.

In Jetpack Compose, state is a value that, when changed, updates the UI automatically. For example, a text field's content is stored in a state variable. Using remember, you can keep this state during recompositions, so the UI stays consistent while the app runs.

Result

The UI updates correctly when the user types or interacts, but state is lost if the device rotates.

Understanding that state controls UI behavior is key to building interactive apps.

2

Foundation

What Happens on Configuration Changes

Concept: Configuration changes like screen rotation restart the activity, causing in-memory state to reset.

When you rotate your phone, Android destroys and recreates the activity. This means any state stored only in memory (like with remember) is lost unless saved explicitly. Users see the UI reset, losing their input or selections.

Result

UI state disappears on rotation, frustrating users who have to re-enter data.

Knowing that configuration changes reset in-memory state explains why apps need special handling to keep data.

3

Intermediate

Introducing rememberSaveable

🤔Before reading on: do you think rememberSaveable stores data only in memory or also saves it across rotations? Commit to your answer.

Concept: rememberSaveable extends remember by saving state to a bundle that survives configuration changes.

rememberSaveable works like remember but also saves the value using Android's saved instance state system. This means when the activity restarts, the saved data is restored automatically. It supports common types like primitives, strings, and parcelables out of the box.

Result

UI state persists across rotations without extra code to save or restore manually.

Understanding that rememberSaveable bridges in-memory state and saved state simplifies state management during configuration changes.

4

Intermediate

Using rememberSaveable in Practice

🤔Before reading on: do you think rememberSaveable requires manual saving code or works automatically? Commit to your answer.

Concept: Using rememberSaveable is as simple as replacing remember to make state survive rotations automatically.

Example: var text by rememberSaveable { mutableStateOf("") } TextField(value = text, onValueChange = { text = it }) This code keeps the text input even if the user rotates the device, without extra save/restore logic.

Result

The text field keeps its content after rotation, improving user experience.

Knowing that rememberSaveable requires minimal code change encourages its use for better app stability.

5

Advanced

Custom Types with rememberSaveable

🤔Before reading on: do you think rememberSaveable can save any custom object automatically? Commit to your answer.

Concept: rememberSaveable can save custom types if you provide a way to convert them to and from a savable format.

For custom data classes, you can use the Saver interface to define how to save and restore your object. For example: val mySaver = Saver(save = { it.toString() }, restore = { MyData.fromString(it) }) val state = rememberSaveable(stateSaver = mySaver) { mutableStateOf(MyData()) } This lets rememberSaveable handle complex objects safely.

Result

Custom objects persist across configuration changes without losing data.

Understanding how to extend rememberSaveable for custom types unlocks flexible state management.

6

Expert

rememberSaveable vs ViewModel State Handling

🤔Before reading on: do you think rememberSaveable replaces ViewModel for state persistence? Commit to your answer.

Concept: rememberSaveable handles short-term UI state across rotations, while ViewModel manages longer-lived state surviving process death.

rememberSaveable saves state in a bundle tied to the activity lifecycle, so it doesn't survive if the app is killed. ViewModel holds state in memory tied to the app process and can be combined with saved state handles for more robust persistence. Choosing between them depends on the state lifespan and complexity.

Result

Developers understand when to use rememberSaveable or ViewModel for best state management.

Knowing the lifecycle and persistence differences prevents bugs and improves app reliability.

Under the Hood

rememberSaveable uses Android's SavedStateRegistry to save state in a Bundle when the activity is destroyed due to configuration changes. It registers a provider that writes the current state to the bundle and restores it when the activity is recreated. This happens automatically without developer intervention, using type-safe serialization for supported types.

Why designed this way?

Android needed a simple way to preserve UI state across configuration changes without forcing developers to write boilerplate save/restore code. rememberSaveable builds on the existing saved instance state system, integrating it with Compose's declarative model for seamless state persistence.

┌───────────────┐
│ Compose UI    │
│ (rememberSaveable) │
└──────┬────────┘
       │ saves state
       ▼
┌───────────────┐
│ SavedStateRegistry │
│ (Bundle storage)   │
└──────┬────────┘
       │ restores state
       ▼
┌───────────────┐
│ Activity recreated │
│ with restored state│
└───────────────────┘

Myth Busters - 3 Common Misconceptions

Quick: Does rememberSaveable save state permanently across app restarts? Commit yes or no.

Common Belief: rememberSaveable saves state permanently, even if the app is closed and reopened.

Reality: rememberSaveable only saves state across configuration changes like rotations, not across full app restarts or process death.

Why it matters: Relying on rememberSaveable for permanent data causes data loss when the app is killed, leading to bugs and poor user experience.

Quick: Can rememberSaveable save any object type automatically? Commit yes or no.

Common Belief: rememberSaveable can save any object without extra work.

Reality: rememberSaveable only saves types supported by the saved instance state system or those with a custom Saver provided.

Why it matters: Trying to save unsupported types without a Saver causes crashes or lost data.

Quick: Does rememberSaveable replace ViewModel for all state needs? Commit yes or no.

Common Belief: rememberSaveable replaces ViewModel for all state persistence.

Reality: rememberSaveable is for short-term UI state across rotations; ViewModel handles longer-lived state and business logic.

Why it matters: Misusing rememberSaveable for complex state leads to fragile apps and harder maintenance.

Expert Zone

1

rememberSaveable uses SavedStateRegistry under the hood, which means it integrates tightly with the Android lifecycle and can be combined with other saved state providers.

2

Custom Savers must be carefully designed to avoid data loss or corruption, especially when dealing with nested or complex objects.

3

rememberSaveable state is restored before the first composition, so initial UI rendering can rely on restored values without flicker or delay.

When NOT to use

Do not use rememberSaveable for data that must survive process death or app restarts; use ViewModel with SavedStateHandle or persistent storage instead. Also avoid it for very large data objects that can slow down state saving and restoring.

Production Patterns

In production apps, rememberSaveable is commonly used for simple UI inputs like text fields, toggles, and selections. It is often combined with ViewModel for business logic and longer-lived state. Developers also create custom Savers for domain-specific objects to keep UI state consistent.

Connections

ViewModel with SavedStateHandle

complements

Understanding rememberSaveable helps grasp how ViewModel's SavedStateHandle extends state persistence beyond configuration changes to process death.

Android Activity Lifecycle

builds-on

Knowing the activity lifecycle clarifies why state is lost on rotation and how rememberSaveable hooks into lifecycle events to save and restore state.

Web Browser Session Storage

similar pattern

Both rememberSaveable and session storage save temporary state that survives page reloads or configuration changes but not permanent closures, showing a cross-domain pattern of short-term state persistence.

Common Pitfalls

#1 Losing state after rotation because remember was used instead of rememberSaveable.

Wrong approach:

var text by remember { mutableStateOf("") }
TextField(value = text, onValueChange = { text = it })

Correct approach:

var text by rememberSaveable { mutableStateOf("") }
TextField(value = text, onValueChange = { text = it })

Root cause:

Using remember only keeps state in memory, which is cleared on configuration changes.

#2 Trying to save a custom data class without a Saver, causing crashes.

Wrong approach:

var data by rememberSaveable { mutableStateOf(MyData()) } // MyData is custom class without Saver

Correct approach:

val mySaver = Saver(save = { it.toString() }, restore = { MyData.fromString(it) })
var data by rememberSaveable(stateSaver = mySaver) { mutableStateOf(MyData()) }

Root cause:

rememberSaveable cannot serialize unknown types without instructions.

#3 Expecting rememberSaveable to keep data after app is killed and restarted.

Wrong approach:

var count by rememberSaveable { mutableStateOf(0) } // expecting count to persist after app restart

Correct approach:

Use ViewModel with SavedStateHandle or persistent storage like DataStore for data that must survive app restarts.

Root cause:

rememberSaveable only saves state across configuration changes, not process death.

Key Takeaways

rememberSaveable is a simple way to keep UI state across configuration changes like screen rotations.

It automatically saves and restores supported types using Android's saved instance state system.

For custom types, you must provide a Saver to tell rememberSaveable how to save and restore them.

rememberSaveable is not a replacement for ViewModel or persistent storage for long-term data.

Using rememberSaveable improves user experience by preventing data loss during common device changes.