Consider a Compose UI using rememberSaveable to store a counter value. What will happen to the counter value when the device is rotated (causing a configuration change)?
Think about what rememberSaveable is designed to do with state during configuration changes.
rememberSaveable saves the state in a way that survives configuration changes like screen rotations, so the counter value is preserved.
Choose the correct Kotlin Compose code that uses rememberSaveable to save a String variable name.
Remember the syntax for using rememberSaveable with mutableStateOf.
The correct syntax is val name = rememberSaveable { mutableStateOf("") }. Option B uses remember but not rememberSaveable, so state won't survive configuration changes. Options C and D are invalid syntax.
Which statement correctly describes how remember and rememberSaveable behave when the app process is killed by the system?
Think about what happens to in-memory state versus saved instance state on process death.
remember only keeps state in memory and loses it on process death. rememberSaveable saves state in a Bundle if the type is supported (e.g., Parcelable), so it can restore state after process death.
Given this code snippet, why does the state not restore after device rotation?
var count by rememberSaveable { mutableStateOf(0) }
Button(onClick = { count++ }) {
Text("Count: $count")
}Check if the delegated property syntax is fully supported by imports.
Using by delegation requires importing getValue and setValue from Compose runtime. Without these imports, the code compiles but the state does not behave correctly.
You want to save a custom data class instance using rememberSaveable. Which approach will correctly preserve the state across configuration changes?
Think about what types rememberSaveable can save by default.
rememberSaveable can save types that are Parcelable or Serializable. To save a custom data class, it must implement one of these interfaces. Otherwise, you must provide a custom saver or convert it to a supported type.