https://kotlinlang.org logo
Join Slack
Powered by
java.lang.UnsupportedOperationException: Arrays do...
# compose
f
java.lang.UnsupportedOperationException: Arrays don't support default values. Does anyone know why I can't pass StringArrayType in compose navigation?
i
Routes, the way of navigating between destinations, are like URIs. They don't support arrays or complex types. What are you trying to do?
f
Trying to pass list/array of strings to a navigation composable
The string list/array consists of 5 dynamic URLs that i need to provide everytime i open that screen
i
Okay, so why 5 dynamic URLs?
f
Because i have these 5 urls on the list screen and i want to have them in the details screen
And they're different for every list item
i
So every list item has 5 urls associated with it?
f
True
i
So you should be passing the ID of the list item through your arguments, not the individual fields of the list item, same as if you were trying to pass a Parcelable
👍 1
f
When i open the details, i call an API with the id as the first navigation (route) parameter passed to the navigation and these 5 URLs as a second parameter
Because in the details of the API i don't have these URLs
Limitations of the backend
i
It seems like the same approach suggested for Parcelables, or any complicated set of data, also applies here. Don't send all your content your arguments. https://kotlinlang.slack.com/archives/CJLTWPH7S/p1604087992002000?thread_ts=1604053414.451400&cid=CJLTWPH7S
g
Is there somewhere where you elaborate on the rationale behind this design choice, @Ian Lake? I don't quite understand the choice to stop supporting navigation with complex arguments.
i
You mean, like in that thread I just linked?
g
The thread says what to do, not really why. Unless I missed something.
I'll check it again.
i
g
But again, this seems more like an argument in favour of caching than against complex navigation arguments. It seems to me that this approach requires the new view to sort out its own dependencies instead of allowing the previous one provide them.
f
Is there a possibility to obtain the view model holding the list somehow, like scope it to the previous backstack entry or something and just get the model with the id from that list?
i
Again, you have keep in mind that your app can be killed and then later restored at any point in time. It will come back up at the same destination it is at, but any ViewModel / in memory only information is going to be lost
👍 2
f
Same goes with in memory database as a temp data holder for the URLs?
i
Your list of items should already be just displaying data from a local repository; your detail view should just be accessing that same local repository
👍 3
f
Right, so there's no way to pass lists as nav argument to compose at all?
g
It's not currently supported and there are no plans to support it AFAIK.
😢 1
It may be a blessing in disguise, @FunkyMuse. It will "force" us to think about a single source of truth, persistence and process death.
f
Yeah true that, some habits die hard
but i guess there should be an information pointing that
since NavType.StringArray still exists
then i guess Parcelize won't have much usage in the future, i.e deprecateD?
g
I believe it still has its place in passing arguments to activities and fragments, just not composables.
g
Compose still needs to interface with the platform. The underlying APIs are unlikely to stop using Bundles and Parcelables. We’ll still use 
@Parcelize
for state restoration going forward: https://developer.android.com/jetpack/compose/state#restore-ui-state
28 Views
Open in Slack
PreviousNext
Powered by