Handling user feedback like showing a Snackbar, navigating, or triggering a one-off animation is essential in any application. In Jetpack Compose, a common and tricky bug arises when these actions are treated like standard UI state, leading to them being triggered multiple times upon recomposition.

To build a robust Compose app, we must fundamentally distinguish between State (the current description of the UI) and Effect (a one-time action that the UI must perform).

Let’s dive into the problem, why modeling an event as state is flawed, and how to correctly implement the ViewEffect pattern using SharedFlow versus Channel.

The Core Mistake: Treating UI State as an Event Sink

The core conceptual error is confusing persistent state (what the UI is) with a transient effect (what the UI must do once). In the login scenario, navigating to the home screen is a one-time action, but by modeling it as the persistent state field isLoggedIn: Boolean, we introduce a dangerous loop.

The Flawed Implementation: Login State as Navigation Trigger

Let’s look at the provided code. The ViewModel successfully updates the LoginUiState after a simulated successful login:

// --- Flawed ViewModel Implementation ---
data class LoginUiState(
    val isLoading: Boolean = false,
    val isLoggedIn: Boolean = false // Persistent state used for one-time navigation
)

class LoginViewModel : ViewModel() {
    // ...
    fun login() {
        viewModelScope.launch {
            // ... API logic ...
            // On success, this line sets the flag, which is now persistent!
            _uiState.update { it.copy(isLoading = false, isLoggedIn = true) }
        }
    }
}

The problem manifests entirely in the LoginScreen Composable where the navigation logic depends directly on this persistent flag:

// --- LoginScreen Composable ---
@Composable
fun LoginScreen(...) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()
    // Flaw: LaunchedEffect keys on a persistent state field.
    LaunchedEffect(uiState.isLoggedIn) {
        if (uiState.isLoggedIn) {
            onLoginSuccess() // Triggers navigation (the one-time action)
        }
    }
    // ... UI ...
}

Press enter or click to view image in full size

The Mechanism of the Replay Bug

Here is why this approach leads to unwanted repetitions:

1. State Persistence: After successful login, the state is permanently set to isLoggedIn = true. This flag’s purpose is fulfilled the moment navigation starts, but the flag itself doesn’t reset.
2. Recomposition Trigger: Compose is designed to redraw the UI whenever any dependent state changes. However, recomposition happens frequently for other reasons too — device rotation, UI size changes, or even an unrelated timer running elsewhere in the UI tree.
3. Effect Repeats: Every time the LoginScreen recomposes, the LaunchedEffect block checks its key: uiState.isLoggedIn. Since this key is still true (it never changes back to false), Compose determines the side effect needs to be run again. This forces repeated calls to onLoginSuccess(), potentially causing navigation attempts to loop or crashing the app.

The core rule being violated is: Recomposition is not Event Consumption. The LaunchedEffect must react only once to an action, not continuously to a persistent truth.

The Flawed Fix: The Anti-Pattern of State Reset

When developers realize the first approach leads to repeated actions, they often attempt a “fix” by manually resetting the state immediately after the action is consumed. This requires introducing a new function in the ViewModel (onLoginHandled()) and calling it from the Composable.

The Code Demonstrating the Flawed Fix

This approach attempts to break the loop by clearing the isLoggedIn flag as soon as navigation is triggered:

// --- ViewModel with State Reset Logic ---
class LoginViewModel : ViewModel() {
    // ... State setup ...
    fun login() { /* ... updates isLoggedIn = true on success ... */ }

    fun onLoginHandled() {
        // The Reset: ViewModel function to clear the flag
        _uiState.update { it.copy(isLoggedIn = false) }
    }
}

// --- Composable Executing the Reset ---
@Composable
fun LoginScreen(onLoginSuccess: () -> Unit, viewModel: LoginViewModel = viewModel()) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

    LaunchedEffect(uiState.isLoggedIn) {
        if (uiState.isLoggedIn) {
            onLoginSuccess()        // 1. Action executed (Navigation)
            viewModel.onLoginHandled() // 2. State immediately reset (Clears isLoggedIn)
        }
    }
    // ... UI ...
}

This “fix” is an anti-pattern for critical reasons:

1. Violation of UDF Intent: The UI layer is performing state modification, confusing the responsibility of the ViewModel.
2. Unreliable/Lifecycle Issues: If the LaunchedEffect is cancelled before the viewModel.onLoginHandled() call, the isLoggedIn state persists, and the event will fire incorrectly later.
3. Loss of Composition Context: In case of state using sealed interface Resource<T>, clearing the state might incorrectly reset the UI back to a placeholder state (Resource.Success(null)), causing the entire Composable to recompose with new data, even though the user was looking at the persistent error screen. The persistent UI elements (like a “Retry” button) tied to Resource.Error vanish unnecessarily.

This anti-pattern fixes the symptom of repeated events but creates a highly coupled, brittle, and lifecycle-unsafe system. The correct solution must handle the transient action outside the persistent state model.

The Solution: ViewEffect with Flow Comparison

The ViewEffect pattern uses a separate hot flow to emit actions that are consumed once. The choice is usually between SharedFlow and Channel.

1. SharedFlow Implementation

The SharedFlow approach is a popular method for implementing the ViewEffect pattern due to its straightforward syntax and efficiency. It requires defining a dedicated, zero-replay hot flow to carry the transient actions.

SharedFlow Implementation Code

This code demonstrates the pattern by setting up a LoginEffect sealed interface and using a correctly configured MutableSharedFlow to expose actions:

data class LoginUiState(
    val isLoading: Boolean = false
)

