I need to pass a complex object via navigation. Th...
# compose
u
I need to pass a complex object via navigation. The type lives in a pure kotlin module, so no android. Would you rather create a private wrapper that is
Parcelable
or, serialize it via
Json
or
Protobuf
Btw I meaasured the protobuf and it still sometimes takes 2ms to serialize (measured in debug mind you) TLDR; is it unreasonable for passing arguments to take 2ms in runtime, or should I rather sacrifice developer time and write the silly wrapper?
a
Hoist it into a higher lived object like activity level or app level. When you “need” to pass large objects like that , it’s a code smell.
u
why would it be a code smell? its not large, couple of fields, basic struct
a
The word “complex”
u
as opposed to primitive
a
Serializing it to a single field could easily by done by doubly encoding it key + value as a single parameter value
Just in case you got values that have spaces or special characters, assuming you mean jetpack navigation
u
you mean like this?
Copy code
bundle.putString(.., struct.foo)
bundle.putString(.., struct.bar)
a
Compose navigation? Or android navigation
u
well, both really, I though compose nav could take a bundle as well .. is it only a string?
a
Jetpack navigation compose only takes url arguments
Pretty sure
u
I see, so even lamer do people really destructure it to n query params manually? that seems so backwards tbh
coming from ios, I only want to pass this struct to a screen, thats it .. its not backed by database or any other reactive store, simply a tuple of n values
a
It’s not bad to write a library to do it. https://github.com/raamcosta/compose-destinations We at my company I’ve written a library that’s type safe too using ksp
u
think parsed from a deeplink
s
If you want to keep your sanity, just use this https://github.com/kiwicom/navigation-compose-typed and you can pass the object as-is, as long as it is @Serializable
👍 1
a
You might enjoy compose destinations
s
And if you notice this https://issuetracker.google.com/issues/188693139 you will see that the official library is building their type-safe tooling exactly around kotlinx.serialization as well. So the migration to the official solution will be painless
👍 1
u
I see, but that does what, serialize it to json synchronously on main thread?
I mean I could do that myself, I was just curious about perf impliciations
since 2ms ... idk, that seems like a lot.. on a 120Hz screen you have what, 8ms to do everything?
u
right .. so I guess it's fine? I mean it does fall down to 0-1, probably some caching of the serializer happening etc
s
Yeah, if you are worried try to profile your app to see how fast this happens. I doubt it’s a problem, especially serializing a class with 2 objects as you say
u
what time would you consider not fine?
anyways good to know they're going this way anyways, thank you!
s
what time would you consider not fine?
The time which makes my app miss frames 😄
anyways good to know they’re going this way anyways, thank you!
Yeah unless I am missing something it seems like they indeed are doing this too
z
You can also consider instead passing a key/id of the complex object, then retrieving it from some form of cache 🙂
u
sure if you have it, I mean for the times when you don't have a store