Simpler, better back button handling. #843
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rjrjr
force-pushed
the
ray/back-button-always-the-back-button-what-a-terrible-idea-the-back-button-was
branch
2 times, most recently
from
9b676fb to
7ad3116
Compare
rjrjr
changed the title
rjrjr
force-pushed
the
ray/back-button-always-the-back-button-what-a-terrible-idea-the-back-button-was
branch
from
7ad3116 to
b5b1f00
Compare
rjrjr
force-pushed
the
ray/back-button-always-the-back-button-what-a-terrible-idea-the-back-button-was
branch
from
b5b1f00 to
76422f5
Compare
rjrjr
force-pushed
the
ray/back-button-always-the-back-button-what-a-terrible-idea-the-back-button-was
branch
from
76422f5 to
3c394cf
Compare
workflow-ui/core-android/src/main/java/com/squareup/workflow1/ui/container/DialogSession.kt
Show resolved
Hide resolved
workflow-ui/core-android/src/main/java/com/squareup/workflow1/ui/container/DialogSession.kt
Outdated
Show resolved
Hide resolved
...w-ui/core-android/src/main/java/com/squareup/workflow1/ui/container/LayeredDialogSessions.kt
Show resolved
Hide resolved
| * work, and provides default bindings for [AlertOverlay] and [FullScreenOverlay]. | ||
| * | ||
| * Here is how this hook could be used to provide a custom dialog to handle [FullScreenOverlay]: |
There was a problem hiding this comment.
This example is no longer applicable because of back press handling?
There was a problem hiding this comment.
It was already inaccurate, and I'm kind of exhausted, TBH.
workflow-ui/core-android/src/main/java/com/squareup/workflow1/ui/container/DialogSession.kt
Outdated
Show resolved
Hide resolved
workflow-ui/core-android/src/main/java/com/squareup/workflow1/ui/container/DialogSession.kt
Show resolved
Hide resolved
Less complex, anyway. The old scheme had a strategy object in the ViewEnvironment that was providing a one-size-fits-all-dialogs scheme for back button handling, and that scheme was only used by the ScreenViewOverlay subtype, not for Overlay in general. It also was applied only for modals, which was just wrong. With this change, the OverlayDialogHolder that wraps the Dialog is directly responsible for defining its back button behavior; the bizarre subtle I'll add this to the commit message. |
rjrjr
force-pushed
the
ray/back-button-always-the-back-button-what-a-terrible-idea-the-back-button-was
branch
from
3c394cf to
2120968
Compare
`OverlayDialogHolder` now can provide an `onBackPressed: () -> Unit` function to be called in place of `Dialog.onBackPressed`, and we provide a default implementation that hooks in `OnBackPressedDispatcher`. This works for all kinds of dialogs, not just modal ones, and replaces `ModalScreenOverlayBackButtonHelper`. The other method that was on `ModalScreenOverlayBackButtonHelper`, which put the no-op `backPressedHandler` on the content view to ensure those on layer layers would not fire, is now built into the default implementation of `ScreenOverlayDialogFactory.buildDialogWithContent`, which is designed to be customized anyway.
Also locks down `AlertOverlayDialogFactory`, but moves all the interesting parts into a public function. Should be easier and safer for re-use.
So how is this simpler? Or at least less complex?
The old scheme had:
- a strategy object in the `ViewEnvironment`, `ModalScreenOverlayBackButtonHelper`, that was providing a one-size-fits-all-dialogs scheme for back button handling
- that scheme was only used by the `ScreenViewOverlay` subtype, not for `Overlay` in general
- and it was applied only for modals, which was very wrong
With this change:
- The individual `OverlayDialogHolder` that wraps a `Dialog` is directly responsible for defining its back button behavior, and can be changed from the default behavior directly by the feature developer
- The bizarre subtle `onBackPressed = {}` hack is moved to the factory class responsible for building the dialog, again in a spot that is naturally open for customization
- and we eliminate the boolean return value, meaning one less decision point for developers
rjrjr
force-pushed
the
ray/back-button-always-the-back-button-what-a-terrible-idea-the-back-button-was
branch
from
2120968 to
ba43dab
Compare
steve-the-edwards
approved these changes
Jul 28, 2022
rjrjr
deleted the
ray/back-button-always-the-back-button-what-a-terrible-idea-the-back-button-was
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
OverlayDialogHoldernow can provide anonBackPressed: () -> Unitfunction to be called in place ofDialog.onBackPressed, and we provide a default implementation that hooks inOnBackPressedDispatcher. This works for all kinds of dialogs, not just modal ones, and replacesModalScreenOverlayBackButtonHelper. The other method that was onModalScreenOverlayBackButtonHelper, which put the no-opbackPressedHandleron the content view to ensure those on layer layers would not fire, is now built into the default implementation ofScreenOverlayDialogFactory.buildDialogWithContent, which is designed to be customized anyway.Also locks down
AlertOverlayDialogFactory, but moves all the interesting parts into a public function. Should be easier and safer for re-use.So how is this simpler? Or at least less complex?
The old scheme had:
ViewEnvironment,ModalScreenOverlayBackButtonHelper, that was providing a one-size-fits-all-dialogs scheme for back button handlingScreenViewOverlaysubtype, not forOverlayin generalWith this change:
OverlayDialogHolderthat wraps aDialogis directly responsible for defining its back button behavior, and can be changed from the default behavior directly by the feature developeronBackPressed = {}hack is moved to the factory class responsible for building the dialog, again in a spot that is naturally open for customization