Disabling back on a specific screen

[troyjperales]

Is there a way to disable system back presses for a screen that doesn't interfere with calls to navigator.pop() in the corresponding presenter?

[ZacSweers]

You can always bring your own BackHandler that would take priority. This is more of a general compose question than circuit.

[troyjperales]

I first attempted adding a BackHandler with an empty onBack at the screen UI level. When I did, calls to navigator.pop() stopped working in the presenter. This makes sense since the UI BackHandler is the most-nested BackHandler.

@Parcelize
data object DisabledBackScreen : Screen {
    data object UiState : CircuitUiState
}

class DisabledBackPresenter(
    val navigator: Navigator,
): Presenter<UiState> {

    @Composable
    override fun present(): UiState {
        LaunchedEffect(Unit) {
            delay(5.seconds)
            navigator.pop() // Will be consumed and ignored by UI BackHandler
        }

        return UiState
    }
}

@Composable
fun DisabledBackUi(
    state: UiState,
) {
    BackHandler {
        // Empty to ignore user back presses
    }
}

Next, I added a shouldDisableBack parameter in the screen state to control when the above BackHandler was enabled. I would then update this parameter to disable the BackHandler just before popping the screen. Unfortunately, this requires delaying the call to pop enough for the UI to render the state, which is counter-intuitive since we are already in a state to leave the screen.

@Parcelize
data object DisabledBackScreen : Screen {

    data class UiState(
        val shouldDisableBack: Boolean,
    ) : CircuitUiState
}

class DisabledBackPresenter(
    val navigator: Navigator,
): Presenter<UiState> {

    @Composable
    override fun present(): UiState {
        var shouldDisableBack by remember { mutableStateOf(true) }

        LaunchedEffect(Unit) {
            delay(5.seconds)
            shouldDisableBack = false
            navigator.pop() // Will be ignored since shouldDisableBack has not changed in UI yet
        }
        
        return UiState(shouldDisableBack)
    }
}

@Composable
fun DisabledBackUi(
    state: UiState,
) {
    BackHandler(enabled = state.shouldDisableBack) {
        // Empty to ignore user back presses
    }
}

While I get this is related to how back-handling behaves in Compose, I'm at a loss for how to make this work with Circuit.

[troyjperales]

This is the best solution I could come up with—launching another effect for navigating after disabling the UI empty BackHandler.

@Parcelize
data object DisabledBackScreen : Screen {

    data class UiState(
        val shouldKeepShowingScreen: Boolean,
    ) : CircuitUiState
}

class DisabledBackPresenter(
    val navigator: Navigator,
) : Presenter<UiState> {

    @Composable
    override fun present(): UiState {
        var shouldKeepShowingScreen by remember { mutableStateOf(true) }

        LaunchedEffect(Unit) {
            delay(5.seconds)
            shouldKeepShowingScreen = false
        }

        LaunchedEffect(shouldKeepShowingScreen) {
            if (!shouldKeepShowingScreen) {
                navigator.pop()
            }
        }

        return UiState(shouldKeepShowingScreen)
    }
}

@Composable
fun DisabledBackUi(
    state: UiState,
) {
    BackHandler(enabled = state.shouldKeepShowingScreen) {
        // Empty to ignore user back presses
    }
}

It's not a very obvious solution for a use case that is fairly common.

Also, this is not due to a shortcoming of Circuit, but rather the Compose back-handling paradigm within any UDF-based UI architecture.

[stagg]

I think you could not use this rememberCircuitNavigator with a BackHandler, and instead create your own with a custom BackHandler? Can provide your own logic to enable/disable based on the current back stack (ie Screen type).

[troyjperales]

@stagg While that is another option, I'd prefer to configure this at the screen level versus keeping a list of back-disabled screens.

[stagg]

Oh thats fair!
Had thought this might be doable with a common interface that screens could implement to op-out of back handling.
Think you're going to have to work within the Compose problem of nested BackHandlers then.

[troyjperales]

That's a great suggestion, but I can't see around the need for the Presenter to trigger disabling the empty BackHandler just before the navigator.pop(). Can you?

[stagg]

Think if it's at the Screen level you can disable it once the backstack updates when navigating. Anything more granular you'll need to reach up out of the presenter to disable it, maybe a custom local can do that, not sure.