czuckie
06/15/2023, 6:20 PM{
"type": "STATE",
"state": {
"foo": "bar"
}
}
and
{
"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 serializerAdam S
06/15/2023, 6:46 PMczuckie
06/16/2023, 9:38 AMAdam S
06/16/2023, 9:40 AM@SerialName("STATE-CHANGE")
and @SerialName("STATE")
on the subclasses?czuckie
06/16/2023, 9:41 AMczuckie
06/16/2023, 9:41 AMczuckie
06/16/2023, 9:41 AMczuckie
06/16/2023, 9:42 AMAdam S
06/16/2023, 9:42 AMtype
field, but it looks like you’re luckyczuckie
06/16/2023, 9:43 AMAdam S
06/16/2023, 9:43 AMczuckie
06/16/2023, 9:43 AMAdam S
06/16/2023, 9:43 AMczuckie
06/16/2023, 9:43 AMczuckie
06/16/2023, 9:44 AMAdam S
06/16/2023, 9:45 AMAdam S
06/16/2023, 9:45 AMAdam S
06/16/2023, 9:46 AMczuckie
06/16/2023, 9:53 AMMessage
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
accordinglyczuckie
06/16/2023, 9:54 AMAdam S
06/16/2023, 10:00 AMclass Message<T>(
val contents: T
)
instead make T sealed, and remove the generic type from Message
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.czuckie
06/16/2023, 10:00 AMAdam S
06/16/2023, 10:01 AMAdam S
06/16/2023, 10:02 AMczuckie
06/16/2023, 10:09 AMAdam S
06/16/2023, 10:09 AMAdam S
06/16/2023, 10:09 AMczuckie
06/16/2023, 10:15 AMczuckie
06/16/2023, 10:16 AMczuckie
06/16/2023, 10:17 AMAdam S
06/16/2023, 10:33 AMczuckie
06/16/2023, 10:37 AMJson
instance used to deserialise the object I don't have to text replace msg
to type
which is coolAdam S
06/16/2023, 10:38 AM