HomeCard Api Response

Models.kt

sealed class HomeCard {

    data class Campaign(val campaignId: String,
                        val imageUrl: String,
                        val videoUrl: String?,
                        val mapUrl: String,
                        val title: String,
                        val progress: Int,
                        val footer: Footer) : HomeCard()

    data class TheTable(val imageUrl: String,
                        val videoUrl: String?,
                        val title: String,
                        val subTitle: String,
                        val footer: Footer) : HomeCard()

    data class Impact(val numberOfMeals: Long,
                      val numberOfUsers: Long) : HomeCard()

}

sealed class Footer {

    data class Simple(val icon: String,
                      val text: String) : Footer()

    data class Friends(val friends: List<String>) : Footer()

}

response.json

{
  "homeCards": [
    {
      "type": "impact",
      "numberOfMeals": "38,000,000",
      "numberOfUsers": "26,000"
    },
    {
      "type": "campaign",
      "id": "syria",
      "imageUrl": "www.sharethemeal/com/syria.jpg",
      "videoUrl": "www.sharethemeal/com/syria.mp4",
      "mapUrl": "www.sharethemeal/com/map.jpg",
      "title": "Syria",
      "progress": "15",
      "footer": {
        "type": "simple",
        "icon": "www.sharethemeal/com/comeicon.jpg",
        "text": "help children now"
      }
    },
    {
      "type": "theTable",
      "videoUrl": "www.sharethemeal/com/syria.mp4",
      "imageUrl": "www.sharethemeal.com/syria.jpg",
      "title": "Subscribe for monthly etc",
      "subTitle": "monthly giving",
      "footer": {
        "type": "friends",
        "friends":  ["Alex","Arun","Matthias"]
      }
    }
  ]
}

hey everybody, so instead of having a universal layoutId on all responses, you are advocating for a type attribute which is unique in the context of each content type (HomeCards, NewsFeedItems, etc...) right?

If that is the case, that is fine for me. This naming convention can actually also be adopted by the design team while doing the mockups ( as in hey! how far are you guys implementing the support for homecards of the campaign type ...)

I totally agree with not having anything related to how to display things in the backend responses.
The gist looks good to me, I'd just change the id field to be campaignId, since otherwise being in the root of a homeCard element seems to be its id. Also I'd like to avoid any use of theTable as an identifier replacing it for just subscription or something like that, since it's more generic and representative name and doesn't bind us to a name that potentially could change.
Finally I wonder what's the benefit of having different types of footers, or what does a friends footer means. But we can discuss which types are needed there in the next meeting.

Some additional comments:

// general

• I'm advocating to keep more of the strings in the backend rather than loading them as part of the overall app localization, for better maintenance and for keeping the app localization slim
• I'm recommending to create re-usable structures to ease re-usability across endpoints

// overview homecard

• needs map image
• numbers should remain integers so the clients can use count-up anims

// campaign homecards

• need itemId when clicked on info-i for more info
• footers: version with commodity icons missing
• footers: version with friends should rather contain properties for images and formatted string (unless the backend wants to take care of Arabic plural concatenation of names and the like)