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"]
      }
    }
  ]
}

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)