Lifecycle, rotation and process death

The bug you cannot reproduce

You fixed rotation with a ViewModel in Lesson 4.2. Here is a report you will get anyway:

"I was halfway through writing a note. I switched to the camera to check something, took a few photos, came back — and my note was blank."

You try it. It works fine. You try it ten times. It works fine every time.

It works because your phone had memory to spare. Theirs did not. While your app sat in the background, Android killed the entire process to keep the camera running smoothly. When the user came back, Android started your app again from scratch and restored what it had written down — and everything it had not written down was gone.

This is process death, and it is completely normal Android behaviour. It is not a crash. Nothing appears in the logs to say it happened.

What survives what

Pin this table up somewhere.

Two rows deserve reading twice.

A ViewModel does not survive process death. It is an ordinary object in memory, and the memory is gone. Lots of people believe otherwise, because on a developer's phone — plenty of RAM, app in the foreground — it never comes up.

rememberSaveable survives process death but not a swipe-away. Swiping an app out of the recents view is the user saying "I am finished with this", and Android throws away the saved state too. That is correct: nobody wants a half-typed message from three weeks ago reappearing.

The Activity lifecycle, briefly

Android tells your Activity where it is with six callbacks:

1onCreate()   // being built
2onStart()    // about to become visible
3onResume()   // in front, taking taps
4// ---- user opens another app ----
5onPause()    // no longer in front
6onStop()     // no longer visible
7onDestroy()  // going away

Compose hides nearly all of this. You almost never write these callbacks — the composition appears and disappears, and remember, LaunchedEffect and DisposableEffect handle the timing for you.

But two facts leak through and matter.

onStop is roughly where Android decides your app is a candidate for being killed. And saved state is written just before onStop, not at the moment of death — because when the process is killed, nothing gets to run at all.

Saving from a composable

rememberSaveable is remember plus a receipt:

1var title by rememberSaveable {
2  mutableStateOf("")
3}
4var body by rememberSaveable {
5  mutableStateOf("")
6}
7var loaded by rememberSaveable {
8  mutableStateOf(false)
9}

That is the real editor from Pocket Notes. Three saved values, and the third one is the clever one.

rememberSaveable only accepts what fits in a Bundle: numbers, strings, booleans, and types marked Parcelable. Hand it your own data class and you get an error naming exactly that — see the Error Doctor.

Saving from a ViewModel

A ViewModel can ask for a SavedStateHandle, which is a small map that does survive process death:

1class EditorViewModel(
2  private val saved: SavedStateHandle
3) : ViewModel() {
4
5  var draft: String
6    get() = saved["draft"] ?: ""
7    set(value) {
8      saved["draft"] = value
9    }
10}

It goes into the same Bundle, so the same size limit applies. A draft is fine. A list of five hundred notes is not — and does not belong there anyway, because that is what the database is for.

The fix most apps actually use

Look at how Pocket Notes handles a half-written note:

1fun finish() {
2  vm.save(noteId, title, body)
3  onDone()
4}
5
6// The system back gesture must save too.
7BackHandler { finish() }

There is no Save button. Leaving the screen writes the note to Room — and once it is on disk, all three disasters stop mattering. rememberSaveable is only covering the gap between "you are typing" and "you left the screen".

That is the general shape of a good answer:

• On disk for anything the user would be upset to lose.
• rememberSaveable for what they are part-way through right now.
• ViewModel for what is cheap to rebuild — a filtered list, a computed total.
• remember for things that genuinely do not matter, like whether a menu is open.

Cleaning up on the way out

DisposableEffect is the tool for anything that must be undone when a composable leaves. Focus Flow uses it for the keep-screen-on setting:

1val view = LocalView.current
2DisposableEffect(keepOn) {
3  view.keepScreenOn = keepOn
4  onDispose { view.keepScreenOn = false }
5}

Set it on arrival; hand it back in onDispose. Without that, leaving the Timer tab would leave the phone's display pinned awake for as long as the app ran — the kind of bug users notice only as "this app eats my battery".