NavTypeSerializer not used from separate module

[kassim]

I've created a serializer
@NavTypeSerializer class BitmapTypeSerializer : DestinationsNavTypeSerializer<Bitmap>
(I know its probably inefficient to serialise a bitmap between screens but that's a different point)

I also have my composable destination

@Composable
@Destination
fun ReviewScreen(destinationsNavigator: DestinationsNavigator, bitmap: Bitmap?) {

when I put BitmapTypeSerializer next to ReviewScreen in the same package the serialization works fine, but when I move the Serializer to a navigation module that my feature module depends on, the codegen decides to use DefaultParcelableNavTypeSerializer instead of BitmapTypeSerializer

[raamcosta]

Hey 👋

Yeah at the moment this is expected. Ksp tasks are completely isolated inside each module. So it only knows about classes of that module.

But btw passing bitmap really is not something you want to do, the Android Binder only has 500 kb of space, so you can easily get exception if you’re using it for something like a bitmap.

Anyway I’ll keep this open so I can investigate if there is a way to know about classes of other modules on ksp task.

[raamcosta]

I was developing a feature for this, but I realized it's stupid to have a specific API just for this.
Because ideally, we register a nav type serializer globally for that type in that module and for that, there is nothing simpler then what is already possible.

@NavTypeSerializer
object ClassFromOtherModuleSerializer : DestinationsNavTypeSerializer<ClassFromOtherModule> by NavTypeSerializerDeclaredOnTheOtherModule

[raamcosta]

@kassim @Nek-12 What do you guys think? Am I missing something?

[Nek-12]

Yeah I think what I consider to be a "workaround" looks good from the code standpoint, but still, this does not solve the problem of some people wanting to use different serializers for different composables or even parameters. I believe such a use case is going to appear at some point. Kotlinx.serialization doesn't have anything like the module serializer, but it does have a file-wide, class level and parameter-level annotations, which is I think the most flexibility there possibly could be.

Taking into consideration the fact that you want to deprecate multimodule setup in #216, which solves the visibility problem of this issue, you may want to decide to be opinionated and not change anything.

In the end it depends on what we do about that issue I think

[pawelsmagala]

@raamcosta bump on this - would be nice to be able to define global serializer for specific type that is reused in every module

[kassim]

Sorry. Missed this. I think the workaround is okay, I assume many devs may want global defined serialisers but perhaps that's an argument of preference.

An issue of this is a user probably wouldn't know this workaround needs to be used. A warning/error can't be produced unless something does scan to check and then tell the user "oh, by the way this may not serialize as you expect" and if you've written that then I guess it's not many steps away from that process actually just facilitating the usage of that serializer cross-module.

An alternative might be DefaultParcelableNavTypeSerializer and other default serializers are always used, unless there's a specific annotation on the argument that defines a custom serializer to use.