Is there a way to dismiss a `SheetState` such that...

# compose

[Zoltan Demant]

Is there a way to dismiss a SheetState such that onDismiss is invoked when the animation is finished? Example code in 🧵

[Zoltan Demant]

Im doing the following currently. It works, but I dont like having magic numbers in there 😱 Without the delay, the sheet is removed a bit abruptly.

scope.launch {
state.hide()

delay(150)

// exactly what my onDismiss function does
emitter emit Dismissed
}

[Stylianos Gakis]

Which sheet are you using?
The material(3?) sheets mark the hide() function as suspending, which means that when the coroutine resumes after it’s done with hide() it really should’ve been done with the animation already, have you found this not to be the case for you?

[Stylianos Gakis]

https://cs.android.com/androidx/platform/tools/dokka-devsite-plugin/+/master:testDat[…]3?q=androidx.compose.material3.samples.ModalBottomSheetSample
This also shows an example of them doing this, letting the hide() finish, and then dismissing the dialog completely by setting the state to false too.

[Zoltan Demant]

Yup, thats exactly what Im seeing. Thanks for the link - Ill try using invokeOnCompletion on the job, the timing is just off by ~100 ms so maybe that works? Ill report back!

[Zoltan Demant]

Muy buen, that works better. Thank you! I do wonder if this is worth reporting? Seems more like a workaround using invokeOnCompletion than placing the logic right after .hide since its suspending.

[Stylianos Gakis]

The thing is, this

launch {
  someSuspendFunction()
  yourCallback()
}

should really be the exact same thing as

launch {
  someSuspendFunction()
}.invokeOnCompletion {
  yourCallback()
}

since the coroutine should suspend inside hide() until it’s properly done.

[Stylianos Gakis]

So yeah it certainly feels super odd that it’s any different in your case 😵‍💫

[Stylianos Gakis]

Is the coroutine scope grabbed simply using rememberCoroutineScope?

[Zoltan Demant]

Yup!

[Stylianos Gakis]

Suuuper odd

[Stylianos Gakis]

I really can’t think of a reason why that’d be the case. Which sheet is it that you’re using then? Maybe the hide() implementation is broken for what you’re using?

[Stylianos Gakis]

Returns too early?

[Zoltan Demant]

0,00001% chance that my debug build is actually the culprit

[Stylianos Gakis]

Or you got some other part in the code which listens to the state change and triggers the callback too early

[Stylianos Gakis]

0,00001% chance that my debug build is actually the culprit

Always possible 😅

[Zoltan Demant]

Dang it, Ill have to test with a release build.. Brb

[Stylianos Gakis]

Haha sorry for doing this to you 🫣

[Zoltan Demant]

As it turns out, I just dont like the hide animation of the sheet. The delay I was using was just placebo, it doesnt really do any difference 😅 The default animation is val AnimationSpec = SpringSpec<Float>() and it makes me wonder if the lack of visibilityThreshold is causing the sheet to hide prematurely. Ill have to test this further before I can say for sure.

[Stylianos Gakis]

Heh alright, nice to see it’s not a flat out bug though. Lmk if it works out well for you after all

[Stylianos Gakis]

Oh I think I understand why they do the invokeOnCompletion in that code. The coroutine may be cancelled somehow in the meantime as it’s doing the hide() call. If you do the cleanup after it it won’t ever run in case of cancellation I don’t think. With the completion callback it should run always.
So I think that’s why they do it, not for any timing issues.

[jossiwolf]

Yes, keep in mind that hide() or show() can be cancelled and would throw a CancellationException in that case. invokeOnCompletion vs try-catch doesn't make a difference in this case 🙂

[Zoltan Demant]

It would be detrimental for hide to do its thing, but the onDismiss not coming through - basically making the UI "under" the sheet unresponsive, so that makes sense.

[Stylianos Gakis]

invokeOnCompletion vs try-catch

Yeah I was comparing it with this, which would in fact be wrong right? The first option would not work properly in case of cancellation

[jossiwolf]

Yes, the job would be cancelled if someSuspendFunction() throws and yourCallback() never executed

[efemoney]

Narrator: Foot, meet Gun