Status Update
No update yet.
Comments
lp...@google.com
I suspect this change is the culprit.
lp...@google.com
Bug reproducible in compose NavHost when compose sets same graph consecutively.
Upon setting same graph the second time, the original _graph nodes were not properly replaced by the new graph node instances. When navigating to new destination in addEntryToBackstack:
findDestination(destination.id) was not able to find destination node (a new instance) amongst the old nodes (old instances). Therefore it proceeds to re-add new node's hierarchy resulting in duplicated root node.
The fix to
ma...@gmail.com
Branch: androidx-main
commit 5499d88b63726e63900b89d3100be1b3a17b84ce
Author: Clara Fok <clarafok@google.com>
Date: Tue Mar 28 17:00:19 2023
Fix set same graph to replace old destinations
When setting the same graph (exact same routes and destinations but different instances), NavController would keep the original graph but replace the existing graph's nodes with the new graph's nodes. Fix the replace logic to ensure this replacement happens. Also replace backqueue's entry destinations with new instances to ensure the graph and backstack is in sync.
Test: ./gradlew navigation:navigation-compose:cC
Bug: 275258161
Bug: 275407804
Relnote: "When NavController sets the same graph with same route and destinations, it now properly replaces its current graph nodes and its bacstack destinations with new instances."
Change-Id: I5bc582e315578ee53383596070ee3ea4a23aed69
M navigation/navigation-compose/build.gradle
M navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavHostTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
jb...@google.com
Fixed internally and will be available navigation 2.6.0-alpha09
ma...@gmail.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-compose:2.6.0-alpha09androidx.navigation:navigation-runtime:2.6.0-alpha09
Description
PreferenceFragmentCompat sets this adapter (PreferenceGroupAdapter), which implicitly registers an observer. PreferenceFragmentCompat never sets the adapter to null when the view is destroyed, so the observer keeps references to the RecyclerView and doesn't get gc'ed.
I've worked around this by explicitly setting the adapter to null in an override of onDestroyView, but since my component doesn't explicitly have ownership of the list handling, I'd argue that PreferenceFragmentCompat should do this cleanup.
It would be solved by setting the RecyclerView adapter to null in the fragment's onDestroyView.
Here's a memory dump.