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.
A reader writes:
I just followed your instructions at http://www.mlsite.net/blog/?p=323 to modify the iPhone CoreData tutorial to use
NSFetchedResultsControllerbut am having a small problem.
I changed the
tableView:commitEditingStyle:forRowAtIndexPath:code and I added the delegate methods for
NSFetchedResultsController. I also added
NSFetchedResultsControllerDelegateto 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?
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.
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.)