`remember` vs. `rememberSaveable`: When and why to use each?
Tests understanding of state survival in Compose. A good answer contrasts remember (for composition) with rememberSaveable (for activity recreation/process death), explaining its use of the Bundle mechanism. A red flag is confusing the two lifecycles.
What's really being asked
This tests your grasp of state management lifecycles in Jetpack Compose. The interviewer isn't just looking for a definition. They want to see if you understand the 'why' – specifically, the difference between state that needs to survive recomposition versus state that needs to survive major system events like configuration changes (e.g., screen rotation) and process death. It's a test of practical, production-level Android knowledge.
The full answer
A strong answer will cover four points in order. First, define remember: it keeps an object alive across recompositions, but its state is lost if the composable leaves the composition tree or the Activity is recreated. It's for cheap, easily re-creatable UI state. Second, define rememberSaveable: it behaves like remember but additionally saves the state into the Activity's Bundle. This allows it to survive configuration changes and process death. Third, explain the mechanism: rememberSaveable uses a Saver to convert the object into something that can be stored in a Bundle (like primitives, Parcelable, or Serializable types). For custom types, you might need to provide a custom Saver. Fourth, provide clear use cases: use remember for transient UI state like animation states. Use rememberSaveable for critical user input like text in a form field.
The mistakes people make
A major red flag is stating that remember survives configuration changes. It does not. The state is lost, and the composable is re-initialized. Another common mistake is using rememberSaveable for everything 'just in case.' This is inefficient. It adds overhead by writing to the Bundle, which has size limitations (around 1MB, but practically much less is safe) and performance costs. A candidate who doesn't mention the performance or storage trade-off is likely missing senior-level nuance. Finally, failing to explain the underlying Bundle and Saver mechanism suggests a superficial understanding.
What usually comes next
Expect questions like: 'What happens if you try to use rememberSaveable with a custom, non-parcelable object? How would you fix it?' (Answer: You need to implement a custom Saver). Or, 'You mentioned the Bundle has size limits. What's a better approach for saving large amounts of state, like a complex user-drawn bitmap?' (Answer: Persist it to a file or database and use rememberSaveable to store only the file path or a unique ID).
A concrete example
Imagine a search screen with a text field. The search query typed by the user should be stored using rememberSaveable { mutableStateOf("") }. This ensures that if the user rotates the screen or the OS kills the app in the background, their typed query is not lost. However, the state of a decorative ripple effect on a button on that same screen should use remember { mutableStateOf(false) }. Losing and re-initializing this transient visual state upon rotation is perfectly acceptable and more performant.
Interview question
A user is typing their email into a text field. To ensure the text is not lost if the user rotates their device, which state-holding approach is most appropriate?
- a.Use `remember` because it's lightweight and designed to hold state across recompositions, which includes screen rotation.
- b.Use `rememberSaveable` because it saves the state to a local database, ensuring it survives even if the app is uninstalled.
- c.Use `rememberSaveable` because it persists state across configuration changes by saving it to the system's `Bundle`.Correct
- d.Use `remember` because `rememberSaveable` is only for complex objects and adds unnecessary performance overhead for a simple string.
Why? this is the answer
`rememberSaveable` is correct because it uses the `Bundle` mechanism to survive configuration changes like screen rotation. In contrast, `remember` alone is insufficient as its state is lost when the Activity is recreated during rotation.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
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