remember vs. rememberSaveable: When and Why to Use Each
Tests understanding of Compose state survival. remember is for recomposition scope. rememberSaveable survives activity recreation and process death via a Bundle, requiring custom Savers for complex types. Red flag: saying remember survives rotation.
What's really being asked
This question probes your understanding of state management lifecycles in Jetpack Compose. It specifically targets the critical distinction between surviving recomposition, surviving activity recreation (configuration changes), and surviving process death. An interviewer wants to see that you not only know which one to use, but also understand the underlying Android platform mechanisms (Bundle, Parcelable) that rememberSaveable leverages.
The full answer
A complete answer should touch on four key points. First, explain remember: its state is kept as long as the composable remains in the composition tree. It survives recompositions but is lost on configuration changes or process death. It's ideal for transient UI state. Second, explain rememberSaveable: it survives everything remember does, plus activity and process recreation. This is for critical user state like text input or scroll position. Third, detail the mechanism: rememberSaveable automatically saves its data into a Bundle, just like the classic onSaveInstanceState system. It has built-in support for primitives, enums, annotations, and Parcelable types. Fourth, mention custom Savers: for any data type not automatically supported, you must provide a custom Saver object to instruct Compose on how to convert your object to and from a Bundle-compatible format.
The mistakes people make
The most common red flag is stating that remember survives configuration changes like screen rotation. It does not; the activity is destroyed and recreated, losing the remember state. Another mistake is being vague about how rememberSaveable works; a senior candidate should explicitly mention the Bundle and the onSaveInstanceState analogy. Finally, failing to bring up custom Savers for complex objects suggests a superficial understanding, implying rememberSaveable works magically for all types.
What usually comes next
Expect questions like, "When would you choose a ViewModel over rememberSaveable?" (Answer: for business logic, sharing state between screens, and handling larger data sets). Or, "What are the performance costs of putting a large, complex object into rememberSaveable?" (Answer: serialization/deserialization overhead on every configuration change and transaction size limits on the Bundle, which is around 1MB).
A concrete example
Use remember for purely transient UI state, like val isExpanded = remember { mutableStateOf(false) } for a dropdown menu. Use rememberSaveable for any user-generated content or position that would be frustrating to lose on rotation. For example, a search query in a text field should use var query by rememberSaveable { mutableStateOf("") } to ensure the user's typed text is not lost.
Interview question
A Composable displays a user's input in a text field. Which state management approach ensures the input persists across a device rotation and why?
- a.Using rememberSaveable because it leverages the Android Bundle mechanism to store state across activity recreation.Correct
- b.Using remember with a custom Saver to handle configuration changes.
- c.Using remember because it retains state across all UI lifecycle events.
- d.Using a ViewModel to hold the state, as rememberSaveable is only for primitive types.
Why? this is the answer
The correct answer is B. rememberSaveable is specifically designed to persist state across activity recreation, such as device rotation or process death, by utilizing the Android Bundle mechanism. Option C is incorrect because remember only survives recompositions and is lost when the activity is recreated, which happens during a device 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