Having previously discussed here the benefits of separating the data for the app’s questions from the functionality in the code, the question still stood on how to best go about achieving this goal.
Speaking to our tutors, and doing our own research as well, there appeared to be several different options to explore which could provide a suitable solution in the context of our work.
P-lists, more formally referred to as property lists, are files used in OSX and iOS programming to store serialised objects. They are generally utilised to store a user’s settings for an app, however can be leveraged to store various information about applications. In this current context, a property list file could be used to store information about each question contained within our app.
These files are most commonly formatted in either an XML or a binary form, and can be edited in a text editor. Additionally, the Xcode environment has built in support for editing property lists. These files can be viewed in a hierarchical manner and edited in a similar fashion.
Usefully, one such programming language with support for the JSON format is Swift. Even more usefully, we have already been given somewhat of a head-start on using JSON in Swift, due to a tutorial workshop that was given which covered some of the basics. Storing our data in the JSON format makes sense at it is somewhat of a standard for data transfer, being somewhat easier to use that XML-based solutions, and after some trial and error I have had more success adapting the currently stored information to this format than to a property list-based structure. The JSON format also, similarly to P-lists, has the benefit of being easily human-readable and understandable in its text-based representation. Unlike the property list format, there is no visual hierarchical editor built into Xcode, but I do not think this is too big a consideration, since part of the point of separating the data from the code to begin with is to make it easily editable by people with no knowledge of the code base of the application – people who would likely not wish to use the Xcode software to make these changes anyway.
After deciding that our data will be stored in the JSON format, there is still the question of where exactly it will be stored. This format lends itself well to communicating with an external server to fetch data over the internet. This, however, would add an additional layer of complexity to the development process and would come with its own set of problems and limitations. We are unsure at this moment in time whether to go down this road or whether to store our data on the local filesystem with the application, as these methods both have their relative strengths and weaknesses. In either case, however, a JSON-based approach to providing the code with data for the questions is likely to be feasibly achievable, and therefore we have decided to adopt this technology moving forwards. I will post the progress we make with implementing this functionality as it is made.
Introducing JSON [online]. JSON.org. Available from: http://json.org [accessed 15 May 2015].