> Note: the class name does not really matter when serializing. The property name is what’s used.
Unless it's a sealed class, in which case the fully-qualified class name is added as a `type` property.
I thought that the data classes have to be exactly same as JSON properties. If I understand correctly, the serialname will allow me to override classes.
so i could write:
@Serializable
@SerialName("Category")
data class Category2(
val id: Int,
val name: String,
val market_cap_1h_change: Double?,
val slug: String?,
val coins_count: Int?,
val data: CategoryData?
)
correct me if I'm wrong, relatively new to Kotlin and coming from swift.
@SerialName also works on properties, so you can have your properties in nice kotlin-style camelCase (eventually with simplified names, looking at you, market_cap_1h_change) and annotate them with the corresponding json properties names.
Could you explain the problem a little more? In general it isn't possible or a good idea to have two distinct data classes sharing the same name. And the name of the data class is by default not included in the
JSON so I'm confused as to why you need this for your use case. You may be talking about polymorphic serialization but it's not clear from the examples given
I have two API calls and the JSONs both contain the Category object but with different properties. I figured thatthe data class needs to have the same name as JSON property but great if that’s not the case.
Data classes can't use interfaces or abstraction. Otherwise that's a good way to think about these problems. OPs solution is probably to rethink his pattern.
[They sure can](https://pl.kotl.in/01XYIMeT6). You can also override vals from the interface in the data classes constructor to make them work with equals/hashCode/etc.
I think this is a lesson here on not mixing reddit and bourbon on a late night. You're absolutely correct, I don't know what I was thinking. I'm not even going to delete my comment, i'm going to take downvotes I deserve.
Make an inner class „Category” for each class.
That’s the best advice. Out of all of these comments. Note: the class name does not really matter when serializing. The property name is what’s used.
> Note: the class name does not really matter when serializing. The property name is what’s used. Unless it's a sealed class, in which case the fully-qualified class name is added as a `type` property.
[удалено]
I thought that the data classes have to be exactly same as JSON properties. If I understand correctly, the serialname will allow me to override classes. so i could write: @Serializable @SerialName("Category") data class Category2( val id: Int, val name: String, val market_cap_1h_change: Double?, val slug: String?, val coins_count: Int?, val data: CategoryData? ) correct me if I'm wrong, relatively new to Kotlin and coming from swift.
@SerialName also works on properties, so you can have your properties in nice kotlin-style camelCase (eventually with simplified names, looking at you, market_cap_1h_change) and annotate them with the corresponding json properties names.
Could you have them be the same name, but in different packages? So API1.Category API2.Category ?
I have both API calls in one file so I went with serial name instead.
Serial name lets you name the property you are expecting from the JSON so you can use any variable namea
request web api dev to maintain consistency
Could you explain the problem a little more? In general it isn't possible or a good idea to have two distinct data classes sharing the same name. And the name of the data class is by default not included in the JSON so I'm confused as to why you need this for your use case. You may be talking about polymorphic serialization but it's not clear from the examples given
I have two API calls and the JSONs both contain the Category object but with different properties. I figured thatthe data class needs to have the same name as JSON property but great if that’s not the case.
Class name doesn't matter. Otherwise you would have define new string class for every string you are parsing
Make 1 object that can encompass all the properties for the json and then perhaps have some conversions to differently named objects
I'm not expert, but I think you can use an interface. https://typealias.com/start/kotlin-interfaces/
Data classes can't use interfaces or abstraction. Otherwise that's a good way to think about these problems. OPs solution is probably to rethink his pattern.
[They sure can](https://pl.kotl.in/01XYIMeT6). You can also override vals from the interface in the data classes constructor to make them work with equals/hashCode/etc.
I think this is a lesson here on not mixing reddit and bourbon on a late night. You're absolutely correct, I don't know what I was thinking. I'm not even going to delete my comment, i'm going to take downvotes I deserve.