hey serialization friends- I've looked at <https:/...
# serialization
c
hey serialization friends- I've looked at https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/json.md#content-based-polymorphic-deserialization but I wonder if it's possible to augment how a single field is deserialised based on another field. Something like:
Copy code
{
  "type": "STATE",
  "state": {
    "foo": "bar"
  }
}
and
Copy code
{
  "type": "STATE-CHANGE",
  "state": {
    "foo": [
      "bar",
      "baz"
    ]
  }
}
I'm not clever enough to parse the documentation to understand if that is possible, or if I need to go turbo and make a custom serializer
a
a regular ol’ sealed class should handle that situation, if you use a separate subclass for each response type https://github.com/Kotlin/kotlinx.serialization/blob/v1.5.1/docs/polymorphism.md#sealed-classes
c
I went with a sealed interface and that didn't seem to work, I'll try a sealed class instead, cheers Adam
a
what problem did you have? There shouldn’t be a significant difference between a sealed class and sealed interface. Did you set
@SerialName("STATE-CHANGE")
and
@SerialName("STATE")
on the subclasses?
c
oh 😮 wait, I can set a discriminator based on the type field?
ok I really need to read the docs now
because that's starting to make sense!
because the type implies the state field's type, I was confused how I could associate them
a
yeah, it should just work! Normally it’s a little bit awkward to decode polymorphic JSON because not all JSON has the
type
field, but it looks like you’re lucky
c
thank dyson for that >_>, <_<
a
the vacuum company?
c
the very same
a
haha weird
c
wait so, their actual data structure uses a 'message' field, not a 'type' one
if I literally change the json text to replace "message" with "type" 😂 would that actually work? Sorry I'm doing that thing where I ask questions instead of just trying
a
yeah, that should work
and no problem, questions are good :)
try taking a look at this answer, it tackles a similar problem https://stackoverflow.com/a/73145311/4161471
c
ok I was looking at this all wrong thinking about it, I messed up my representation of the data structures coming back, I think I can do everything I need now. What I was trying to do was have a kind of generic parent class called
Message
and the contents of that class would vary wildly depending on the type of message being received. I was trying to be able to deserialise the
Message
type with a single member having it's class type changed, but that's a no go. What's more accurate and easier to deal with, is having a sealed interface called
Message
and a
StateMessage
and
StateChangeMessage
accordingly
cheers @Adam S, really helped us crack the case on this one
a
yeah exactly! It’s really best to be as explicit as possible with KxS, and avoid generic types. So even if you did need some generic typed class, e.g.
Copy code
class Message<T>(
  val contents: T
)
instead make T sealed, and remove the generic type from Message
Copy code
class Message(
  val contents: MessageContent
)
That’s a rough rule of thumb, it won’t always hold. And it seems a bit weird and counter-intuitive, but it will pay off with explicitness.
c
the compile time nature of the serializers makes that a requirement too right?
a
basically, yeah. KxS can handle classes with generic types, but it just requires a bit more setup and care, so you have to manually specify them.
so it’s not a strict requirement, but it does require some manual definition
c
cheers dude, really appreciate the heads up! I can confirm I can get all kinds of status updates from my fan now 😂
a
haha, good to know
what fan do you have?
c
the Dyson Pure Cool, you can get them for like 100 quid off refurb on ebay
though when I got mine, they sent me the wrong remote... which I think was a guerilla attempt to get me to download the app
it has an MQTT interface that I got integrated into home assistant thanks to the work of some legend on github (https://github.com/shenxn/libdyson) and now I'm just working it into my little remote control noddy app I've got for learning KMM
a
ahh that’s cool, thanks for the tip
c
fwiw too! If I change the classDisriminator property on the
Json
instance used to deserialise the object I don't have to text replace
msg
to
type
which is cool
a
oooh yes, good point, I forgot about that