What will it take to pass a parcellable as an argument? @Ian Lake

In general, this isn't something you should consider doing: pass the ID of the item instead of the item itself. The route structure in Navigation Compose has the best analog with a restful web service

profile/{id}

not

profile/{a whole set of fields representing a user's profile}

which is essentially what passing a parcelable is doing

Ok thanks

It's an extension function.

Yep, import the extension function

Doesn’t this extension come with this dependence?

androidx.navigation:navigation-composite:1.0.0-alpha01

Import should be one of the quick fixes for that error. Was that not the case for you?

Exactly

Does an issue have been filed regarding this behavior?

There's no intention to change the behavior, but please do file a bug so we can properly call this out in the documentation

I mean we do need to import that function manually, Android studio isn't suggesting the same

Ah, yes you should file a bug against Studio if it isn't suggesting extension functions

I'm still confused.. where do I import it from? Edit: Found it..

import androidx.navigation.compose.navigate

@Ian Lake what do you think about this solution to disallow complex types as argument type? https://github.com/jeziellago/androidx/commit/fa4711838092061ca02409b998a59f12ef0b7143

No, that's not the right approach. The problem isn't with having arguments with complex types - that's actually totally fine (and you could absolutely use an

EnumType

with a

defaultValue

to build an argument based listener ). It is easy to conflate the list of arguments in your route with the total list of arguments, but those are purposefully separate things

Interesting! Thanks!!

@Ian Lake When we send a result back through the previous back stack entries' SavedStateHandle, putting a Parcelable object in there is no problem. It's unclear to me if it's fine to use Parcelable there or if we should avoid that as well. Because why send Parcelables in one direction but not the other?

The first thing you should do is define your single source of truth. An observable repository is an example of a source of truth - any destination can read that data and get the same answer back. Any source can update that data and have it automatically flow back to everyone using that source of data. Arguments and results should not be a source of truth for your app's data

@Ian Lake. I see, thank you. The Parcelable I'm sending back is not an entity. It's a sealed result class. Is it fine to put that in the

SavedStateHandle

of the

previousBackstackEntry

?

Nothing is going to stop you 👍

Alright, thank you very much!