{"id":73,"date":"2026-09-30T13:05:00","date_gmt":"2026-09-30T11:05:00","guid":{"rendered":"https:\/\/grindloop.io\/blog\/?p=73"},"modified":"2026-09-27T16:59:05","modified_gmt":"2026-09-27T14:59:05","slug":"one-time-events-jetpack-compose-keep-breaking","status":"publish","type":"post","link":"https:\/\/grindloop.ai\/blog\/one-time-events-jetpack-compose-keep-breaking\/","title":{"rendered":"Why One-Time Events in Jetpack Compose Keep Breaking"},"content":{"rendered":"

One-time events in Jetpack Compose keep breaking because they’re sent as signals. A signal only works if someone is listening at that exact moment. Navigation, snackbars and haptics often fire when no screen is collecting. The app might be in the background, or mid-rotation. A SharedFlow<\/code> with no replay drops the event outright. A Channel<\/code> keeps it until someone receives it. But it’s gone once received, even if the screen stops before acting on it. Google’s architecture guidance says neither one guarantees delivery. Its fix is to reduce the event to UI state. The screen reads a field like isUserLoggedIn<\/code> and reacts to it. Any collector that attaches later still sees it. If the screen stays on the back stack, the UI also needs to record that it already acted. Below is one login screen built all three ways. We ran each version’s core logic to show where it fails.<\/p>\n\n

A login screen calls viewModel.login()<\/code>. On success, the ViewModel tells the UI to go to Home. It works on the emulator. A user taps “Log in” on a slow network and switches apps while it loads. They come back to the login screen. The request succeeded. Nothing happened.<\/p><\/blockquote>\n\n

Version 1: SharedFlow drops what nobody hears<\/h2>\n\n

The most common first attempt is a SharedFlow<\/code> of events.<\/p>\n\n\n

private val _events = MutableSharedFlow<LoginEvent>()\nval events = _events.asSharedFlow()\n\nfun login() = viewModelScope.launch {\n    repository.login()\n    _events.emit(LoginEvent.ToHome)\n}\n\n\/\/ in the composable\nLaunchedEffect(Unit) {\n    viewModel.events\n        .flowWithLifecycle(lifecycle)\n        .collect { navController.navigate(\"home\") }\n}<\/pre>\n\n\n
A default MutableSharedFlow<\/code> has replay = 0<\/code>. It delivers each value only to collectors subscribed at the moment of emit()<\/code>. flowWithLifecycle<\/code> stops collecting when the app goes to the background. So the login finishes and ToHome<\/code> is emitted. No one receives it. There’s no error. In our JVM run, a collector that subscribed after the emit got nothing.<\/p>\n\n
Version 2: Channel keeps the event, then loses it differently<\/h2>\n\n
The next fix swaps in a Channel<\/code>. It buffers, so an event sent while nobody collects waits for the next receiver.<\/p>\n\n\n
private val _events = Channel<LoginEvent>(Channel.BUFFERED)\nval events = _events.receiveAsFlow()<\/pre>\n\n\n
That fixes the background case above. In our run, a late receiver got ToHome<\/code>. But a Channel<\/code> hands each value out once. Receiving it removes it. If the collecting coroutine is cancelled after receiving and before navigate()<\/code> runs, the event is gone. The lifecycle stopping at the wrong moment does exactly that. We simulated it by cancelling the receiver mid-handling. The next collector got nothing.<\/p>\n\n
The window is small. That’s why this passes manual testing. Google’s UI events guide<\/a> names the risk. When the ViewModel outlives the Compose UI, these streams “don’t guarantee the delivery and processing of those events.”<\/p>\n\n
Version 3: reduce one-time events in Jetpack Compose to state<\/h2>\n\n
The same guide gives the fix. “Handle such events immediately and reduce them to UI state.” For login, the event becomes a fact about the screen.<\/p>\n\n\n
data class LoginUiState(\n    val isLoading: Boolean = false,\n    val isUserLoggedIn: Boolean = false,\n)\n\nfun login() = viewModelScope.launch {\n    _uiState.update { it.copy(isLoading = true) }\n    repository.login()\n    _uiState.update { it.copy(isLoading = false, isUserLoggedIn = true) }\n}\n\n\/\/ in the composable\nval state by viewModel.uiState.collectAsStateWithLifecycle()\nLaunchedEffect(state.isUserLoggedIn) {\n    if (state.isUserLoggedIn) onUserLogIn()\n}<\/pre>\n\n\n
A StateFlow<\/code> always holds its latest value. When the user comes back, the screen collects again and reads isUserLoggedIn = true<\/code>. It navigates then. Nothing depended on being subscribed at the right instant. In our run, a collector that attached after the update still saw it.<\/p>\n\n
The catch: the screen stays on the back stack<\/h2>\n\n
Version 3 works because Login isn’t kept on the back stack. The guide points out that if screen A stays on the stack, it may keep advancing to B. Say the user goes back from Home to Login. isUserLoggedIn<\/code> is still true. The effect runs again and pushes Home again.<\/p>\n\n
So the UI has to record that it acted. The guide’s back-stack example keeps that extra flag in the UI. The simpler version below mirrors its pattern for messages. The UI calls back once it acted. Then the ViewModel clears the state.<\/p>\n\n\n
LaunchedEffect(state.isUserLoggedIn) {\n    if (state.isUserLoggedIn) {\n        onUserLogIn()\n        viewModel.onNavigatedToHome() \/\/ sets isUserLoggedIn back to false\n    }\n}<\/pre>\n\n\n
The flag now lives until the UI confirms it handled it. That’s the difference from a Channel<\/code>. The event isn’t removed on receipt. It’s removed on completion.<\/p>\n\n
Two limits are worth knowing. The state lives in the ViewModel, so process death still clears it. Route it through SavedStateHandle<\/code> if that matters. And if several events can queue up, use a list in state. The guide points to the Jetsnack sample<\/a> for a queue of messages.<\/p>\n\n
The rule to remember<\/h2>\n\n
An event that must happen is state until the UI says it happened.<\/strong><\/p>\n\n