Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Buttons on successive AlertScreen renderings are not respected #138

Closed
christiandeange opened this issue Jul 22, 2020 · 1 comment
Closed

Buttons on successive AlertScreen renderings are not respected #138

christiandeange opened this issue Jul 22, 2020 · 1 comment
Assignees
@rjrjr
Labels
good first issue Good for newcomers help wanted Extra attention is needed modals ui Related to UI integration
Projects
Workflow Kotlin
Milestone
ui-1.0

Comments

@christiandeange
Copy link

When rendering two different AlertScreens in back-to-back render passes, the button contents do not seem to be updated by the AlertContainer properly.

First Rendering Second Rendering
AlertScreen(message = "Starting Checkout...", onEvent = {}) AlertScreen(message = "Waiting for checkout...", buttons = mapOf(NEGATIVE to "Cancel"), onEvent = { ... })
Screenshot_1595382241 Screenshot_1595382242

At first I was able to work around this locally by using some reflection to manually force the buttons to be re-bound to the UI again:

val buttonPanel = dialog.findViewById<ViewGroup>(androidx.appcompat.R.id.buttonPanel)
dialog.javaClass.getDeclaredField("mAlert")
    .let { mAlert ->
      mAlert.isAccessible = true
      mAlert[dialog].javaClass.getDeclaredMethod("setupButtons", ViewGroup::class.java)
          .let { setupButtons ->
            setupButtons.isAccessible = true
            setupButtons(mAlert[dialog], buttonPanel)
          }
    }

Eventually I just decided to implement my own AlertContainer-like container to subvert this entirely.
@rjrjr rjrjr added ui Related to UI integration good first issue Good for newcomers help wanted Extra attention is needed labels Jul 22, 2020
@rjrjr rjrjr added this to the post-v1.0.0 milestone Jul 22, 2020
@rjrjr rjrjr added this to To do in Workflow Kotlin Apr 15, 2021
@rjrjr rjrjr added the modals label Jul 6, 2021
@rjrjr rjrjr modified the milestones: post-v1.0.0, ui-1.0 Sep 15, 2021
@rjrjr rjrjr moved this from To do to In progress in Workflow Kotlin Dec 2, 2021
@rjrjr rjrjr self-assigned this Dec 2, 2021
rjrjr added a commit that referenced this issue Dec 2, 2021
@rjrjr
wip: Introduces ScreenOverlay and ModalScreenOverlayDialogFactory
c1c8f4a 
`ScreenOverlay` marks an `Overlay` with a `Screen` defining its content.

`ModalScreenOverlayDialogFactory` can show a `ScreenOverlay` as an
`android.app.Dialog`, taking care of updating the content view and managing
the Back button. It's the much simpler replacement for `ModalViewContainer`.

Also introduces two new `ViewEnvironment` values:

 - `ModalArea`, which allows dialogs to restrict themselves to a subset
   of the screen
 - `CoveredByModal`, used to disable touch and keyboard events reliably

Updates the Tic Tac Toe sample to use the new hotness. I think the diff of the
sample code really highlights how much the new marker interfaces improve our
composition story.

That said, the `ScrimScreen` bit in the sample is a little rough. In the old
code we magically swizzled the scrim into place automatically, and I think in
prod I would still do the same, but the sample is complex enough already.

For the record, it would be easy and clean to make panel-savvy alternative to
`BodyAndModalScreen` -- maybe `BodyAndPanelsScreen` -- that uses a
`DecorativeScreenViewFactory` to put the `ScrimScreen` in place and then
delegates to a `BodyAndModalScreen` to do the real work.

Fixes #259, #138, #99, #204, #314
@rjrjr rjrjr mentioned this issue Dec 2, 2021
Merged
rjrjr added a commit that referenced this issue Dec 2, 2021
@rjrjr
wip: Introduces ScreenOverlay and ModalScreenOverlayDialogFactory
eed7a6a 
`ScreenOverlay` marks an `Overlay` with a `Screen` defining its content.

