如何处理自定义结果视图的NSFetchedResultsControllerDelegate更新

Question

I am currently working on a CoreData based iPhone app with a map view that will have its annotations generated from an NSFetchedResultsController . The idea of the map view is that it will show a number of saved locations for the user.

One of the advantages of using an NSFetchedResultsController is that I can set my map view as a delegate on NSFetchedResultsController and get notified of any changes made to the set of saved locations that happen on another device or on a website when the user is logged in.

I am currently having a bit of trouble getting my head around how to deal with a number of different kinds of updates that are sent to my NSFetchedResultsControllerDelegate implementation. The documentation: http://developer.apple.com/library/ios/#documentation/CoreData/Reference/NSFetchedResultsControllerDelegate_Protocol/Reference/Reference.html doesn't seem to tell you how these different updates should be handled as it seems more geared towards integrating with a UITableView, which does most of the work.

I am keeping an NSDictionary of my annotations that maps them to the NSIndexPath inside the result set. The issue is, for example, when I receive 10 move, 3 insert and 4 delete updates, what order should I process these in? Some of these indexPaths will have a number of conflicting indices and the order in which they are processed will have an affect on the actual annotations I need to move, insert or delete. If I perform all the move updates first, then the insert indices will cause the final order to be different to their final order if I inserted first.

Are there any existing small libraries/classes that will translate a set of indices prior to an update to a set of post update indices given those update messages? If not, can anyone explain how this stuff works so I can write my own?

Any help will be greatly appreciated!

Answer 1

The flow of the NSFetchedResultsControllerDelegate methods for one update cycle is like this:

• controllerWillChangeContent: (called once)
• controller:didChangeObject:atIndexPath:forChangeType:newIndexPath: (called X times)
• controllerDidChangeContent: (called once)

Every call to the didChangeObject method will be about just one object / indexPath. You should apply the changes in the order that you receive them via those calls to didChangeObject. That will keep them consistent.

If you are using sections, you could also have calls to controller:didChangeSection:atIndex:forChangeType: intermixed with the object changed calls.