Allow @kotlinx.serialization.Serializable for Navigation Results

[cvb941]

Kotlin's @Serializable types currently work as navigation arguments, but not for navigating back with a result using ResultBackNavigator and ResultRecipient.

Is it possible to add support for @Serializable there as well?

[petrstetka]

Hello @raamcosta, Is there any way I can help implement this? I would like to see a support for this, or rather I need it because without this kotlinx.serializable is not possible to fully use with this library and I don't want to resort to using parcelable or other serializers when the official kotlinx.serializatio is here with us today.

You wrote last this:

kotlin("plugin.serialization")

Hmmm I'd like to avoid this if possible. I don't known yet exactly how.. I'm guessing we can also generate the serializers like we do for navigation on the user's module and have them point to them by passing their instance or something like this. To be honest, if this is the only way, I'd rather not do it. I don't want to force this dependency on all users of the library. Maybe we could make this a separate dependency, but that also comes with additional overhead for all maintainers...

So do you have an idea how it should work and how to implement it? From what I've seen in the code for resultRecipients / resultNavigator there is no generating the serializers now as in the case of navigation arguments, is that right?

[LukasAnda]

@raamcosta any updates on this please? It forces me to not to pass data back as originally intended but only by ID or serialize to String since I removed all Parcelable/serializable imports due to KMM.

Or, is there any way I can help to support this feature?

[ryanholden8]

+1 for this request. When reading the docs I thought this was already implemented but we get this error:

com.ramcosta.composedestinations.codegen.commons.IllegalDestinationsSetup: Composable Screen, ResultDataModel: Result types must be one of: String, Long, Boolean, Float, Int, Parcelable, Serializable

I guess Serializable here is referring to java.io.Serializable ? I had to dive into the source code to figure that out.. I think Serializable referring to @kotlinx.serialization.Serializable would be a more natural conclusion for most Kotlin projects..

[ryanholden8]

Ah seems like java.io.Serializable vs @kotlinx.serialization.Serializable is a common mistake: https://github.com/raamcosta/compose-destinations/pull/266#issuecomment-1588719190

[whitescent]

Any updates on this? @raamcosta

[raamcosta]

Hi 👋

No, this is not a priority for v2 at the moment.

[petrstetka]

Hey @raamcosta any progress on this?

It would be very useful to have support for @kotlinx.serialization.Serializable in navigation result. Then we can just use kotlinx.serialization everywhere.

[raamcosta]

No efforts done here so far.

Given this is for now an Android only library, I don’t think it’s a big deal, just mark the class as Java Serializable and move on (or Parcelable but that’s a bit more work I guess).

That said, I am working on KMP support and this will be needed for the feature to work, so it will probably force me to look at this again.

[raamcosta]

Good news!

As expected while adding KMP support, it made me look into this.

I already know how I'm going to make this work and it will be even better than allowing Kotlinx Serializable. Basically, any supported navigation argument type will also work in the back navigation case.

I do need quite some changes to make this happen, but I think the result will be pretty great! Stay tuned!

[petrstetka]

@raamcosta That's great news. I look forward to it. Thank you