`ModalScreenOverlayDialogFactory` can show a `ScreenOverlay` as an
`android.app.Dialog`, taking care of updating the content view and managing
the Back button. It's the much simpler replacement for `ModalViewContainer`.

Also introduces two new `ViewEnvironment` values:

 - `ModalArea`, which allows dialogs to restrict themselves to a subset
   of the screen
 - `CoveredByModal`, used to disable touch and keyboard events reliably

Updates the Tic Tac Toe sample to use the new hotness. I think the diff of the
sample code really highlights how much the new marker interfaces improve our
composition story.

That said, the `ScrimScreen` bit in the sample is a little rough. In the old
code we magically swizzled the scrim into place automatically, and I think in
prod I would still do the same, but the sample is complex enough already.

For the record, it would be easy and clean to make panel-savvy alternative to
`BodyAndModalScreen` -- maybe `BodyAndPanelsScreen` -- that uses a
`DecorativeScreenViewFactory` to put the `ScrimScreen` in place and then
delegates to a `BodyAndModalScreen` to do the real work.

Fixes #259, #138, #99, #204, #314
rjrjr added a commit that referenced this issue Dec 2, 2021
@rjrjr
wip: Introduces ScreenOverlay and ModalScreenOverlayDialogFactory
0bb52cb 
`ScreenOverlay` marks an `Overlay` with a `Screen` defining its content.

`ModalScreenOverlayDialogFactory` can show a `ScreenOverlay` as an
`android.app.Dialog`, taking care of updating the content view and managing
the Back button. It's the much simpler replacement for `ModalViewContainer`.

Also introduces two new `ViewEnvironment` values:

 - `ModalArea`, which allows dialogs to restrict themselves to a subset
   of the screen
 - `CoveredByModal`, used to disable touch and keyboard events reliably

Updates the Tic Tac Toe sample to use the new hotness. I think the diff of the
sample code really highlights how much the new marker interfaces improve our
composition story.

That said, the `ScrimScreen` bit in the sample is a little rough. In the old
code we magically swizzled the scrim into place automatically, and I think in
prod I would still do the same, but the sample is complex enough already.

For the record, it would be easy and clean to make panel-savvy alternative to
`BodyAndModalScreen` -- maybe `BodyAndPanelsScreen` -- that uses a
`DecorativeScreenViewFactory` to put the `ScrimScreen` in place and then
delegates to a `BodyAndModalScreen` to do the real work.

Fixes #259, #138, #99, #204, #314
rjrjr added a commit that referenced this issue Dec 3, 2021
@rjrjr
wip: Introduces ScreenOverlay and ModalScreenOverlayDialogFactory
e60df88 
`ScreenOverlay` marks an `Overlay` with a `Screen` defining its content.

`ModalScreenOverlayDialogFactory` can show a `ScreenOverlay` as an
`android.app.Dialog`, taking care of updating the content view and managing
the Back button. It's the much simpler replacement for `ModalViewContainer`.

Also introduces two new `ViewEnvironment` values:

 - `ModalArea`, which allows dialogs to restrict themselves to a subset
   of the screen
 - `CoveredByModal`, used to disable touch and keyboard events reliably

Updates the Tic Tac Toe sample to use the new hotness. I think the diff of the
sample code really highlights how much the new marker interfaces improve our
composition story.

That said, the `ScrimScreen` bit in the sample is a little rough. In the old
code we magically swizzled the scrim into place automatically, and I think in
prod I would still do the same, but the sample is complex enough already.

For the record, it would be easy and clean to make panel-savvy alternative to
`BodyAndModalScreen` -- maybe `BodyAndPanelsScreen` -- that uses a
`DecorativeScreenViewFactory` to put the `ScrimScreen` in place and then
delegates to a `BodyAndModalScreen` to do the real work.

Fixes #259, #138, #99, #204, #314
rjrjr added a commit that referenced this issue Dec 3, 2021
@rjrjr
Introduces ScreenOverlay and ModalScreenOverlayDialogFactory
032d5a8 
`ScreenOverlay` marks an `Overlay` with a `Screen` defining its content.

`ModalScreenOverlayDialogFactory` can show a `ScreenOverlay` as an
`android.app.Dialog`, taking care of updating the content view and managing
the Back button. It's the much simpler replacement for `ModalViewContainer`.

Also introduces two new `ViewEnvironment` values:

 - `ModalArea`, which allows dialogs to restrict themselves to a subset
   of the screen. `ModalScreenOverlayDialogFactory` applies this automatically
 - `CoveredByModal`, used by `BodyAndModalsContainer` and `LayeredDialogs` to
   disable touch and keyboard events reliably

In sample code, `PanelOverlay` replaces `PanelContainerScreen`, and the Tic
Tac Toe sample is updated to use the new hotness. I think the diff of the
sample code really highlights how much the new marker interfaces improve our
composition story.

That said, the `ScrimScreen` bit in the sample is a little rough. In the old
code we magically swizzled the scrim into place automatically. This PR
seems big enough already, so I'll follow up with a clean up that does
something similar and deletes all the deprecated sample code.

Fixes #259, #138, #99, #204, #314, #589
rjrjr added a commit that referenced this issue Dec 3, 2021
@rjrjr
Introduces ScreenOverlay and ModalScreenOverlayDialogFactory
15d629d 
`ScreenOverlay` marks an `Overlay` with a `Screen` defining its content.

`ModalScreenOverlayDialogFactory` can show a `ScreenOverlay` as an
`android.app.Dialog`, taking care of updating the content view and managing
the Back button. It's the much simpler replacement for `ModalViewContainer`.

Also introduces two new `ViewEnvironment` values:

 - `ModalArea`, which allows dialogs to restrict themselves to a subset
   of the screen. `ModalScreenOverlayDialogFactory` applies this automatically
 - `CoveredByModal`, used by `BodyAndModalsContainer` and `LayeredDialogs` to
   disable touch and keyboard events reliably

In sample code, `PanelOverlay` replaces `PanelContainerScreen`, and the Tic
Tac Toe sample is updated to use the new hotness. I think the diff of the
sample code really highlights how much the new marker interfaces improve our
composition story.

That said, the `ScrimScreen` bit in the sample is a little rough. In the old
code we magically swizzled the scrim into place automatically. This PR
seems big enough already, so I'll follow up with a clean up that does
something similar and deletes all the deprecated sample code.

Fixes #259, #138, #99, #204, #314, #589
rjrjr added a commit that referenced this issue Dec 3, 2021
@rjrjr
Introduces ScreenOverlay and ModalScreenOverlayDialogFactory
061c609 
`ScreenOverlay` marks an `Overlay` with a `Screen` defining its content.

`ModalScreenOverlayDialogFactory` can show a `ScreenOverlay` as an
`android.app.Dialog`, taking care of updating the content view and managing
the Back button. It's the much simpler replacement for `ModalViewContainer`.

Also introduces two new `ViewEnvironment` values:

 - `ModalArea`, which allows dialogs to restrict themselves to a subset
   of the screen. `ModalScreenOverlayDialogFactory` applies this automatically
 - `CoveredByModal`, used by `BodyAndModalsContainer` and `LayeredDialogs` to
   disable touch and keyboard events reliably

In sample code, `PanelOverlay` replaces `PanelContainerScreen`, and the Tic
Tac Toe sample is updated to use the new hotness. I think the diff of the
sample code really highlights how much the new marker interfaces improve our
composition story.

That said, the `ScrimScreen` bit in the sample is a little rough. In the old
code we magically swizzled the scrim into place automatically. This PR
seems big enough already, so I'll follow up with a clean up that does
something similar and deletes all the deprecated sample code.

