Does anyone know if `ModalBottomSheetLayout` will ...

# compose-android

[Lucas Kivi]

Does anyone know if ModalBottomSheetLayout will be ported to Material3? The Material3 ModalBottomSheet has some limitations that make it unusable for me. I either need to hack up the BottomSheetScaffold or use the Material ModalBottomSheetLayout and suppress the UsingMaterialAndMaterial3Libraries warning.

[jossiwolf]

No, Material 3's ModalBottomSheet is the API shape we're committed to. The team is currently considering some API changes to enable a broader range of use cases, no details on that yet though.
What are the limitations you're facing?

[Lucas Kivi]

Awesome. I have been thinking about this a lot and I actually agree. The layout aspect is not necessary. And as far as the issues I am having with ModalBottomSheet , I am glad you asked.
1. I need to be able to disable user dragging. There is already a ticket for this erroneously marked as a duplicate.
2. It seems a little weird that we need to wrap the ModalBottomSheet in an if statement (due to the fact that when the ModalBottomSheet enters the composition it animates open if it has an expanded state). I could elaborate on this, but I am not sure that you are curious about it. I feel like this would work best if we just had a way to intercept any attempt to dismiss the sheet so we could hand it off the VM, update our state, and manually animate the sheet closed.

[Lucas Kivi]

I am actually very intrigued to hear what you say about that user dragging issue. I have a work around that is non-ideal using the ModalBottomSheetLayout but I would rather just wait for the updated ModalBottomSheet API if it is going to be something that sees the light of day. Currently migrating away from a BottomSheetDialogFragment .

[jossiwolf]

1. Yeah, that request is being tracked in b/288211587. The feature has been implemented in M2, so the issue is marked fixed correctly. This wouldn't be addressed by other API updates though
2. There's no need to do that - you could keep the sheet in composition the entire time. We might need the ability to configure auto-showing the sheet on composition though if I understand your use case correctly. I'd encourage you to report an issue with more details 🙂

[Lucas Kivi]

1. Interesting. Are you saying that fixing this is not related to the work you are doing to update the API? I do hope that it is ultimately picked up, it does block my migration to a full compose solution here. Right now I am nesting my composable screen in a BottomSheetDialogFragment to get the behavior I want.
2. Ok. I will see what I can do about that. Even when it is hidden it still consumes clicks and stuff which I didn’t even realize before!

[Lucas Kivi]

I am not sure this deserves a bug ticket @jossiwolf. I ask you to check it again just so I don’t waste someone else’s . I will restate the problem.

My problem is two-fold.
1. It is required that you conditionally show ModalBottomSheet if you want to interact with content behind it and avoid the sheet animating open as soon as it enters the composition.
2. I wish I could override clicks outside of the sheet’s content. This is handled by the animateToDismiss lambda on the Scrim in the implementation. This way I can go to the VM, and back to the UI, and animate the sheet away.
Here is a bit of code for reproduction of problem 1.

Surface(modifier = Modifier.fillMaxSize(), color = MaterialTheme.colorScheme.background) {
    Column(
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.Center,
        modifier = Modifier.fillMaxSize()
    ) {
        Button(
            onClick = { scope.launch { sheetState.show() } },
        ) {
            Text(text = "Open dialog")
        }
    }
}

ModalBottomSheet(
    containerColor = Color.Cyan,
    onDismissRequest = { },
    sheetState = sheetState,
) {
    Spacer(
        modifier = Modifier
            .fillMaxWidth()
            .height(200.dp)
    )
}