Configuration Driven

It is common practice when delivering a Liquid solution, that the application be configuration driven. This means that certain parts of the application can be changed without the need to push out a new iOS build. The following components in an application are typically configuration driven:

• Registration images
• The text that shows up in a table view
• Colors / Fonts across the application

When we want to make an item in the databse that denote is strictly for configuration, give it a category of config. This is strictly to keep with organization, mainly in MC. Next change the permission type to All. This can configured in the schema itself. Next you can give fields just like any other schema. Typically for this if you want a free form structure, you can have the field type of jsonElement. Let's take a look at an example below. The color palette item was designed so that the hex colors could be switched / modified at any given time without impacting the iOS code.

  "community": "TestCommunity",
  "permissionType": "All",
  "fields": [
    {
      "dataType": "refnum",
      "name": "colorPaletteId",
      "primary": true
    },
    {
      "dataType": "jsonElement",
      "name": "colorMapping"
    }
  ]

"data": {
    "colorPaletteId": "testColorPalette",
    "colorMapping": "{\"orange\":\"FD4249\",
 \"gray\":\"828280\",\"darkGray\":\"333333\",
 \"pinkDust\":\"E4CFC6\",\"bluePearl\":\"D1D5DB\",
 \"quartzite\":\"977F83\",\"flamingos\":\"FD7A81\",
 \"lightBlue\":\"CFCEDE\",\"pearlCream\":\"FAEFE3\",
 \"purplePotion\":\"001F\"}

The item above lets the developer swap the color palette out whenever they please. It is recommended that configuration items typically be loaded during application initialization (perhaps in a helper class), and then attach an observer to them, and refresh your internal data structures accordingly, so that you will always have the latest and greatest in memory. There is no limit as to what the developer can make configuration driven.