Difference between remember and rememberSaveable
Compose state vs saved state.
remember survives recompositions only; rememberSaveable uses Bundle state for config changes and process death; use for UI state after recreation.
Claiming it uses ViewModel or disk.
What's really being asked
Whether you understand the boundary between ephemeral UI state and state that must survive system-initiated destruction. Interviewers want to see that you know remember is tied to the Composition lifecycle while rememberSaveable hooks into the Activity or Process saved state mechanism via Bundles.
The full answer
First, the scope difference. remember keeps state across recompositions but loses it when the activity is recreated or the process dies. Second, rememberSaveable uses the SavedStateRegistry to write values into a Bundle, which the system restores after configuration changes and process death. Third, the type constraints. rememberSaveable only works with types the Bundle can store, such as primitives, Strings, Parcelables, Serializables, and arrays or lists of those. For custom objects you must supply a Saver or autoSaver. Fourth, the right scenarios. Use rememberSaveable for small UI state that the user would expect to survive rotation or background killing, such as form input, expanded or collapsed sections, or scroll position. Do not use it for large data sets or business logic state that belongs in a ViewModel backed by repository or disk.
The mistakes people make
Saying rememberSaveable persists to disk or uses Room or DataStore. Claiming it survives everything including explicit user back navigation or finish, which it does not. Stating that remember survives process death. Using rememberSaveable for heavy objects like bitmaps or large lists, which can crash with TransactionTooLargeException. Saying it relies on a ViewModel under the hood.
What usually comes next
How would you save a custom class with rememberSaveable? The expected answer is implementing a Saver object using listSaver or mapSaver. What happens if the Bundle size limit is exceeded? The app throws TransactionTooLargeException, so large state belongs in persistent storage, not saved state. Why not just put everything in a ViewModel with SavedStateHandle? The interviewer wants to hear that ViewModel is for screen-level state while rememberSaveable is appropriate for leaf composable local UI state.
A concrete example
A search screen with a text field and a filter chip row. The query text should use rememberSaveable so it survives rotation. The list of search results should live in a ViewModel and be fetched from the network or database, not stored in rememberSaveable, because results are large and can be reloaded. The expanded or collapsed state of a filter section can use rememberSaveable because it is a boolean and the user expects it to remain after rotation.
Interview question
What is the primary architectural reason to use rememberSaveable instead of a ViewModel SavedStateHandle for a leaf composable's UI state?
- a.rememberSaveable is designed for leaf composable state rather than screen-level stateCorrect
- b.rememberSaveable persists to disk and survives user-initiated back navigation
- c.rememberSaveable can store bitmaps and large collections safely in the saved state Bundle
- d.rememberSaveable requires no type constraints and accepts any Kotlin object automatically
Why? this is the answer
rememberSaveable is appropriate for leaf composable local UI state, whereas ViewModel with SavedStateHandle is meant for screen-level state. Distractor A is wrong because rememberSaveable writes to the transient saved state Bundle, not disk, and its state is lost on explicit back navigation or finish.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #jetpack-compose
- #state-management
- #kotlin
- #saved-state
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles