-
Notifications
You must be signed in to change notification settings - Fork 101
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.
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
Long lived branch with Overlay
refinements
#839
Conversation
OverlayDialogHolder.onUpdateBounds
replaces `ScreenOverlayDialogFac…OverlayDialogHolder.onUpdateBounds
09fee95
to
f6204fe
Compare
@steve-the-edwards Uh oh:
I'm surprised by this, and I don't see what I've done to cause it. Can I just bump the expected range, or do we need to dig in? |
Re-running that shard to see if this is flaky. |
Sure enough, it was a flake. :( |
This is ready for review, although I might not merge it until I get to exercise it a bit harder as a snapshot ( |
If that was just a flake/within reasonable bounds I am fine with bumping up the expected range. |
...core-android/src/main/java/com/squareup/workflow1/ui/container/ScreenOverlayDialogFactory.kt
Outdated
Show resolved
Hide resolved
...core-android/src/main/java/com/squareup/workflow1/ui/container/ScreenOverlayDialogFactory.kt
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:stamp:
I'm going to merge #840 into this branch, and hold off on merging into main until I have a bit more confidence in this series of changes. I'm already working on a refinement of our back button handling in |
OverlayDialogHolder.onUpdateBounds
Overlay
refinements
`OverlayDialogHolder.onUpdateBounds` replaces `ScreenOverlayDialogFactory.updateBounds`. I finally tried to use `ScreenOverlayDialogFactory.updateBounds` and was reminded once again why it's bad to create interfaces that build something and then take it back later to be updated. If you want the renderings to be involved in setting the bounds policy, there was no way to smuggle that information along with the Dialog returned from `buildDialogWithContent`, so that `updateBounds` could honor it. Also, it was always pretty ugly that the bounds hook was special to the `ScreenOverlay` world. The fix is make bounds maintenance part of the job of the `OverlayDialogHolder` interface. Square reviewers will notice that we're now an even more faithful rip off of Mosaic's DialogRunner -- hi @helios175.
WorkflowLayout was wrapping things in EnvironmentScreen for no real reason. No longer.
#840 is being weird in CI, though everything passes locally and all our internal tests like it. I'm going to go ahead and merge this branch and target #840 at |
Holding off on merging into
main
until I have more confidence in the changes, which I'm getting by applying them across Square's flagship Android apps; and until I'm ready to deal with the recent coroutines version update (#817).Introduces
OverlayDialogHolder.onUpdateBounds
OverlayDialogHolder.onUpdateBounds
replacesScreenOverlayDialogFactory.updateBounds
.I finally tried to use
ScreenOverlayDialogFactory.updateBounds
and was reminded once again why it's bad to create interfaces that build something and then take it back later to be updated. If you want the renderings to be involved in setting the bounds policy, there was no way to smuggle that information along with the Dialog returned frombuildDialogWithContent
, so thatupdateBounds
could honor it. Also, it was always pretty ugly that the bounds hook was special to theScreenOverlay
world.The fix is make bounds maintenance part of the job of the
OverlayDialogHolder
interface. Square reviewers will notice that we're now an even more faithful rip off of Mosaic's DialogRunner -- hi @helios175.No more hard coded EnvironmentScreen in WorkflowLayout.
WorkflowLayout was wrapping things in EnvironmentScreen for no real reason. No longer.