iOS Best practice for handling model objects

Question

There are different levels I'm asking this question at.

Case 1: Let's think about the typical drill-down design. Say a table view controller has an array of custom objects, and tapping a cell will push a view controller that allows the user to modify the object represented by the cell. In this case, should the pushed view controller have the custom object as a property of its own, or use a data source/delegate protocol to edit the custom object but not own it.

Case 2: A similar but slightly different situation is this. I'm using a singleton store to handle an array of bank accounts in my app. A view controller will show a list of the accounts, and I'm wondering if I should have the array of accounts as a property in my view controller or get the array via the store. (The array of accounts is accessed quite often.) I guess the only difference is a single object vs. an array of objects. I'm curious about how heavy these arrays can be, so whether it's faster to load the array from the store each time or have it as a property in the view controller.

Case 3: When should the local file system be used? In my app's example, bank accounts are accessed quite often, so I have them unarchived and set as properties upon launching the app, but for much bigger data, I only load them from the file system when they should be displayed or edited. I'm still not sure what the right way is.

Answer 1

In case 1, you should probably use the store and/or some kind of Data Manager. The reason to this is that 1) it shouldn't be the ViewController's responsibility to change the data, and if you build it into the VC, you would have to change a bunch of them to change the functionality.

There's also the issue of copying data around. When you're working with copies, you don't know what's going on with the original, and you're not making changes in real-time.

Same goes for case 2. The controller only displays the data, ideally the true reperentation of the data, not a copy.

If loading speed is an issue, you could split up your database to be able to load only the data you need (if you can), and you can also cache data that is used often.

In case 3, you can also cache the data, keeping in mind to track any changes that might happen in between caching and using the data. Caching is better that simply storing because your app won't take up a lot of space on the user's device.

UX/UI design elements like spinners/activity indicators go a long way in making the app feel more responsive.

Answer 2

Essentially you have the following limits

• Memory in use

  If you have a huge long list of objects, you probably dont want to copy their data around. Pass references to your datasource and load only the ones you need rather than the whole list.

• Loading time

  If your data takes a long time to load, maybe you get it from the internet, or possibly the file system. Load the data in the background and cache the frequently used data in memory so you can hide the long load time from the user.

• Editing

  If your view edits the data, then you are going to need a copy of the data. In order to handle storing both the unedited copy (in case of cancellation or validation errors) and the edited version of the model prior to 'saving'.

• Drawing the UI

  If you have many, or complex elements to draw and populate, such as a large grid, you may need to optimise this via pagination or reuse of elements which are scrolled. Although you will probably find this is already built into standard controls.