Fixes #259, #138, #99, #204, #314, #589
rjrjr added a commit that referenced this issue Dec 3, 2021
@rjrjr
Introduces ScreenOverlay and ModalScreenOverlayDialogFactory
c7d84cf 
`ScreenOverlay` marks an `Overlay` with a `Screen` defining its content.

`ModalScreenOverlayDialogFactory` can show a `ScreenOverlay` as an
`android.app.Dialog`, taking care of updating the content view and managing
the Back button. It's the much simpler replacement for `ModalViewContainer`.

Also introduces two new `ViewEnvironment` values:

 - `ModalArea`, which allows dialogs to restrict themselves to a subset
   of the screen. `ModalScreenOverlayDialogFactory` applies this automatically
 - `CoveredByModal`, used by `BodyAndModalsContainer` and `LayeredDialogs` to
   disable touch and keyboard events reliably

In sample code, `PanelOverlay` replaces `PanelContainerScreen`, and the Tic
Tac Toe sample is updated to use the new hotness. I think the diff of the
sample code really highlights how much the new marker interfaces improve our
composition story.

That said, the `ScrimScreen` bit in the sample is a little rough. In the old
code we magically swizzled the scrim into place automatically. This PR
seems big enough already, so I'll follow up with a clean up that does
something similar and deletes all the deprecated sample code.

Fixes #259, #138, #99, #204, #314, #589
rjrjr added a commit that referenced this issue Dec 6, 2021
@rjrjr
Introduces ScreenOverlay and ModalScreenOverlayDialogFactory
727928c 
`ScreenOverlay` marks an `Overlay` with a `Screen` defining its content.

`ModalScreenOverlayDialogFactory` can show a `ScreenOverlay` as an
`android.app.Dialog`, taking care of updating the content view and managing
the Back button. It's the much simpler replacement for `ModalViewContainer`.

`ModalScreenOverlayDialogFactory` works with `BodyAndModalsContainer`
and `LayeredDialogs` to perform two important tricks:

 - `updateBounds(Dialog, Rect)`, which allows dialogs to be restrictred to a subset
   of the screen. Implemented via the private `ModalArea` value in `ViewEnvironment`

 - Touch and keyboard events are blocked by views that are covered by
   dialogs managed by a `ModalScreenOverlayDialogFactory`. Same for
   dialogs with a lower z order. We use another private `ViewEnvironment`
   value for that, `CoveredByModal`.

In sample code, `PanelOverlay` replaces `PanelContainerScreen`, and the Tic
Tac Toe sample is updated to use the new hotness. I think the diff of the
sample code really highlights how much the new marker interfaces improve our
composition story.

That said, the `ScrimScreen` bit in the sample is a little rough. In the old
code we magically swizzled the scrim into place automatically. This PR
seems big enough already, so I'll follow up with a clean up that does
something similar and deletes all the deprecated sample code.

Fixes #259, #138, #99, #204, #314, #589
rjrjr added a commit that referenced this issue Dec 6, 2021
@rjrjr
Introduces ScreenOverlay and ModalScreenOverlayDialogFactory
f1fa90d 
`ScreenOverlay` marks an `Overlay` with a `Screen` defining its content.

`ModalScreenOverlayDialogFactory` can show a `ScreenOverlay` as an
`android.app.Dialog`, taking care of updating the content view and managing
the Back button. It's the much simpler replacement for `ModalViewContainer`.

`ModalScreenOverlayDialogFactory` works with `BodyAndModalsContainer`
and `LayeredDialogs` to perform two important tricks:

 - `updateBounds(Dialog, Rect)`, which allows dialogs to be restrictred to a subset
   of the screen. Implemented via the private `ModalArea` value in `ViewEnvironment`

 - Touch and keyboard events are blocked by views that are covered by
   dialogs managed by a `ModalScreenOverlayDialogFactory`. Same for
   dialogs with a lower z order. We use another private `ViewEnvironment`
   value for that, `CoveredByModal`.

In sample code, `PanelOverlay` replaces `PanelContainerScreen`, and the Tic
Tac Toe sample is updated to use the new hotness. I think the diff of the
sample code really highlights how much the new marker interfaces improve our
composition story.

