Status Update
Comments
of...@sebastianmarschall.com <of...@sebastianmarschall.com> #2
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
il...@google.com <il...@google.com> #3
ma...@gmail.com <ma...@gmail.com> #4
Not sure how this would be exposed, but driving Activity.getLifecycle events from the ReportFragment which is actually a different lifecycle to that Activity is very odd.
Not sure on the API, but a getActivityLifecycle and getFragmentLifecycle would be nice in this situation, as I actually want my lifecycle events to fire IN onCreate not in onStart.
il...@google.com <il...@google.com> #5
of...@sebastianmarschall.com <of...@sebastianmarschall.com> #6
Hello Ian,
any chance to fix this by just returning the already existing mFragmentLifecycleRegistry
in getLifecycle()
overload?
This really caused us back-press handling issues as mentioned in my
Currently I'm workarounding this with a reflection to register the callback with mFragmentLifecycleRegistry
lifecycle.
Thank you.
il...@google.com <il...@google.com> #7
Is this ever going to be implemented? My team is facing issues related to this as well... Be it with registering OnBackPressed on orientation changes or driving the ViewLifecycle in some cases...
of...@sebastianmarschall.com <of...@sebastianmarschall.com> #8
I think you'd still run into the same issue when navigating from C back to a previous set of destinations.
You are right, thats not a generic solution. It is just for me at the moment because I am only navigating from the subgraph start destination to another subgraph. So I will never have the case where I am navigating back from a subgraph to a screen that uses getBackStackEntry<C>().
I like the idea of the getParentBackStackEntry(NavBackStackEntry)
API. It would definitley help me in my scenario and I also think it's clear.
Description
Component used: Navigation Version used: Navigation Compose 2.8.2
Devices/Android versions reproduced on: Pixel 9 Pro, Simulator
Imagine this Navigation structure:
In composable C I am loading a viewModel() with the backstackEntry of B as viewModelStoreOwner. Now I am navigation from A to B, and from B again to B. When navigation back using popBackStack() everything works as expected. When navigation back using the Back Gesture with Predictive Back enabled in the Manifest the app crashes when going from A-B-B to A-B.
Try it with this sample project:https://github.com/sebastianmarschall/predictive-back-crash