remember vs. rememberSaveable – Zustand, der die Drehung übersteht

In Compose speicherst du lokalen UI-Zustand mit remember. Das reicht für Recompositions – aber es gibt eine Falle: Dreht der Nutzer das Gerät, wird die Activity neu erzeugt und der mit remember gehaltene Wert ist weg. Genau dafür gibt es rememberSaveable.

Der Unterschied in zwei Zeilen

@Composable
fun Counter() {
    // Überlebt Recomposition – aber NICHT die Bildschirmdrehung:
    var a by remember { mutableStateOf(0) }

    // Überlebt Recomposition UND Konfigurationsänderung (Drehung, Sprache …):
    var b by rememberSaveable { mutableStateOf(0) }

    Column {
        Button(onClick = { a++ }) { Text("remember: $a") }
        Button(onClick = { b++ }) { Text("saveable: $b") }
    }
}

Zähl beide hoch, dreh das Gerät – a springt auf 0 zurück, b bleibt stehen.

Wie funktioniert das?

rememberSaveable legt den Wert im Bundle der Activity ab (derselbe Mechanismus wie onSaveInstanceState). Deshalb funktioniert es out-of-the-box nur für Typen, die ins Bundle passen: Int, String, Boolean, Parcelable usw.

Für eigene Klassen gibst du einen Saver mit:

data class Range(val from: Int, val to: Int)

val rangeSaver = listSaver<Range, Int>(
    save = { listOf(it.from, it.to) },
    restore = { Range(it[0], it[1]) }
)

var range by rememberSaveable(stateSaver = rangeSaver) {
    mutableStateOf(Range(0, 10))
}

Faustregel

• remember – kurzlebiger UI-Zustand, der ruhig neu starten darf (z. B. ob ein Menü gerade offen ist).
• rememberSaveable – Zustand, den der Nutzer nach einer Drehung erwartet (Sucheingabe, ausgewählter Tab, Formularwerte).
• ViewModel – alles, was die Drehung und eine kurze Weg-vom-Screen-Situation überleben soll oder Geschäftslogik enthält.

Du brauchst eine Android-App, deren Zustand sich in jeder Situation richtig verhält? Ich helfe dir weiter.

Quellen

• State in Compose – rememberSaveable (developer.android.com)
• Save UI state in Compose (developer.android.com)