Saving instance state in Android Kotlin - Deep Dive

Overview - Saving instance state

What is it?

Saving instance state means keeping important information about your app's screen when it changes or restarts. For example, if you rotate your phone or switch apps, the app can remember what you were doing. This helps keep the app feeling smooth and avoids losing your work or data. Android provides a way to save and restore this information automatically.

Why it matters

Without saving instance state, your app would forget everything every time the screen changes or the app restarts. Imagine writing a message and suddenly losing it because you turned your phone. Saving instance state solves this by remembering key data, making apps feel reliable and user-friendly. It prevents frustration and improves user experience.

Where it fits

Before learning this, you should understand basic Android app components like Activities and their lifecycle. After this, you can learn about persistent storage options like databases or shared preferences for saving data long-term beyond just screen changes.

Mental Model

Core Idea

Saving instance state is like packing a small bag with your current app details before a trip, so you can unpack and continue exactly where you left off after the trip.

Think of it like...

Imagine you are working on a puzzle and need to leave the table. You put your puzzle pieces in a small box to keep them safe. When you come back, you open the box and continue without losing any pieces. Saving instance state works the same way for your app's temporary data.

┌─────────────────────────────┐
│       Activity Lifecycle     │
├─────────────┬───────────────┤
│ onSaveInstanceState │ onRestoreInstanceState│
│  (pack bag) │  (unpack bag) │
└─────────────┴───────────────┘
       ↑                     ↓
  App about to change    App restored
  (e.g., rotate)         (e.g., rotate)

Build-Up - 7 Steps

1

Foundation

Understanding Activity Lifecycle Basics

Concept: Learn what happens when an Android screen changes or the app moves between states.

Android apps use Activities to show screens. Each Activity has a lifecycle with methods like onCreate, onStart, onResume, onPause, onStop, and onDestroy. When you rotate the screen, Android destroys and recreates the Activity to apply new layout settings. This means the screen resets unless you save data.

Result

You understand that screen changes cause Activity restarts, which can erase temporary data.

Knowing the Activity lifecycle explains why saving instance state is necessary to keep user data during screen changes.

2

Foundation

What is Instance State in Android?

Concept: Instance state is a small bundle of data saved temporarily to remember UI details during Activity restarts.

Android provides a Bundle object to save key-value pairs of simple data types like strings, integers, and booleans. This Bundle is passed to onSaveInstanceState before the Activity is destroyed and to onRestoreInstanceState or onCreate when it is recreated.

Result

You know where and how Android stores temporary UI data during lifecycle changes.

Understanding the Bundle as a temporary data bag clarifies how Android helps preserve UI state automatically.

3

Intermediate

Saving Data with onSaveInstanceState

🤔Before reading on: do you think onSaveInstanceState is called before or after the Activity is destroyed? Commit to your answer.

Concept: Learn how to put your data into the Bundle before the Activity is destroyed.

Override the onSaveInstanceState method in your Activity. Inside, add data to the Bundle using methods like putString or putInt with a unique key. This method is called before the Activity is destroyed, giving you a chance to save important info.

Result

Your data is safely packed into the Bundle before the Activity restarts.

Knowing that onSaveInstanceState runs before destruction ensures you save data at the right moment to avoid loss.

4

Intermediate

Restoring Data in onCreate or onRestoreInstanceState

🤔Before reading on: do you think restoring state must happen only in onCreate or can it also happen in onRestoreInstanceState? Commit to your answer.

Concept: Learn how to get your saved data back when the Activity is recreated.

In onCreate, check if the savedInstanceState Bundle is not null. If it has data, retrieve it using getString or getInt with the same keys you used to save. Alternatively, override onRestoreInstanceState which is called after onStart, and restore data there.

Result

Your app recovers the saved data and UI looks as before the change.

Understanding multiple restore points helps you choose the best place to reload your data depending on your app's needs.

5

Intermediate

What Data Can You Save in Instance State?

Concept: Learn the types of data suitable for saving in instance state and what to avoid.

You can save small, simple data like strings, numbers, booleans, and small arrays. Avoid saving large objects, files, or complex data structures because the Bundle size is limited and saving/restoring them is inefficient.

Result

You know how to pick the right data to save for smooth app behavior.

Knowing data limits prevents app crashes or slowdowns caused by oversized or inappropriate saved data.

6

Advanced

Handling Configuration Changes Gracefully

🤔Before reading on: do you think saving instance state is the only way to handle screen rotations? Commit to your answer.

Concept: Explore how saving instance state fits with other ways to handle configuration changes like rotation.

Besides saving instance state, you can declare in the manifest that your Activity handles configuration changes itself, preventing restarts. However, this requires manual UI updates. Saving instance state is the recommended way for most cases because it works automatically and keeps code simpler.

Result

You understand trade-offs between automatic state saving and manual configuration handling.

Knowing alternatives helps you choose the best approach for your app's complexity and performance needs.

7

Expert

Surprising Limits and Gotchas of Instance State

🤔Before reading on: do you think all UI widget states are saved automatically by Android? Commit to your answer.

Concept: Discover what Android saves automatically and what you must save yourself, plus Bundle size limits.

Android automatically saves state for some standard widgets like EditText, but custom views or complex UI states need manual saving. Also, the Bundle size limit is about 1MB; exceeding it causes crashes. Large data should be saved elsewhere, like ViewModel or persistent storage. Understanding these limits avoids subtle bugs and app crashes.

Result

You avoid common pitfalls by knowing what Android handles and what you must do.