sealed interface LoginEffect {
    data object NavigateToHome : LoginEffect
}

// --- ViewModel using SharedFlow ---
class LoginViewModel : ViewModel() {
    // ... State (isLoading) ...

    private val _effect = MutableSharedFlow<LoginEffect>() // Default replay = 0
    val effect: SharedFlow<LoginEffect> = _effect.asSharedFlow()

    fun login() {
        viewModelScope.launch {
            // ... login logic ...
            _uiState.update { it.copy(isLoading = false) }
            _effect.emit(LoginEffect.NavigateToHome) // Emits the action
        }
    }
}

// --- Composable Collecting SharedFlow ---
@Composable
fun LoginScreen(...) {
    val lifecycleOwner = LocalLifecycleOwner.current

    LaunchedEffect(viewModel.effect, lifecycleOwner) {
        // We use repeatOnLifecycle(STARTED) to ensure we only collect when the screen is visible.
        lifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
            viewModel.effect.collectLatest { effect ->
                if (effect is LoginEffect.NavigateToHome) {
                    onLoginSuccess()
                }
            }
        }
    }
    // ... UI ...
}

This implementation successfully separates the navigation action from the UI’s persistent state, immediately solving the repeat-trigger bug. However, using SharedFlow for one-time events introduces technical challenges regarding guaranteed delivery.

While SharedFlow is highly configurable — you can set a non-zero buffer capacity and a replay cache — when attempting to manage a reliable, non-repeating effect, its properties are constrained:

• Configured for Zero Replay: For one-time events, we must set the replay cache to zero (replay = 0) to prevent the event from being re-fired to new collectors.
• Buffer Ineffectiveness for Guarantee: Even if you configure a buffer, the fundamental structure of SharedFlow is distribution. If the event is emitted while the collector is paused (due to lifecycle changes), and the buffer is cleared or overwritten before the collector resumes, the event may be missed. The system lacks a mechanism to ensure the event waits for a specific consumer.

This technical vulnerability leads to Potential Event Loss, which is a concern for actions like navigation. If the navigation event is emitted from the ViewModel at the exact moment the Composable’s flow collector is inactive — such as during a screen rotation — the event has no active recipient and may be discarded.

2. Implementation: Channel

Channel in Kotlin Coroutines is a synchronization primitive that acts as a suspension-safe queue, allowing the transfer of a stream of elements between coroutines (producers and consumers).

It functions like a mailbox: when a producer calls send(), the element is placed into the channel’s buffer. The element remains there until a consumer calls receive(). This makes it ideal for the ViewModel-to-UI flow, ensuring the event waits for the single, intended receiver.

// --- Channel ViewModel Implementation ---
class LoginViewModel : ViewModel() {
    // ... State (isLoading) ...

    private val _effect = Channel<LoginEffect>() // The robust event queue
    val effect = _effect.receiveAsFlow() // Expose as a consumable Flow

    fun login() {
        viewModelScope.launch {
            // ... login logic ...
            _uiState.update { it.copy(isLoading = false) }
            _effect.send(LoginEffect.NavigateToHome) // Sends the action to the queue
        }
    }
}

However, it does not offer an absolute 100% guarantee against loss due to a specific, extremely rare cancellation race window that occurs during Activity destruction and recreation (e.g., screen rotation).

This loss occurs because, in the brief window between when the old LaunchedEffect coroutine is cancelled and the new one is started, if the event is emitted at that precise moment, the event could potentially be dropped, even by the Channel’s queue.

But there is a workaround of using Dispatchers.Main.immediate to eliminate this final vulnerability by forcing the execution path to be atomic (indivisible) on the main thread.

The core idea is to ensure the coroutine that handles the collection executes its work synchronously on the main thread, eliminating any suspension points where the cancellation race window could occur therefore there is no possibility of event loss.

@Composable
fun LoginScreen(...) {
    // ...
    LaunchedEffect(Unit) {
        lifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
            
            // FORCES synchronous execution of the flow consumption logic
            withContext(Dispatchers.Main.immediate) { 
                viewModel.effect.collect { effect ->
                    // Consumption happens synchronously here
                    if (effect is LoginEffect.NavigateToHome) {
                        onLoginSuccess()
                    }
                }
            }
        }
    }
    // ...
}

However, for most standard applications, the basic Channel implementation offers more than sufficient reliability and is far simpler to maintain. Only implement this workaround if your specific application has an extremely low tolerance for any event loss.

Channel Vs SharedFlow for One-Time Events

Which Mechanism is Better to Use?

Based on the analysis of reliability and developer experience, I recommend using Channels as the preferred approach for handling single one-time events, especially when implementing the event loss prevention technique.

Why You Should Avoid Other Options

• Avoid Shared Flows: Shared Flows are discouraged for single one-time events because they are essentially Channels that force you to manually manage the buffer/replay cache. They are conceptually better suited for scenarios requiring multiple listeners, which is typically unnecessary for a single UI action.
• Avoid Modeling as State: While using State (like StateFlow) prevents event loss entirely, it introduces a significantly greater risk of bugs. This is because the developer must always remember to manually reset the state after it has been consumed (e.g., setting an isNavigationPending flag back to false). Forgetting this manual reset is a common oversight that can cause the event (like navigation or a dialog) to unexpectedly trigger repeatedly, leading to a poorer user experience. This risk is magnified on larger teams, especially those including junior developers, where knowledge transfer gaps or simple human error make it much more likely that the required state-resetting logic will be forgotten or implemented incorrectly across different feature screens.

This article was previously published on proandroiddev.com