A modern programming language that makes developers happier.

kotlinlang

codi.png

If anyone can help me (and the 38 :star2:) figure out why <https://issuetracker.google.com/issues/270983047|dialogs in compose fail to dim the content underneath them>; Ill be eternally grateful. Currently well on our way into the 9:th month of not being able to publish any updates to the play store :smiling_face_with_tear: More details in thread :thread:

This only happens on emulators for me, and apparently for other people too (in issue comments)

Most of the details are available in <https://issuetracker.google.com/issues/270983047>

But the gist of it is that using any kind of Dialog in compose will simply result in it being drawn over all other content, without the dim/scrim effect. This applies to Dialog, AlertDialog, etc. I believe this started happening around the time compose 1.2.0 rolled out.

Ive looked into simply faking the scrim effect, using something like the code below. This effectively works, but there are devices/configurations out there where the original scrim *does work*; and in my case that results in updates being rejected due to confusing UX (ironically, same as if there was no scrim at all). The workaround code is below, the dialog is inside the `Box:content`.

```    Box(
        Modifier.fillMaxSize().drawBehind {
            drawRect(
                color = Color.Black,
                alpha = alpha,
            )
        },
    )```
Ive tested it on a bunch of different emulators; and real devices - Pixel 2, 6, 7; Samsung S22 Ultra, Huawei P30 Pro, OnePlus 5T. All present the exact same behavior for me.

This is slowly killing my business, but I still love compose :heart: I just hope that we can figure something out together.

<@U05NMHG9QMB> Yup, unfortunately seeing it on both real &amp; emulators in my case!

Not saying this shouldn't be fixed but why can't you use your own implementation in production while waiting for this to be fixed? I don't use Dialog myself so not sure if there's something special it does

<@U03M3G2TX9A> I would think so too. A major part of the problem for me is that dialogs handle OEM and API discrepancies automatically; and while I can build something that looks like a dialog very easily in compose, the behavior is very hard to get right across the entire spectrum.

Upon some further reflection, the main pain points that I havent been able to overcome are:
• Drawing the fake dialog over everything else, in the right place, without it having any layout constraints from the parent composable or window. 
• Have it use the correct sizing across devices, API levels, etc.
• Focus, key events and all of that jazz (this is what gets flagged by the Google review team) 
You can also check out what Dialog does under the hood, I dont think any of the composition specific behavior is required for my use-case, but all of the layout stuff is and its very hard to recreate :smiley: