Ive been using `val t = Class.forName(name).kotlin...

# multiplatform

[Zoltan Demant]

Ive been using val t = Class.forName(name).kotlin then when(t) { TypeA::class -> etc } to save/restore navigation state in my application. Im leaning towards switching to kotlin-serialization for this to support multiplatform, but thought Id first ask if theres a easier way to acheive this kind of logic without any extra libraries?

[Joel Denke]

https://github.com/slackhq/circuit/blob/main/circuit-retained/src/commonMain/kotlin/com/slack/circuit/retained/RetainedStateRegistry.kt
Can check this 🙂 Otherwise there is Parcelize libraries, such as Moko to use Android parcelable in all platforms. Depends what you want to store.
This is one core reason to use a navigation library imo 😜

[Zoltan Demant]

Thanks 🙏🏽 That looks similar to what SaveableStateRegistry does! Which is what Im using under the hood when running on compose. All I want is to have a somewhat type safe way to store my types in the registry, I thought the class name worked well for that purpose until I realized it wasnt available in multiplatform!

[Joel Denke]

Yeah I think the devs in that library pretty much did a variant if Googles lifecycle thingy. For Circuit I am using @CommonParcelize to being able to mutli platform serialization.
There is some limitations in Android, not gives you full power of storing like Serializable Java Android scope things in same way @Serializable in Kotlin. In that sense I think they added Parcelable on top of this to allow custom classes. And now we adding a new layer of complexity using multiplatform 😄
Ideally Google would provide a new way of do like rememberSaveable working multiplatform not using Android SDK things, more decoupled interfaces and hide the implementation details from us or give us the power of choose doing it ourselves. Dont know the state, if they working in this direction, but pretty much sure I read that they working on doing androidx lifecycle KMP supported 😜 See https://issuetracker.google.com/issues/317249252#comment2
I would not do this myself, thats for sure 😛

[Joel Denke]

Oh they already coded it 😄 https://android-review.googlesource.com/c/platform/frameworks/support/+/2927699
I guess next lifecycle androidx release being KMP then 😄

[Joel Denke]

Thats the last nail for androidx viewmodel as well I think, I remember asked about in the past why we cant having our own compose viewmodels not using androidx lifecycle hard coded.
To make them agnostic, and using their own state handling to survive config changes etc without inherit the entire Android SDK doing so 😛
It makes sense both in Android native and multiplatform world in many scenarios. Glad to see its going into that direction.

[Zoltan Demant]

Thats a nice change 👍🏽 Even though Im not using viewmodel, happy to see the whole ecosystem moving in this direction.

As for saving state, didnt mean to get into such deep detail but personally Ive been using okio for my state saving. Everything just boils down to a ByteArray that gets stored in SaveableStateRegistry 😃 Its super effective, and this question isnt really about its capabilities, rather my own choice for how Id like to store what type a given class is. You can imagine that my KClass<T> points to a sealed class/interface that has a bunch of variants, Id just like to be able to store each type along with its (optional) parameters like someItemId, etc. I can always just store the name, but that seems too error prone for my liking.

[Joel Denke]

Yeah probably this is something Jetbrains/Google or such could/will provide a more granular power storage, not coupled to Android SDK limitations. But I think its about performance as well as security. Hard to sandbox all data if to uhm open to any storage variant 😛 Restoring the state I think is the most painful thing to solve, like where and how restoring it back into ui layer. If its important to keep like config such as rotation config changes in Android or can discard that in navigation. Like rotate screen while navigate 😄