Fixed
Status Update
Comments
cl...@google.com <cl...@google.com>
ap...@google.com <ap...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-main
Author: Clara Fok <
Link:
Fix fillInLabel not encoded by NavType
Expand for full commit details
Fix fillInLabel not encoded by NavType
When parsing labels in XML, the label will be retrieved via NavType.get. This means we will now respect the custom logic on how the label is to be retrieved from the SavedState.
Test: ./gradlew navigation:navigation-ui:cC
Bug: 388100796
Relnote: "NavDestination labels provided through XML will be parsed via NavType.get to ensure custom NavType logic is respected."
Change-Id: I7ec2f3e410b616e8933c8f5dd8015869906fb263
Files:
- M
navigation/navigation-common/src/androidMain/kotlin/androidx/navigation/NavDestination.android.kt
- M
navigation/navigation-ui/src/androidTest/java/androidx/navigation/ui/NavigationUITest.kt
Hash: 63ef852cfd918acb9b9661f739e8249cdee9f9d1
Date: Mon Jan 06 16:47:38 2025
cl...@google.com <cl...@google.com> #3
Fixed internally and available in navigation 2.9.0-alpha05
na...@google.com <na...@google.com> #4
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-common:2.9.0-alpha05
androidx.navigation:navigation-ui:2.9.0-alpha05
androidx.navigation:navigation-common:2.8.6
androidx.navigation:navigation-ui:2.8.6
Description
Component used: Navigation
Version used: 2.8.5
The attempts to fill in the
NavDestination.fillInLabel
methodlabel
of theNavDestination
with arguments. However, it does this by (in every case butNavType.ReferenceType
) by just callingargs[argName].toString()
- e.g., just directly callingtoString()
on the object in theSavedState
bundle.While this approach works for simple types, a custom
NavType
might not store their class directly in the Bundle - for example, if using the@Serializable
support, it would be stored as aBundle
, which means thetoString()
is unlikely to actually be what is needed.Instead,
fillInLabel
should take into account theNavType
and use itsget
method to give theNavType
control over exactly the object that is synthesized from the arguments. That way, developers could implement a customtoString()
implementation on their object to control how it is displayed in the label.