https://kotlinlang.org logo
Join Slack
    ankushg

    ankushg

    2 years ago
    Copy to Clipboard
    I'm working in a multiplatform project where we have a few 
    actual typealias MyClass = String
    for some platforms, while using 
    actual data class MyClass(val someVal: String)
    on other platforms. We also have an 
    expect val MyClassSerializer: KSerializer<MyClassSerializer>
    which we set equal to either 
    StringSerializer
    or the generated serializer for the data class. We declare 
    contextual(MyClass::class, MyClassSerializer)
    in our common serialization context. On platforms where we typealias to Strings, we get a 
    SerializerAlreadyRegisteredException: Serializer for class String already registered in this module
    , even though our 
    MyClassSerializer
    points to the built-in 
    StringSerializer
    . Is there a way to avoid this error? • I see the 
    overwriteWith
    option, but it feels scary to use this since I'd be overwriting behavior for ALL Strings. It seems easy to declare a custom serializer for a type without realizing that this might change behavior for every String in your app. • My understanding is that using an inline class instead of typealias might help here, but I'm not sure about the state of inline classes in multiplatform. • Can I contextually register a serializer if-and-only-if there isn't already one registered for the type? • Is it possible for the contextual registration to do an equality check on the 
    KSerializer
    and not throw an error if we're just redeclaring the preexisting association?
    Robert Jaros

    Robert Jaros

    2 years ago
    Copy to Clipboard
    why do you use actual/expect serializers?
    Copy to Clipboard
    can't you just define normal serializers for each platform?
    Copy to Clipboard
    if you need same serialization based code in the common module, maybe just create an expect/actual helper function?
    ankushg

    ankushg

    2 years ago
    Copy to Clipboard
    Ideally we'd have one common SerialModule that doesn't know/care about the underlying implementation details for how each platform represents classes… I guess we could work around this issue by building platform-specific SerialModules for classes relying on expect/actual and then use 
    include
    to pull them into the global SerialModule we define in Common?
    Robert Jaros

    Robert Jaros

    2 years ago
    Copy to Clipboard
    maybe it would be enough to have one serialmodule in common, but just register it in platform code (only where the actual class is not String)
    Copy to Clipboard
    I'm not sure it's possible, I'm just comparing your use case to mine
View count: 4
Join thread in Slack