Dialogs isn't dismissed when workflow stops rendering it without interaction on the dialog itself

[zach-klippenstein]

If a workflow renders a dialog with a listener on the buttons that result in the dialog no longer being rendered, everything is fine.

However, if the workflow suddenly stops rendering the dialog without the user having clicked on the dialog buttons, the dialog is not dismissed.

Repro steps:

1. Render a dialog with AlertContainerScreen.
2. After a timeout, stop rendering it. Dialog will still be around.

Repro project: https://github.com/square/droidcon-nyc-2019-workflow-game (win the game, then enter time travel mode and scrub past the "game over" dialog)

[zach-klippenstein]

It looks like ModalContainer should already be doing this:

https://github.com/square/workflow/blob/1329c822c3fc543a809372501bd068094e37b9af/kotlin/workflow-ui-android/src/main/java/com/squareup/workflow/ui/ModalContainer.kt#L90

[rjrjr]

Not as simple as it sounds, naturally. If I reproduce the recipe literally (show an alert, fire a two second timeout worker that moves to a non-alert state), the dialog is torn down as expected.

[zach-klippenstein]

I wonder if it has something to do with how that demo ends up wrapping the ModalContainer in another layout?

[zach-klippenstein]

I believe this is caused by the combination of square/workflow#609 and the fact that the root workflow is actually doing the wrong thing - it should have a rendering type of AlertContainerScreen and only vary what it passes as the modal list.

On iOS, this bug would manifest as the modals appearing and disappearing without the proper animation, since modals on iOS (at least the way they're implemented with workflows) are entirely rendered and animated by their container view.

Fixing square/workflow#609 should resolve this issue, but we should also fix the root workflow to be more idiomatic.

[zach-klippenstein]

Not including in 1.0 since this is a behavior fix, not an API change.