Model Decisions

I’m about to get started on a new iOS app and the first major decision is what form the model is going to take.

The app will be a quiz style app where my client will be providing the questions in the form of a large JSON file.

Initially I was going to create individual model objects, have a questions manager object read in the JSON file on launch and create the various question objects, along with their parent containers. The question tree is relatively complex, with each question sitting under three ancestor nodes.

In terms of persistence, the only things that I need to keep track of is how many times a user has attempted a question and whether or not they were correct on the last attempt.

Initial Idea

My initial idea was to have a questionManager, together with various model objects. The Question objects would vend an array of Answer objects. The controller would then pass back an array of Answer objects to the Question object which would update its state and return a tuple consisting of a Bool and an NSAttributedString object indicating whether or not the answer was correct, and giving more information about the correct answer.

This would work fine and persistence would be relatively straightfoward. After the initial read of the JSON file (which will run to around 2,000 questions), I would just have all the model objects conform to NSCoding and freeze and unfreeze the questionManager between launches.

Core Data?

Trail Wallet uses Core Data to manage its data and I am very happy with it. Xcode features a decent model editor and between NSPredicate, NSFetchRequest, and NSFetchedResultsController I get a lot of power and convenience for free, not to mention that persistence is straightforward.

I haven’t yet branched into iCloud for Trail Wallet, but it is something that I am eager to implement and (if it works well—which is a big "if", given iCloud Core Data’s history) then I’ll get a lot of syncing power for very little effort (as opposed to a third party solution, or even just having to manage mapping the model to CloudKit).

Implementing Core Data in this new app which, admittedly, is overkill for something so straightforward would allow me to try out iCloud Core Data with very little risk.

All user data loss is bad, but losing the history of which questions were answered seems a lot less catastrophic than years worth of financial records. I would also get some experience in managing migration paths when iCloud is in play before I implemented it in our most important app.

 


If you you enjoyed this, sign up to my mailing list to get my latest posts direct to your inbox.

Your email won't be shared and you can unsubscribe any time (the link’s at the bottom of every email).