More flexible modality.

[rjrjr]

Introduces the ModalOverlay interface. Moves as much code as possible from BodyAndModalsContainer to LayeredDialogs, and allows them to turn on modal event blocking behavior per managed Overlay instance, rather than always enforcing it.

Very sad that I wasn't able to get rid of BodyAndOverlaysContainer.onAttachedToWindow, but the SavedStateRegistry timing is just too fussy to allow it.

Git was dumb about diff'ing across renames, so they aren't all done in the first commit for ease of review.

[steve-the-edwards]

Empty doc?

[rjrjr]

Thanks.

  /**
   * The unique `SavedStateRegistry` key passed to [LayeredDialogs.onAttachedToWindow],
   * derived from the first rendering passed to [update]. See the doc on
   * [LayeredDialogs.onAttachedToWindow] for details.
   */

[steve-the-edwards]

SO this is how we specify whether to block events around overlays now?

[rjrjr]

Big response here, I'll update the commit message to include it, once you confirm it's intelligible.

This isn't new, I just renamed it from ModalOverlayArea b/c it's not specific to modal behavior. OverlayArea is still how we broadcast the bounds of the view under the dialogs, so that the dialogs' size and position can be restricted to that area. It's always been about positioning, not modality. And it's mainly about making sure that the dialog isn't too big, e.g. so that we can build status and tutorial bars that don't get eclipsed by our modal windows.

[ StatusBarContainer ]
[ BodyAndOverlaysContainer ]
[ TutorialBarContainer ]

OverlayArea here tracks the size and position of BodyAndOverlaysContainer, so any related dialog windows won't stray over the status or tutorial bars while they're visible. None of that changes with this PR.

The big change here is related to the tricky code we've built to make covered views start ignoring events the instant we decide to show a dialog, because there is a period after the call to Android's Dialog.show() where events that should be intercepted by the new dialog window aren't. It's fundamentally about when we set allowEvents fields in DialogHolder and LayeredDialogs to true or false.

While allowEvents is false, the covered view ignores all UI events, regardless of the size of the dialog windows above it. In our illustration above, even if the dialog windows over the body in BodyAndOverlaysContainer decide to be tiny, the body will ignore all events while any dialog is showing.

Previously, LayeredDialogs.modal was set at construction time, and BodyAndModalsContainer set it to true. That meant that we wanted all managed dialog windows to be considered modal, meaning allowEvents should be false while any of them are visible. So, if you wanted to use smaller dialog windows for something like a floating toast, which should not block events, you're hosed. You have to fork BodyAndModalsContainer to create LayeredDialogs with modal false, and have a separate wrapping container to host your non-modal toasts.

With this PR, LayeredDialogs looks for the ModalOverlay marker interface. LayeredDialog.allowEvents is set to false only if one of the managed Overlay renderings also implements ModalOverlay. DialogHolder.allowEvents is set to false only for dialogs whose z index is lower than a ModalOverlay sibling.

Also note how we still look for the value of the CoveredByModal ViewEnvironment value while deciding if we're in that situation, so that it's still possible to nest BodyAndOverlayContainers.

[rjrjr]

I'm adding this discussion to the kdoc on ScreenOverlayDialogFactory in the next PR, gonna merge this as is.