-
Notifications
You must be signed in to change notification settings - Fork 99
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
WorkflowLayout.start needs a Lifecycle, BackStackScreen is supported. #632
Conversation
7bf2fd6
to
2d789d1
Compare
2d789d1
to
bedf43a
Compare
1c65e56
to
1a9569b
Compare
bedf43a
to
3c12d95
Compare
3c12d95
to
579230a
Compare
579230a
to
417bd53
Compare
We make the cored update method for `WorkflowLayout` public to give apps complete control over how exactly they collect renderings. Doing this because the `takeWhileAttached` method used by `start` is causing problems. Opening this up lets those impacted by these problems avoid them. In a downstream release, we will upgrade `androidx.lifecycle:lifecycle-viewmodel` and update the convenient `start` to use its improved API. Details in #632.
We make the cored update method for `WorkflowLayout` public to give apps complete control over how exactly they collect renderings. Doing this because the `takeWhileAttached` method used by `start` is causing problems. Opening this up lets those impacted by these problems avoid them. In a downstream release, we will upgrade `androidx.lifecycle:lifecycle-viewmodel` and update the convenient `start` to use its improved API. Details in #632.
We make the core update method for `WorkflowLayout` public to give apps complete control over how exactly they collect renderings. Doing this because the `takeWhileAttached` method used by `start` is causing problems. Opening this up lets those impacted by these problems avoid them. In a downstream release, we will upgrade `androidx.lifecycle:lifecycle-viewmodel` and update the convenient `start` to use its improved API. Details in #632.
We make the core `update` method for `WorkflowLayout` public to give apps complete control over how exactly they collect renderings. Doing this because the `takeWhileAttached` method used by `start` is causing problems. Opening this up lets those impacted by these problems avoid them. In a downstream release, we will upgrade `androidx.lifecycle:lifecycle-viewmodel` and update the convenient `start` to use its improved API. Details in #632.
aec5713
to
03ab545
Compare
417bd53
to
1ffc126
Compare
1ffc126
to
4eb2c07
Compare
4eb2c07
to
0785914
Compare
0785914
to
705d753
Compare
Cool, should have left this as a draft:
Thanks @pyricau! |
Meh, I think the LeakCanary bit is noise: seems like the
|
The real broken test is because the change somehow breaks the device back button after config changes in (at least) the Tic Tac Toe sample. |
Maybe it's about breaking the back button on modals after config change. Good times. |
3e83946
to
c2434a4
Compare
8b51bba
to
0176bb4
Compare
...amples/src/main/java/com/squareup/sample/compose/hellocomposebinding/HelloBindingActivity.kt
Show resolved
Hide resolved
...c/main/java/com/squareup/sample/compose/hellocomposeworkflow/HelloComposeWorkflowActivity.kt
Show resolved
Hide resolved
...low-ui/container-android/src/main/java/com/squareup/workflow1/ui/modal/ModalViewContainer.kt
Show resolved
Hide resolved
@WorkflowUiExperimentalApi | ||
public class BackButtonScreen<W : Any>( | ||
public val wrapped: W, | ||
public val override: Boolean = false, |
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.
nit: now that this is promoted can we not use a reserved keyword? Maybe overrideWrappedBackHandling
? Too verbose?
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.
How about shadow
?
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.
Hmm shadow
seems vague. Maybe with good kdoc we'd be fine :)
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.
* @param shadow If `true`, [onBackPressed] is set as the
* [backPressedHandler][android.view.View.backPressedHandler] after
* the [wrapped] rendering's view is built / updated, effectively overriding it.
* If false (the default), [onBackPressed] is set afterward, to allow the wrapped rendering to
* take precedence if it sets a `backPressedHandler` of its own -- the handler provided
* here serves as a default.
workflow-ui/core-android/src/main/java/com/squareup/workflow1/ui/BackPressHandler.kt
Show resolved
Hide resolved
workflow-ui/core-android/src/main/java/com/squareup/workflow1/ui/WorkflowLayout.kt
Outdated
Show resolved
Hide resolved
lifecycle.coroutineScope.launch { | ||
lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) { | ||
renderings.collect { update(it, environment) } | ||
} | ||
} |
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.
This is quite tidy and makes very clear sense!
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.
I'm really grateful they cleaned this up. The androidx Lifecycle
stuff is flawed, but its sooo much better than everything that came before it.
workflow-ui/core-android/src/main/java/com/squareup/workflow1/ui/WorkflowLayout.kt
Outdated
Show resolved
Hide resolved
On a lot of Samsung devices running Anroid 12 / API 30, the sketchy `WorkflowLayout.takeWhileAttached` method at the heart of `WorkflowLayout.start` was having surprising effects -- we'd see redundant calls to `OnAttachStateChangeListener.onViewAttachedToWindow`. The problem goes away if we get more conventional and use the new `repeatOnLifecycle` function as described in [this blog post](https://medium.com/androiddevelopers/a-safer-way-to-collect-flows-from-android-uis-23080b1f8bda). The old methods are deprecated and will be deleted soon. Making this change required making our `BackPressHandler` mechanism more robust, as it too was pretending that `OnAttachStateChangeListener` was an adequate lifecycle. Specifically, we were relying on `onViewAttachedToWindow` to be called in a predicable order, which stopped being the case with the move away from `WorkflowLayout.takeWhileAttached`. This PR changes things so that… - We register handlers immediately, so that we can count on them being stacked in the expected order - We lean on `OnAttachStateChangeListener` solely to enable and disable the `BackPressHandler` associated with a view - And take advantage of our recently added support for `ViewTreeLifecycleOwner` for clean up `ModalContainer`'s contribution to coping with the back button also had to be beefed up, for similar reasons. It needs to ensure that back button events are blocked by modal windows, just like any other event, which is tricky with the singleton `OnBackPressedDispatcher` that androidx provides. It does this by putting a no-op handler in place as a backstop for any set by modal renderings. Its bespoke code for doing this was also inadvertently relying on the order of `onViewAttachedToWindow` calls. We now achieve this by wrapping modal renderings with a reliable `BackStackScreen`, which is promoted from the sample container set.
0176bb4
to
01eb576
Compare
Update addresses all of @steve-the-edwards nits but one -- named params on the various |
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.
Thanks! LGTM
On a lot of Samsung devices running Anroid 12 / API 30, the sketchy
WorkflowLayout.takeWhileAttached
method at the heart ofWorkflowLayout.start
was having surprising effects -- we'd see redundant calls toOnAttachStateChangeListener.onViewAttachedToWindow
. The problem goes away if we get more conventional and use the newrepeatOnLifecycle
function as described in this blog post.The old methods are deprecated and will be deleted soon.
Making this change required making our
BackPressHandler
mechanism more robust, as it too was pretending thatOnAttachStateChangeListener
was an adequate lifecycle. Specifically, we were relying ononViewAttachedToWindow
to be called in a predicable order, which stopped being the case with the move away fromWorkflowLayout.takeWhileAttached
. This PR changes things so that…OnAttachStateChangeListener
solely to enable and disable theBackPressHandler
associated with a viewViewTreeLifecycleOwner
for clean upModalContainer
's contribution to coping with the back button also had to be beefed up, for similar reasons. It needs to ensure that back button events are blocked by modal windows, just like any other event, which is tricky with the singletonOnBackPressedDispatcher
that androidx provides. It does this by putting a no-op handler in place as a backstop for any set by modal renderings. Its bespoke code for doing this was also inadvertently relying on the order ofonViewAttachedToWindow
calls. We now achieve this by wrapping modal renderings with a reliableBackStackScreen
, which is promoted from the sample container set.