NSFetchedResultsController on Andrew Bancroft

Sync Table View Data: NSFetchedResultsController and Swift

Fri, 29 May 2015 03:20:54 +0000

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:

Resources

Sync Table View Example Project

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:

 1// MARK: NSFetchedResultsControllerDelegate methods
 2public func controllerWillChangeContent(controller: NSFetchedResultsController) {
 3    self.tableView.beginUpdates()
 4}
 5
 6public func controller(
 7    controller: NSFetchedResultsController,
 8    didChangeObject anObject: AnyObject,
 9    atIndexPath indexPath: NSIndexPath?,
10    forChangeType type: NSFetchedResultsChangeType,
11    newIndexPath: NSIndexPath?) {
12        
13        // implementation to follow...
14}
15
16public func controller(
17    controller: NSFetchedResultsController,
18    didChangeSection sectionInfo: NSFetchedResultsSectionInfo,
19    atIndex sectionIndex: Int,
20    forChangeType type: NSFetchedResultsChangeType) {
21    
22        // implementation to follow...
23}
24
25public func controller(controller: NSFetchedResultsController, sectionIndexTitleForSectionName sectionName: String) -> String? {
26    return sectionName
27}
28
29public func controllerDidChangeContent(controller: NSFetchedResultsController) {
30    self.tableView.endUpdates()
31}

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. :]

 1public func controller(
 2        controller: NSFetchedResultsController,
 3        didChangeObject anObject: AnyObject,
 4        atIndexPath indexPath: NSIndexPath?,
 5        forChangeType type: NSFetchedResultsChangeType,
 6        newIndexPath: NSIndexPath?) {
 7            
 8            switch type {
 9            case NSFetchedResultsChangeType.Insert:
10                // Note that for Insert, we insert a row at the __newIndexPath__
11                if let insertIndexPath = newIndexPath {
12                    self.tableView.insertRowsAtIndexPaths([insertIndexPath], withRowAnimation: UITableViewRowAnimation.Fade)
13                }
14            case NSFetchedResultsChangeType.Delete:
15                // Note that for Delete, we delete the row at __indexPath__
16                if let deleteIndexPath = indexPath {
17                    self.tableView.deleteRowsAtIndexPaths([deleteIndexPath], withRowAnimation: UITableViewRowAnimation.Fade)
18                }
19            case NSFetchedResultsChangeType.Update:
20                if let updateIndexPath = indexPath {
21                    // Note that for Update, we update the row at __indexPath__
22                    let cell = self.tableView.cellForRowAtIndexPath(updateIndexPath)
23                    let animal = self.fetchedResultsController.objectAtIndexPath(updateIndexPath) as? Animal
24                    
25                    cell?.textLabel?.text = animal?.commonName
26                    cell?.detailTextLabel?.text = animal?.habitat
27                }
28            case NSFetchedResultsChangeType.Move:
29                // Note that for Move, we delete the row at __indexPath__
30                if let deleteIndexPath = indexPath {
31                    self.tableView.deleteRowsAtIndexPaths([deleteIndexPath], withRowAnimation: UITableViewRowAnimation.Fade)
32                }
33                
34                // Note that for Move, we insert a row at the __newIndexPath__
35                if let insertIndexPath = newIndexPath {
36                    self.tableView.insertRowsAtIndexPaths([insertIndexPath], withRowAnimation: UITableViewRowAnimation.Fade)
37                }
38            }
39}

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:

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.
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:

 1public func controller(
 2    controller: NSFetchedResultsController,
 3    didChangeSection sectionInfo: NSFetchedResultsSectionInfo,
 4    atIndex sectionIndex: Int,
 5    forChangeType type: NSFetchedResultsChangeType) {
 6    
 7        switch type {
 8        case .Insert:
 9            let sectionIndexSet = NSIndexSet(index: sectionIndex)
10            self.tableView.insertSections(sectionIndexSet, withRowAnimation: UITableViewRowAnimation.Fade)
11        case .Delete:
12            let sectionIndexSet = NSIndexSet(index: sectionIndex)
13            self.tableView.deleteSections(sectionIndexSet, withRowAnimation: UITableViewRowAnimation.Fade)
14        default:
15            ""
16        }
17}
18
19public func controller(controller: NSFetchedResultsController, sectionIndexTitleForSectionName sectionName: String?) -> String? {
20    return sectionName
21}

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.

