A modern programming language that makes developers happier.

kotlinlang

Can you not preview AlertDialogs in Compose?

Haven't tried it myself but I guess you can't preview it because it creates a new window.

Yeah, `AlertDialog/Popup/DropDownMenu` has a bit hacky implementation. I understand they need to show it on top of the rest of UI, but doing it this way(create a new window with a separate ComposeView) I believe this was a quick code path. And because of that, it has issues with positioning and previewing. I wish Compose had an `Overlay` widget concept like Flutter.

The approach of using the system window manager for this is correct interop with the system, not a hack. Preview and layoutlib's implementation of Android's window management is a separate question.

Can you explain why it’s correct? Specifically if there’s any gotchas to be aware of if anyone were to try and implement other overlay-type components (e.g. coachmarks) or customize them to our Design Systems (e.g. different enter animations)

Many window management policies are set and implemented by the platform window manager. This includes things like dialog sizing, focus behavior, dialog placement and anchoring to parent windows, and interactions with the soft keyboard

The reason Android has always used child windows to implement things like text selection handles is because they can interleave with things like the soft keyboard window, allowing them to overlap it for targeting and usability if a text field appears right next to it. (And for any sort of chat-like app, it often does.)

Activity windows are always beneath the soft keyboard, for example.

On something like the web you generally have no choice but to do modal dialog-like things with overlays because the browser gives you no other choice. Other platforms have other expectations around native behavior.

It may not seem like this matters much at first on a phone in a pretty common configuration, but if you have a drop-down menu, Android will generally let it expand over the soft keyboard if it's present, dialogs can have different positioning policies in multi-window modes, etc.

&gt; and interactions with the soft keyboard…expand over the soft keyboard if it’s present
This is what I was conceptually missing. :thank-you: :bow: