Bug P3
Status Update
Comments
jb...@google.com <jb...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 85c1de7395f07e3256a50706d4f619e654624250
Author: Ian Lake <ilake@google.com>
Date: Fri Apr 19 13:54:21 2019
Ensure Fragment OnBackPressedCallbacks take priority
As FragmentController is not yet driven by a
LifecycleObserver ( b/127528777 ), LifecycleObservers on
Fragments are not necessarily nested within
LifecycleObservers registered at the Activity level.
This can lead to cases where a Fragment is started
before the Activity's Lifecycle is started.
In the case of FragmentManager's usage of Lifecycle to
add OnBackPressedCallbacks, that nesting is critical
to ensure the ordering of callbacks. By creating a
host level Lifecycle that is exactly nested outside
the callbacks to FragmentController, we can ensure
the proper nesting in callbacks.
Test: added test passes
Change-Id: I958d2389c90dcd9d157c6c3d30dffb689ed40c62
M fragment/src/androidTest/AndroidManifest.xml
M fragment/src/androidTest/java/androidx/fragment/app/OnBackPressedCallbackTest.kt
M fragment/src/main/java/androidx/fragment/app/FragmentActivity.java
https://android-review.googlesource.com/948209
https://goto.google.com/android-sha1/85c1de7395f07e3256a50706d4f619e654624250
Branch: androidx-master-dev
commit 85c1de7395f07e3256a50706d4f619e654624250
Author: Ian Lake <ilake@google.com>
Date: Fri Apr 19 13:54:21 2019
Ensure Fragment OnBackPressedCallbacks take priority
As FragmentController is not yet driven by a
LifecycleObserver (
Fragments are not necessarily nested within
LifecycleObservers registered at the Activity level.
This can lead to cases where a Fragment is started
before the Activity's Lifecycle is started.
In the case of FragmentManager's usage of Lifecycle to
add OnBackPressedCallbacks, that nesting is critical
to ensure the ordering of callbacks. By creating a
host level Lifecycle that is exactly nested outside
the callbacks to FragmentController, we can ensure
the proper nesting in callbacks.
Test: added test passes
Change-Id: I958d2389c90dcd9d157c6c3d30dffb689ed40c62
M fragment/src/androidTest/AndroidManifest.xml
M fragment/src/androidTest/java/androidx/fragment/app/OnBackPressedCallbackTest.kt
M fragment/src/main/java/androidx/fragment/app/FragmentActivity.java
wi...@gmail.com <wi...@gmail.com> #3
FWIW, I think this is a fantastic idea and would go a long way in bringing sanity to the world of lifecycle. As it would change the ordering between Activity lifecycle methods and Fragment lifecycle methods, this will almost certainly be an opt-in flag set at the FragmentActivity level.
Description
Component used: Navigation
Version used: 2.7.7 until 2.8.4
Devices/Android versions reproduced on: Galaxy Z Fold5 API 34, Pixel 6 Pro API 34, Pixel 8 Pro API 34, Pixel 9 Pro API 35, more in prod.
According to the documentation on Deep Links in Compose, when matching a URI deep link, placeholder values should be placed in back stack entry's arguments Bundle with the same name as the placeholder. For example, consider the following link is deep-linked:
Previously, you could match this URI with something like the following:
This is no longer the case as the documentation suggests. In order to obtain the URI from the deep link, you now have to use:
The entire deep link Intent is getting put into the arguments Bundle, where it should only be a string of the placeholder value from the URI. Second, no matter what I attempted to name my placeholder value in the URI, the name in the Bundle stayed a constant "android-support-nav:controller:deepLinkIntent" as well as staying in the Bundle as an Intent rather than just the string.