Displaying Data With NSFetchedResultsController and Swift

Thu, 05 Mar 2015 15:14:53 +0000

The combination of an NSFetchedResultsController and a UITableView provides a powerful way to integrate Core Data with a user interface. The greatest benefits of using NSFetchedResultsController come when we use it to automatically update a table view when objects are added, updated, or removed from a Core Data data store. First things first, though…

With a Core Data data store seeded with data, the next logical step is to display that data somewhere other than the console. This post will be devoted to figuring out how to set up an NSFetchedResultsController to display data inside a UITableView.

A follow-up post has been published to help you keep the table view in sync with the data as it changes in your persistent store, so once you’re finished here, you might check out that next step!

Final goal

NSFetchedResultsController will help us accomplish two things:

It will fetch data from the Core Data data store
It will use some of the data we fetch to populate various pieces of the UI (table view section headers, cell “title” and “subtitle” text. Here’s what we’re going for:

Setup and resources

I’m continuing my “Zootastic” example that I used to write about using Swift to seed a Core Data database. In fact, I’ve simply branched the project on GibHub and added the things we’re exploring in this post.

Resources

Example Xcode Project

For this entry, we’ll still be dealing with our three primary NSManagedObject subclasses: Zoo, Animal, And Classification:

Storyboard

Zootastic is a single view application. The Storyboard contains one view controller with a table view filling the Scene.

The table view is using one prototype cell with an Identifier of “Cell” (for simplicity). The Style of the prototype cell is set to Subtitle.

MainViewController.swift

MainViewController.swift is where the action is happening. Here’s a quick outline of what we need to accomplish in this class:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

    // maintain a reference to NSManagedObjectContext instance

    // create and configure an NSFetchedResultsController instance

    // Implement UITableViewDataSource methods
}

As you can see, MainViewController is a class concerned with being the table view’s data source and delegate. Additionally, it will serve as the NSFetchedResultsControllerDelegate. For this post, we won’t actually need the fetched results controller delegate functionality to display data. Those methods are particularly useful for synchronizing things when data changes.

With the class declaration out of the way, we’ll investigate the class implementation one section at a time.

Maintain NSManagedObjectContext instance reference

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {
    
    public var context: NSManagedObjectContext!

    // ...
}

You may be asking, “Where will you set this NSManagedObjectContext reference?”. I’m employing a pattern that I’ve found successful in the past: I assign it when the finishes launching through the AppDelegate’s application:didFinishLaunchingWithOptions method. More on this, shortly…

For now, know that we’re counting on that later step to take place, since context is defined as an implicitly unwrapped optional.

Create and configure NSFetchedResultsController instance

Next, we need to create and configure an NSFetchedResultsController instance. Here’s a bit of code with comments to follow:

 2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

                        If you’ve not read  1 language-swift" data-lang="swift">public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

// ...

lazy var fetchedResultsController: NSFetchedResultsController = { let animalsFetchRequest = NSFetchRequest(entityName: "Animal") let primarySortDescriptor = NSSortDescriptor(key: "classification.order", ascending: true) let secondarySortDescriptor = NSSortDescriptor(key: "commonName", ascending: true) animalsFetchRequest.sortDescriptors = [primarySortDescriptor, secondarySortDescriptor]

let frc = NSFetchedResultsController( fetchRequest: animalsFetchRequest, managedObjectContext: self.context, sectionNameKeyPath: "classification.order", cacheName: nil)

frc.delegate = self

return frc }()

// ... class="p">}

