Database Reference
In-Depth Information
that
NSManagedObjectContextWillSaveNotification
is being used to catch when an object
is deleted. When an object is deleted, the
NSFetchedResultsController
determines
whether it is relevant to our
NSFetchRequest
and issues the appropriate delegate
callbacks. This would typically result in a call to
-controller:didChangeSection:atIndex:
forChangeType:
if the deletion caused a section to disappear and/or a call to the
-controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:
with a change type
of
NSFetchedResultsChangeDelete
.
NSManagedObjectContextDidSaveNotification
The third and final
NSNotification
type is fired after the
NSManagedObjectContext
has
completed its save. This notification is observed so that the
NSFetchedResults
-
Controller
can capture any objects that are newly inserted or have been changed
in another context and propagated (as discussed in
Chapter 5,
Threading
, on
page 77
). This would typically result in a call to
-controller:didChangeSection:atIndex:
forChangeType:
if the insertion/update caused a section to disappear or appear.
It would also cause a call to
-controller: didChangeObject: atIndexPath: forChangeType:
newIndexPath:
with any of the change types available.
Beyond listening for these notifications, the
NSFetchedResultsController
is just a
container. The cache is most likely a serialization of the currently fetched
objects (although I have not been able to figure out its exact data structure
yet).
Why is this information valuable? For one, it is always helpful to understand
how things work so that when they stop working, we can investigate them
and resolve the issue. In addition, since the
NSFetchedResultsController
has such
an extremely narrow focus, we don't want to use it in situations where we
don't have a
UITableView
to populate. However, it is so useful that we really
want to use some of its features outside of this narrow focus. With an
understanding of how it works comes the ability to duplicate the features
that are useful to us.
2.3
Building Our Own: ZSContextWatcher
Since the introduction of the
NSFetchedResultsController
, I have run into numerous
situations in which I wanted to use its ability to detect data changes even
when I was not using a
UITableView
. Frequently I would attempt to use an
NSFetchedResultsController
and run into one problem or another that made it more
difficult than it needed to be. This led me to investigate how the
NSFetched
-
ResultsController
worked and finally resulted in the creation of the
ZSContextWatcher
.
