Question Time

Two things: First, you should really check out this article. It’s a comparison of the “Super Six” super middleweight (168lb) boxing tournament with the “Contender” TV series. It’s got some interesting things to say about the business of boxing.

Second, a reader wrote in with a question about NSFetchedResultControllers. Since he didn’t include a return address (one of the perils of using a contact form rather than a mailto: link) and since the question might be of general interest, I thought I’d answer it here.

Question

A reader writes:

I just followed your instructions at http://www.mlsite.net/blog/?p=323 to modify the iPhone CoreData tutorial to use NSFetchedResultsController but am having a small problem.

I changed the addEvent: and tableView:commitEditingStyle:forRowAtIndexPath: code and I added the delegate methods for NSFetchedResultsController. I also added NSFetchedResultsControllerDelegate to the RootViewController.h file.

The app runs but the delegate methods are not being called. This results in the persistent store being updated but the table view does not update as entries are added and deleted. When I restart the changes are evident.

Is there something else that I need to do to get the delegate methods to be called?

Answer

The most likely explanation is that the delegate property of the NSFetchedResultsController isn’t being set. Assuming that you’re still setting up the NSFetchedResultsController in a method of the RootViewController, you just need to add this line to your program:

controller.delegate = self;

after you create the controller. (I omitted this step from my original post because I’m lazy.) I hope this information is useful.

Coming Attractions

Although I doubt it’s relevant to this case, tomorrow we’ll look at a more exotic set of circumstances that can also cause NSFetchedResultsController delegate methods to go unfired. (Fortunately, these situations can be resolved satisfactorily.)