That said, the `ScrimScreen` bit in the sample is a little rough. In the old
code we magically swizzled the scrim into place automatically. This PR
seems big enough already, so I'll follow up with a clean up that does
something similar and deletes all the deprecated sample code.

Fixes #259, #138, #99, #204, #314, #589
rjrjr added a commit that referenced this issue Dec 6, 2021
@rjrjr
Introduces ScreenOverlay and ModalScreenOverlayDialogFactory
1092624 
`ScreenOverlay` marks an `Overlay` with a `Screen` defining its content.

`ModalScreenOverlayDialogFactory` can show a `ScreenOverlay` as an
`android.app.Dialog`, taking care of updating the content view and managing
the Back button. It's the much simpler replacement for `ModalViewContainer`.

`ModalScreenOverlayDialogFactory` works with `BodyAndModalsContainer`
and `LayeredDialogs` to perform two important tricks:

 - `updateBounds(Dialog, Rect)`, which allows dialogs to be restrictred to a subset
   of the screen. Implemented via the private `ModalArea` value in `ViewEnvironment`

 - Touch and keyboard events are blocked by views that are covered by
   dialogs managed by a `ModalScreenOverlayDialogFactory`. Same for
   dialogs with a lower z order. We use another private `ViewEnvironment`
   value for that, `CoveredByModal`.

In sample code, `PanelOverlay` replaces `PanelContainerScreen`, and the Tic
Tac Toe sample is updated to use the new hotness. I think the diff of the
sample code really highlights how much the new marker interfaces improve our
composition story.

That said, the `ScrimScreen` bit in the sample is a little rough. In the old
code we magically swizzled the scrim into place automatically. This PR
seems big enough already, so I'll follow up with a clean up that does
something similar and deletes all the deprecated sample code.

Fixes #259, #138, #99, #204, #314, #589
rjrjr added a commit that referenced this issue Dec 6, 2021
@rjrjr
Introduces ScreenOverlay and ModalScreenOverlayDialogFactory
b455dde 
`ScreenOverlay` marks an `Overlay` with a `Screen` defining its content.

`ModalScreenOverlayDialogFactory` can show a `ScreenOverlay` as an
`android.app.Dialog`, taking care of updating the content view and managing
the Back button. It's the much simpler replacement for `ModalViewContainer`.

`ModalScreenOverlayDialogFactory` works with `BodyAndModalsContainer`
and `LayeredDialogs` to perform two important tricks:

 - `updateBounds(Dialog, Rect)`, which allows dialogs to be restrictred to a subset
   of the screen. Implemented via the private `ModalArea` value in `ViewEnvironment`

 - Touch and keyboard events are blocked by views that are covered by
   dialogs managed by a `ModalScreenOverlayDialogFactory`. Same for
   dialogs with a lower z order. We use another private `ViewEnvironment`
   value for that, `CoveredByModal`.

In sample code, `PanelOverlay` replaces `PanelContainerScreen`, and the Tic
Tac Toe sample is updated to use the new hotness. I think the diff of the
sample code really highlights how much the new marker interfaces improve our
composition story.

That said, the `ScrimScreen` bit in the sample is a little rough. In the old
code we magically swizzled the scrim into place automatically. This PR
seems big enough already, so I'll follow up with a clean up that does
something similar and deletes all the deprecated sample code.

Fixes #259, #138, #99, #204, #314, #589
@rjrjr
Copy link
Contributor

rjrjr commented Dec 7, 2021

Fixed by #595

@rjrjr rjrjr closed this as completed Dec 7, 2021
Workflow Kotlin automation moved this from In progress to Done Dec 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rjrjr rjrjr

Labels
good first issue Good for newcomers help wanted Extra attention is needed modals ui Related to UI integration
Projects
Workflow Kotlin
  
Done
Milestone
ui-1.0
Development

No branches or pull requests
2 participants
@rjrjr @christiandeange