Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
Is this specific to navigation? Or can this be reproduced with another other Composable component?
il...@google.com
[Deleted User] <[Deleted User]>
It only happens inside of a NavHost. So, yes, it seems to be specific to navigation.
il...@google.com
This was caused by the fix to BackHandler lifecycle aware. The problem here is that the NavController registers its lifecycle and added an observer to the Activity Lifecycle in composition while the BackHandler registers its observer on the Activity Lifecycle in a DisposbleEffect. This means that the NavController will always get Lifecycle callbacks before the BackHandler, so the components listening the the NavController's lifecycle (like the NavBackStackEntry) will always get their Lifecycle callbacks before the BackHandler as well.
This should be addressed by work coming in 2.7 to integrate the BackHandler into the NavHost.
[Deleted User] <[Deleted User]>
Branch: androidx-main
commit d2c5efe67531a30fb9f1a129d52beb1e9ece0b29
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed May 31 23:09:54 2023
Integrate BackHandler into NavHost
Instead of NavHost taking over the onBackPressedDispatcher from the
Activity, we should just make it use a BackHandler. This will ensure
that it interacters with the other BackHandlers in Compose correctly.
RelNote: "`NavHost` now correctly intercepts system back calls even
after the Activity has been `STOPPED` and `RESUMED`."
Test: modified tests
Bug: 279118447
Change-Id: Icb6deab996d122487243f0d3d775af8c15fc7c25
M navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavHostTest.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
mi...@gmail.com
This has been fixed internally and will be available in Navigation 2.7.0-beta01.
[Deleted User] <[Deleted User]>
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-compose:2.7.0-beta01
il...@google.com
mi...@gmail.com
I wouldn't say this is fixed. If you add a back-callback in the activity which is lifecycle aware, and then background->foreground the app, the activity back-callback will be put on top of the callback pile. This leads to that any BackHandler in your composable will NOT be triggered.
The best workaround I have for now is to use the non-lifecycle aware function in the activity.
class MainActivity : FragmentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// open fragment which hoists the composables
...
if (savedInstanceState == null) {
onBackPressedDispatcher.addCallback(onBackPressedCallback = someBackHandling())
// onBackPressedDispatcher.addCallback(owner = this, onBackPressedCallback = someBackHandling) // not this one
}
}
il...@google.com
mi...@gmail.com
dc...@gmail.com
Bug Fixes : NavHost in Navigation Compose now correctly intercepts system back calls even after the Activity has been STOPPED and RESUMED.
It works fine for me.
da...@gmail.com
il...@google.com
In my case it works fine when the app is first ran, but my custom callback calls navController.popBackStack internally if it can't handle back press on its own. So, when I run the app and click back, everything works, but after I pop up all the Composables from the stack and return to the app, the custom callback is not called anymore.
Description
This approach only seem to work on actions originating from the graph's start destination, and fails on actions between any other destinations. I created a sample project which reproduces the issue:
Here is the project's README detailing the issue:
# Bug in Android Navigation Component (alpha06)
(Note: I have only verified this in alpha06, I don't know if it exists in
previous versions)
## The problem
Basically the problem is that the NavOption "clearTask" was removed in
alpha02, and the recommended substitute was to use app:popUpTo pointing to
the root of the graph/the graph ID, together with app:popUpToInclusive="true".
However, this method does not work. It only seems to work for actions
going from the graph's start destination. If we have the following graph:
x y
A ---> B ---> C
Where A, B, and C are fragments, A is the start destination of the grapg,
and x, y are actions going from A to B and B to C respectively. Let's say
the graph's ID is "@+id/graph"
Then, if both actions x and y have
app:popUpTo="@+id/graph"
app:popUpToInclusive="true"
Then when navigating from A to B through x, and then hitting the back button
will exit the app (as expected). But if navigating from A to B to C through
x and y, and then hitting the back button we will navigate back to B — this
is not what was expected. The expected behavior with this graph is to always
exit the app when clicking the back button
## Environment
This was verified using:
Android Studio 3.2 RC 3
Build #AI-181.5540.7.32.4987877, built on August 31, 2018
JRE: 1.8.0_152-release-1136-b06 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.13.6