Question

I have a rather complex data source for my UITableView. I am very carefully keeping it in sync with the tableview itself, inserting and removing rows/sections manually (with animation) whenever some data changes, and vice versa.

It is hard to be 100% confident in my ability to keep these matched up. The effects of a mis-match between the view and the data can be severe – for example, selecting a row and trying to do something to the associated object, when that object does not exist, will cause a crash. Many other bugs would lead to less obvious errors (operating on the wrong object, for example).

I was thinking about how all of this goes away if I call reloadData after each data change instead of manually modifying the view. But then I would lose the animation.

So perhaps I could somehow call reloadData after my animations have ended, as a safety measure.

• Does this sound like a good idea? Any alternatives?
• Where would I place this call so that the reload only occurs after animation (and would thus be invisible to the user if all is well)?
• Is there anything I could do to compare the view before and after reloadData, to identify if anything changed on the screen and throw a warning, for debugging purposes? I expect this would only work on rows that are in view, since offscreen content is dequeued only when required.

Interested in your thoughts!

Answer 1

I feel your pain. Unfortunately, I don’t think that the reload idea helps much. If there’s a discrepancy between the model and the table view, in my experience the problem manifests as an exception before or during the update animations. If there’s a problem, I’ve found that you don’t make it to the reload, and I don’t think you want to.

These are some risk factors that, in my experience, lead to models prone to get out of synch with a table view:

• model count and model items that come from more complex calculations
  than simple array counts and array itemAtIndex:
• filters, like tabs that show a different aspect of the model in the same table based on which tab is selected
• search results controller and it’s tableView
• updates based on events that are triggered asynchronously
• heterogenous types in the model, with different cell types and sizes
• one clumsy word: FetchedResultsController
• and especially combinations of the above

This goes a little beyond table views, and, I don’t claim to be a perfect practitioner of all the preaching here, but I think the way to get confidence in your app includes the following:

1. Build the UI with no art and as little app logic as possible; just a
   mock version of the model – to the extent possible – equal in
   complexity but not in volume, to the real thing.

2. Build the model and app logic, along with tests that – to the extent
   possible – exercise it independently of the UI.

3. While you’re testing, embrace exceptions as your friend, telling you that you need a fix. Insert as little defensive code as you can for as long as possible.

My $0.02. Best of luck.