Fixed
Status Update
Comments
cl...@google.com <cl...@google.com>
ap...@google.com <ap...@google.com> #2
My apologies. Looks to be a duplicate of
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.