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:
andtableView:commitEditingStyle:forRowAtIndexPath:
code and I added the delegate methods forNSFetchedResultsController
. I also addedNSFetchedResultsControllerDelegate
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.)