Does anyone know if there’s a way to disable the swipe away gesture on a ModalBottomSheetLayout? I ...

# compose

[mattinger]

Does anyone know if there’s a way to disable the swipe away gesture on a ModalBottomSheetLayout? I can veto the change so that the sheet stays up, but id rather the user not be able to drag the content away in that case. why let them drag to dismiss if we’re just going to veto it anyway? A related question is that if i decide to allow a click outside or for them to swipe it away, is there a way to react that that?

[chatterInDaSkull]

rememberModalBottomSheetState(
        initialValue = ModalBottomSheetValue.Hidden,
        skipHalfExpanded = true,
        confirmStateChange = { false }, <-this is what makes the difference
    )

[chatterInDaSkull]

this will make it non-dismissable. Rather it’ll only make it programmatically dismissable.

[chatterInDaSkull]

basically look into confirmStateChange

[mattinger]

@chatterInDaSkull That only vetos the change (which i mentioned above that I can do). What i want to do is to entirely disable the swipe gesture. There’s no point in allowing them to swipe the sheet down if we’re going to veto the state change.

[mattinger]

(also i’m on compose 1.1 still, so i don’t have the skipHalfExpanded, but i can accomplish that in the confirmStateChange

[mattinger]

@OptIn(ExperimentalMaterialApi::class)
@Composable
fun rememberBottomSheetState(skipHalfExpanded: Boolean, allowDismiss: Boolean) =
    rememberModalBottomSheetState(
        initialValue = ModalBottomSheetValue.Hidden,
        confirmStateChange = {
            when (it) {
                ModalBottomSheetValue.HalfExpanded -> !skipHalfExpanded
                else -> allowDismiss
            }
        }
    )

[jossiwolf]

We have an FR for this open: https://issuetracker.google.com/186669832
No workaround currently though

[mattinger]

The other option i might want to do is to allow a dismiss, but i want to respond to the dismiss. Right now there’s on callbacks on that from what i can tell. The only thing i can do is look at the change to the state. But that’s a really ugly solution because you’d have to keep track of why it was being dimissed to figure out if you did it programatically or if it was user swipe or a button press or something.

[mattinger]

Thank you @jossiwolf This is helpful to at least know it’s got a tracker ticket. I’m open to suggestiosn on my other option which is to allow the dismiss but be able to properly respond to it.

[mattinger]

The use case for this is treat the dismiss (ie tappign on the scrim) akin to a cancel button, which we might want to respond to somehow.