Understanding automatic vs manual saving and size limits prevents frustrating bugs and improves app stability.

Under the Hood

When an Activity is about to be destroyed (e.g., rotation), Android calls onSaveInstanceState to collect a Bundle of key-value pairs. This Bundle is serialized and stored temporarily by the system. When the Activity is recreated, Android passes this Bundle back to onCreate and onRestoreInstanceState, allowing the app to restore UI state. This process is fast and uses a lightweight serialization format optimized for small data.

Why designed this way?

Android was designed to handle many device configurations and interruptions gracefully. Destroying and recreating Activities on configuration changes ensures the UI matches new settings. Saving instance state via Bundle provides a simple, standardized way to preserve UI data without forcing developers to manage complex persistence. Alternatives like handling configuration changes manually were less flexible and error-prone.

┌───────────────┐       onSaveInstanceState       ┌───────────────┐
│   Activity    │ ──────────────────────────────▶ │    Bundle     │
│   Destroyed   │                               │ (key-value map)│
└───────────────┘                               └───────────────┘
         ▲                                               │
         │                                               │
         │ onCreate / onRestoreInstanceState             │
         │◀──────────────────────────────────────────────┘
┌───────────────┐
│   Activity    │
│  Recreated    │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does saving instance state keep your data permanently on the device? Commit yes or no.

Common Belief: Saving instance state stores data permanently like a database or file.

Reality: Instance state is temporary and only lasts during Activity restarts, not app kills or device reboots.

Why it matters: Relying on instance state for permanent data causes data loss when the app fully closes or device restarts.

Quick: Do you think Android saves all UI widget states automatically? Commit yes or no.

Common Belief: Android automatically saves the state of every UI element without extra code.

Reality: Only some standard widgets save state automatically; custom views or complex data need manual saving.

Why it matters: Assuming automatic saving leads to lost data and broken UI after rotation or restart.

Quick: Is it safe to save large images or files in the instance state Bundle? Commit yes or no.

Common Belief: You can save any data, including large files or images, in the instance state Bundle.

Reality: The Bundle has size limits and is meant for small, simple data only; large data causes crashes.

Why it matters: Saving large data in instance state can crash the app or cause slow performance.

Quick: Does handling configuration changes manually replace the need for saving instance state? Commit yes or no.

Common Belief: If you handle configuration changes yourself, you don't need to save instance state.

Reality: Even with manual handling, you often still need to save and restore UI state for a smooth user experience.

Why it matters: Ignoring instance state in manual handling leads to inconsistent UI and lost user data.

Expert Zone

1

Some UI components save their state automatically only if they have unique IDs; missing IDs break this behavior.

2

Using ViewModel alongside instance state can optimize data retention by keeping large or complex data out of the Bundle.

3

The timing of onSaveInstanceState is critical; it is not called when the user presses Back, so data saved there is only for temporary interruptions.

When NOT to use

Saving instance state is not suitable for large or permanent data. Use persistent storage like databases or files for long-term data. For complex UI state, consider ViewModel or saved state handles. Also, if your app handles configuration changes manually, you may rely less on instance state but still need it for some UI details.

Production Patterns

In real apps, developers combine instance state saving for small UI details with ViewModel for larger data. They also use saved state handles to bridge ViewModel and instance state. Testing rotation and process death scenarios ensures robust state restoration. Avoiding heavy data in instance state prevents crashes in production.

Connections

ViewModel in Android

complements

ViewModel holds data across configuration changes without serialization limits, while instance state saves small UI details; together they provide robust state management.

Serialization in Computer Science

builds-on

Saving instance state uses serialization to convert data into a storable format, a fundamental concept in data transfer and storage.

Checkpointing in Operating Systems

similar pattern

Saving instance state is like checkpointing a process state so it can resume later, showing how concepts from OS design apply to app lifecycle management.

Common Pitfalls

#1 Saving large objects directly in instance state Bundle.

Wrong approach:

override fun onSaveInstanceState(outState: Bundle) {
super.onSaveInstanceState(outState)
outState.putSerializable("largeData", largeObject)
}

Correct approach:

Use ViewModel or persistent storage for large data, and save only small keys or IDs in the Bundle.

Root cause:

Misunderstanding Bundle size limits and serialization overhead.

#2 Not checking if savedInstanceState is null before restoring data.

Wrong approach:

override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val text = savedInstanceState!!.getString("key")
}

Correct approach:

override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val text = savedInstanceState?.getString("key")
if (text != null) { /* restore UI */ }
}

Root cause:

Assuming savedInstanceState is always non-null leads to crashes on first launch.

#3 Saving UI state only in onPause or onStop instead of onSaveInstanceState.

Wrong approach:

override fun onPause() {
super.onPause()
outState.putString("key", value) // outState not available here
}

Correct approach:

override fun onSaveInstanceState(outState: Bundle) {
super.onSaveInstanceState(outState)
outState.putString("key", value)
}

Root cause:

Confusing lifecycle methods and where Bundle is accessible.

Key Takeaways

Saving instance state preserves small, temporary UI data during Activity restarts like screen rotations.

Use onSaveInstanceState to save data into a Bundle before destruction and restore it in onCreate or onRestoreInstanceState.

Only save small, simple data in instance state; use ViewModel or persistent storage for larger or permanent data.

Android automatically saves some widget states, but custom views need manual saving to avoid data loss.

Understanding the Activity lifecycle and instance state limits prevents common bugs and improves app reliability.