Okay, there is a known problem with NSFetchedResultsController when using section name key paths. When you make a change to an existing object that results in a new section being created, it crashes. The fetched results controller's delegate never gets notified of a section insert, nor does it get notified about the object moving between sections. It just gets notification that the object was updated.
I've been fighting with NSFetchedResultsController for quite some time now, but this afternoon, I think I made it my bitch. You can actually handle this situation, though it requires a bit of gnarley code. I'm going to update the Navigation-Based Core Data Application Xcode project template shortly with this logic, but here's how you handle this problem in the fetched results controller delegate methods. Specifically look at the NSFetchedResultsChangeUpdate case statement in controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:. There, we determine if the section name key path has changed, and if it has, we determine if we need to add a new section to the table. Then, we fall through tot he NSFetchedResultsChangeMove and follow the same logic.
One caveat, though, I don't know if this will work with section name key paths that use nested keys (e.g. "foo.bar"). In fact, I'm pretty sure it won't work, but I will look at fixing that a little later. For the vast majority of situations, this should patch up the section problem in NSFetchedResultsController pretty well.
The code has been fixed to support nested keys in the section name key path.
I've been fighting with NSFetchedResultsController for quite some time now, but this afternoon, I think I made it my bitch. You can actually handle this situation, though it requires a bit of gnarley code. I'm going to update the Navigation-Based Core Data Application Xcode project template shortly with this logic, but here's how you handle this problem in the fetched results controller delegate methods. Specifically look at the NSFetchedResultsChangeUpdate case statement in controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:. There, we determine if the section name key path has changed, and if it has, we determine if we need to add a new section to the table. Then, we fall through tot he NSFetchedResultsChangeMove and follow the same logic.
The code has been fixed to support nested keys in the section name key path.
- (void)controllerWillChangeContent:(NSFetchedResultsController *)controller
- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller
- (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type newIndexPath:(NSIndexPath *)newIndexPath
- (void)controller:(NSFetchedResultsController *)controller didChangeSection:( )sectionInfo atIndex:(NSUInteger)sectionIndex forChangeType:(NSFetchedResultsChangeType)type
0 comments:
Post a Comment