Sync Table View Data: NSFetchedResultsController and Swift

Updated on September 23, 2015 – Swift 2.0

My goal with this article is to help you utilize the full power of NSFetchedResultsController.

This is a continuation on a series of articles I’ve written on Core Data and NSFetchedResultsController, so you may want to check out those previous posts to get an idea of where I’m picking up in this walk-through. Previously I touched on how to seed a Core Data database, and how to take that data and display it in a table view with an NSFetchedResultsController.

As with the previous posts, I’m providing an example XCode project over at GitHub, so feel free to follow along with the live working example:

In this installment to the series, I want to answer the question, “How do I update the rows in a table view when I add or remove objects from the Core Data database?” I will show how to implement the NSFetchedResultsControllerDelegate protocol, which is the key to automatically synchronizing changes made to your Core Data persistent store with a table view.

Examining the NSFetchedResultsControllerDelegate protocol

The NSFetchedResultsControllerDelegate protocol is the piece of the puzzle that helps us update a table view with changes made to the Core Data persistent store. There are five methods that we’ll be taking a look at:

  • controllerWillChangeContent(_:)
  • controller(_:didChangeObject:atIndexPath:forChangeType:newIndexPath:)
  • controller(_:didChangeSection:atIndex:forChangeType:)
  • controller(_:sectionIndexTitleForSectionName:)
  • controllerDidChangeContent(_:)

The two methods that are responsible for doing the actual updates to the table view’s structure are controller(_:didChangeSection:atIndex:forChangeType:) and controller(_:didChangeObject:atIndexPath:forChangeType:newIndexPath:). If some of the changes to the table view result in new sections being created, controller(_:sectionIndexTitleForSectionName:) will help give it an appropriate title (and make sure the other sections keep their appropriate titles as well).

controllerWillChangeContent(_:) and controllerDidChangeContent(_:) help inform the table view that changes are about to happen / just finished happening. Sandwiching the primary “didChangeObject” and “didChangeSection” protocol methods with these two methods allows the table view to animate in all of the changes to its structure in one batch.

So, the general structure of the NSFetchedResultsControllerDelegate section of your source file might look like this:

controller(_:didChangeObject:atIndexPath:forChangeType:newIndexPath:)

This is the method that governs how we want to handle the rows in a table view when the synchronization would require inserting rows, updating existing ones, removing them, or reordering them.

I’ll give you the implementation and then point out a couple of “gotchas” and expound a little more. Recall that we’re working with a sample app named “Zootastic”, so if you see references to Animals in the example, you’ll know why. :]

Right away you’ll notice we enter a switch on the type parameter of the method. There are four options possible in the NSFetchedResultsChangeType enum: Insert, Delete, Update, and Move.

Beware of a few common gotchas with each case of the switch:

  1. First of all, notice that first argument of the majority of the tableView methods takes an array of NSIndexPaths. Be sure to wrap your argument in [ and ] to create an array.
  2. Pay extra attention to which index path parameter you’re referencing in each case. For insert, the goal is to add a row at the newIndexPath. For Delete, the goal is to remove the row at indexPath. Move will require a deletion of the indexPath and an insertion at the newIndexPath. Getting these mixed up will cause runtime errors, so pay close attention here!

controller(_:didChangeSection:atIndex:forChangeType:)

If your table view only has one section, you don’t need to worry with this one.

If your table view has multiple sections, you want to make sure and implement this protocol method – if you fail to do so and the change to the persistent store results in adjustments to the table view that can’t be handled, runtime errors can occur. For example, deleting all rows in a section would result in the section needing to be deleted as well, but without this protocol method being implemented, the update to the table view can’t be made and the app crashes.

Once again, I’ll throw the code your way and follow up with commentary:

For this one, we’re only implementing code for Insert and Delete. The necessary information to insert a section or remove a section (ie, the sectionIndex) comes as a parameter to the method.

We utilize an NSIndexSet to wrap up the section that needs to be inserted or deleted and pass it to the table view’s insertSections() and deleteSections() methods, respectively.