rhardt">Colin Eberhardt’s Swift Initialization and the Pain of Optionals post, I highly recommend it. His post is a fantastic analysis, and the final option of using lazy stored properties initialized by a closure expression is what I’ve chosen to do here. I won’t repeat his analysis here, so feel free to jump over to his post to figure out what’s going on there.

Within the closure expression, I’m setting up a fetch request with some sorting applied. All that’s left is to initialize the NSFetchedResultsController, set its delegate and return it.

viewDidLoad()

Once the view has loaded, the idea is to perform the NSFetchedResultsController instance’s fetch request so that it has data to use in our UITableViewDataSource methods. This is how to do it:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

    // ...

    override public func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view, typically from a nib.

            do {
                try fetchedResultsController.performFetch()
            } catch {
                print("An error occurred")
            }
    }

    // ...

}

UITableViewDataSource methods

The final step in implementing MainViewController is to set up the table view so that it pulls data from fetchedResultsController. I’m implementing the standard UITableViewDataSource methods here, along with tableView:titleForHeaderInSection. Take a look:

public class MainViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, NSFetchedResultsControllerDelegate {

    // ...

    // MARK: TableView Data Source
    public func numberOfSectionsInTableView(tableView: UITableView) -> Int {
        if let sections = fetchedResultsController.sections {
            return sections.count
        }
        
        return 0
    }
    
    public func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        if let sections = fetchedResultsController.sections {
            let currentSection = sections[section] 
            return currentSection.numberOfObjects
        }
        
        return 0
    }
    
    public func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCellWithIdentifier("Cell", forIndexPath: indexPath) 
        let animal = fetchedResultsController.objectAtIndexPath(indexPath) as! Animal
        
        cell.textLabel?.text = animal.commonName
        cell.detailTextLabel?.text = animal.habitat
        
        return cell
    }
    
    public func tableView(tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
        if let sections = fetchedResultsController.sections {
            let currentSection = sections[section] 
            return currentSection.name
        }
        
        return nil
    }

    // ...

}

Apart from a bit of if let ___ = ___ syntax, there’s not an awful lot of surprising code here if you’re familiar with working with table views. I’ve highlighted the relevant code related to fetchedResultsController. Without using NSFetchedResultsController, you’d probably supply data to the table view from an array or a dictionary or both. The fetchedResultsController code simplifies the data display dilemma when you’re using Core Data.

Once the UITableViewDataSource methods are implemented, the implementation of MainViewController is complete for this example.

AppDelegate.swift

There’s one final thing we need to do in order to get things rolling. In the “maintain NSManagedObjectContext instance reference” section of this post, I mentioned the strategy for assigning the NSManagedObjectContext instance in the MainViewController. Here’s how I do it:

class AppDelegate: UIResponder, UIApplicationDelegate {

    // ...


    func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
        // Override point for customization after application launch.
        
        let dataHelper = DataHelper(context: self.managedObjectContext)
        dataHelper.seedDataStore()
        
        dataHelper.printAllZoos()
        dataHelper.printAllClassifications()
        dataHelper.printAllAnimals()
        
        let rootViewController = self.window!.rootViewController as! MainViewController
        rootViewController.context = self.managedObjectContext;
        
        return true
    }

    // ...

}

Note: With iOS 13, the code to assign the managedObjectContext to the root view controller needs to go in your app’s SceneDelegate.

The portion new to “injecting” the managedObjectContext into MainViewController is highlighted. I simply grab a reference to the rootViewController (which in our example is the MainViewController) and cast it to the appropriate type. Then I set the context property to the managedObjectContext that’s created in the AppDelegate via Xcode’s auto-generated Core Data stack setup.

Wrapping up

If you’re using Core Data in your iOS application, the combination of an NSFetchedResultsController and a UITableView provides a powerful way to integrate data from your data store into your UI. We’ve explored how to display data in a table view using NSFetchedResultsController. Feel free to grab the GibHub project for further investigation and to see Zootastic in action.