Status Update
Comments
il...@google.com <il...@google.com>
wa...@reaktor.fi <wa...@reaktor.fi> #2
I don't think this is enough cause we don't know how it is being produced. If you could create a project that recreates this that would be great, if not please provide us with the steps and we can see if that helps.
th...@gmail.com <th...@gmail.com> #3
It looks like we were using a CopyOnWriteArrayList
in the Java version of NavController, which was resilient to removing an OnDestinationChangedListener
as part of the dispatch i.e.,
addOnDestinationChangedListener(object : OnDestinationChangedListener {
override fun onDestinationChanged(
controller: NavController,
destination: NavDestination,
arguments: Bundle?
) {
removeOnDestinationChangedListener(this)
}
})
// Note, you need to have at least one other OnDestinationChangedListener
// that is added after the one that is removed to duplicate this error
We lost that resiliency when we converted over to Kotlin, hence this error. We need to switch back.
ap...@google.com <ap...@google.com> #4
We get this crash as well. I have a simple sample project where it can't be reproduced so it could be due to our nested graphs.
Kinda tl;dr scenario where it happens Graph 1 > Graph 2 (Graph 2 has bottom hav) - Navigate to dynamic feature module and click back - Navigate with BottomNavigationView.
I've spent some time trying to get a sample project which recreates the crash without success as the request in #2. Is that still needed after
jb...@google.com <jb...@google.com> #5
Branch: androidx-main
commit cb7bd694963278c03e987603f51953f0b89d3f1c
Author: Jeremy Woods <jbwoods@google.com>
Date: Fri May 21 14:03:22 2021
Fix ConcurrentModificationException on the OnDestinationChangedListener
Go back to using the CopyOnWriteArrayList to ensure that
modifying the list of OnDestinationChangedListeners is safe.
RelNote: "You will no longer get a ConcurrentModificationException when
using OnDestinationChangedListeners."
Test: NavControllerTest
Bug: 188860458
Change-Id: Ib17074c773ed9462c6a69ad384c23e28fa8abaf6
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
ro...@gmail.com <ro...@gmail.com> #6
This has been fixed internally and will be available in the Navigation 2.4.0-alpha02
release.
jb...@google.com <jb...@google.com> #7
Please file a new bug with a minimal sample project that reproduces your issue.
ro...@gmail.com <ro...@gmail.com> #9
The issue in Empty
. But if you leave the app open and toggle the system dark mode, now the app will get recomposed with the new value2
.
If it helps, I can share the project, but it's really just the code from
th...@gmail.com <th...@gmail.com> #10
th...@gmail.com <th...@gmail.com> #11
Also, IMO, this is a core issue and should be marked as a high priority.
ap...@google.com <ap...@google.com> #13
Branch: androidx-main
commit 5f1bdbbffc8c06355b22fdfe72ef1cf666b0d904
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Aug 18 03:45:03 2021
Ensure changing arguments causes recompose
Now that NavBackStackEntries are immutable and we don't just change
arguements, we change entire entries, we should make sure NavigatorState
properly handles launchSingleTop.
The only thing we need to do is to update both the navController and
navigator state back stacks with the proper entry.
RelNote: "Navigation Compose now properly recomposes when changing back
stack arguments and using launchSingleTop=true."
Test: all tests pass, and tested in samples from bug
Bug: 186392337
Fixes: 196390311
Change-Id: Iebd698c9e310ad84ce65238c8a5a33db86a9f1f7
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/Navigator.kt
M navigation/navigation-common/src/main/java/androidx/navigation/NavigatorState.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
jb...@google.com <jb...@google.com> #14
We were able to get a fix for this in Navigation 2.4.0-alpha08
.
You can try this out by following the #7677699
.
ma...@gmail.com <ma...@gmail.com> #15
jb...@google.com <jb...@google.com> #16
Please file a new bug with a minimal sample project that reproduces the issue.
so...@gmail.com <so...@gmail.com> #17
The same issue still exists.
il...@google.com <il...@google.com> #18
Re
Description
Component used: Navigation-Compose Version used: 1.0.0-alpha10, Compose 1.0.0-beta05
A bit short on time, so just posting a simple repro here. When trying to navigate to a destination that is the current destination but with different arguments using
NavOptions.launchSingleTop
, the NavController will replace the current NavBackStackEntry's arguments. Consider the following example:In
NavController#currentBackStackEntryAsState
, theState
's value won't be changed because the reference stays the same and the NavBackStackEntry held by the state has already been mutated, so theNavHost
won't recompose after that change. Maybe theNeverEqualPolicy
could be used as a quick fix.Let me know if you need more info, cheers!