Hi Everyone, As we know, We can add a nullable typ...

# android

[Pardeep Sharma]

Hi Everyone, As we know, We can add a nullable type for optional fields. Is there any other optimal way to generate a Data class for the below JSON hierarchy?

[Pardeep Sharma]

[
{
"type": "article",
"id": 10,
"lastUpdated": 1661583198,
"title": "Article Mission Mars",
"description": "Lorem Ipsum is simply dummy text of the printing and typesetting industry.",
"imageURL": "https://picsum.photos/200",
"likes": 23,
"shares": 100
},

{
"type": "video",
"id": 22,
"lastUpdated": 1661583343,
"title": "Video Mission Mars",
"videoURL": "https://picsum.photos/200"
},

{
"type": "advertisement",
"id": 33,
"lastUpdated": 1661583343,
"adImage": "https://picsum.photos/200",
"redirectURL": "https://www.google.com"
}
]

[Frank Bouwens]

package com.example.example

import com.google.gson.annotations.SerializedName


data class ExampleJson2KtKotlin (

  @SerializedName("type"        ) var type        : String? = null,
  @SerializedName("id"          ) var id          : Int?    = null,
  @SerializedName("lastUpdated" ) var lastUpdated : Int?    = null,
  @SerializedName("title"       ) var title       : String? = null,
  @SerializedName("description" ) var description : String? = null,
  @SerializedName("imageURL"    ) var imageURL    : String? = null,
  @SerializedName("likes"       ) var likes       : Int?    = null,
  @SerializedName("shares"      ) var shares      : Int?    = null

)

Source :

https://json2kt.com/

[Michael Krussel]

If you use kotlinx serialization or moshi (I believe) you can provide default values for optional fields instead of making the fields optional.

[Chrimaeon]

its just the json is poorly architectured. I would just get rid of the type and move it up a hierarchy so to have a list with the individual types. then your paring would not require empty fields.

{
  "article": [
     <list of articles>
  ],
  "video": [
     <list of videos>
  ]
}

[Arne Jans]

Since the target-data-class is mappable by the type-value, with Moshi, you can map this flexible JSON-structure to one data-class per type:

val moshi = Moshi.Builder()
    .add(
        PolymorphicJsonAdapterFactory.of(RssFeedEntry::class.java, "type")
            .withSubtype(ArticleFeedEntry::class.java, "article")
            .withSubtype(VideoFeedEntry::class.java, "video")
            .withSubtype(Advertisement::class.java, "advertisement"),
    )
    .build()

This would save you the hassle of having to define optional fields, since you would have a clean separation per subtype.
You can put common JSON-fields like type and ID into the abstract class RssFeedEntry.
For me, deserialization of a Long-type common field did not work, though, I had to declare it as Int to work correctly (which might not be an option for lastUpdated), but you can always duplicate Long-fields for each needed usage in a subtype.

Here are the details for this PolymorphicJsonAdapterFactor of Moshi:
https://github.com/square/moshi/blob/ed3e66b1a94e1efd36853e5779011e5ae1b60843/mosh[…]va/com/squareup/moshi/adapters/PolymorphicJsonAdapterFactory.kt

[Arne Jans]

@Chrimaeon Simplifying the JSON-structure might not always be an option, e.g. in the following cases:
1. You don't have the JSON-structure under your control
2. The JSON-structure for the elements are needed in this format, since it might be a mixed list of JSON-objects with variable type, for which their order in the list matters, e.g. like an RSS-feed, a searchresult-response of a service with multiple search-entity-types, etc.
But you are right, if the possibility is there, your solution would be the most straight-forward one.

[Pardeep Sharma]

Thanks @Arne Jans @Chrimaeon @Frank Bouwens. This is indeed helpful!