`remember` vs. `rememberSaveable`: When and why to use each?

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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).

ONE 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.