iOS: NSFetchedResultsController - Core Data - page 35

When we receive a notification, we need to check the -userInfo and see whether
there are any objects that we care about. In the -userInfo , there are up to three
NSSet instances: one for updated objects, one for deleted objects, and one for
inserted objects. We walk through each of these sets, grabbing a mutable
copy of each one, filtering the mutable set against our masterPredicate , and
keeping track of how many objects are left. If there are no objects left at the
end of the filtering, we know there were none in the save that we cared about,
and we can return.

If there were any objects left, we need to notify our delegate of them. Since
we have already filtered the objects, we may as well pass them to our delegate
so our delegate doesn't need to repeat the work. We create a new NSDictionary
and add each of our NSSet instances to it using the same keys that the
incoming NSNotification used. Once it is constructed, we can pass the newly
created NSDictionary off to our delegate.

Now we have a class that allows us to watch any NSManagedObjectContext of our
choosing and notifies us if an object that we care about has been touched in
any way. We can make the predicate as broad or narrow as we want. By
allowing the delegate to pass in the predicate, we've also made this class
highly reusable.

2.4 Wrapping Up

The NSFetchedResultsController is a great time-saver when we are working with a
UITableView . It can drastically reduce the amount of code we need to write and
make our UITableView instances perform very well. However, it has a narrowly
focused purpose, and it should be avoided when you are not working with a
UITableView . Fortunately, with a little bit of effort, we can duplicate quite a bit
of its functionality and create a highly flexible class that fits into a variety of
situations.