Database Reference
In-Depth Information
On the second launch,
NSFetchedResultsController
reads directly from your cache.
This saves a round trip to Core Data's persistent store, as well as the time needed
to compute those sections. Hooray!
Note: You'll learn about measuring performance and seeing if your code
changes really did make things faster in Chapter 9, “Measuring and Boosting
Performance”.
In your own apps, consider using
NSFetchedResultsController
's cache if you're
grouping results into sections and either have a very large data set or are targeting
older devices.
Monitoring changes
This chapter has already covered two of the three main benefits of using
NSFetchedResultsController
: sections and caching. The third and last benefit is
somewhat of a double-edged sword: it is powerful but also easy to misuse.
Earlier in the chapter, when you implemented the tap to increment the number of
wins, you added a line of code to reload the table view to show the updated score.
This was a brute force solution, but it worked.
Sure, you could have reloaded only the selected cell by being smart about the
UITableView
API, but that wouldn't have solved the root problem.
Not to get too philosophical, but the root problem is
change
. Something changed in
the underlying data and you had to be explicit about reloading the user interface.
Imagine for a moment what a second version of the World Cup app would look like.
Maybe there's a detail screen for every team where you can change the score.
Maybe the app calls an API endpoint and gets new score information from the web
service. It would be your job to refresh the table view
for every code path
that
updates the underlying data.
Doing it explicitly is error-prone, not to mention a little boring. Isn't there a better
way? Yes, there is. Once again, fetched results controller comes to the rescue.
NSFetchedResultsController
can listen for changes in its result set and notify its
delegate,
NSFetchedResultsControllerDelegate
. You can use this delegate to refresh
the table view as needed any time the underlying data changes.
What does it mean that a fetched results controller can monitor changes in its
“result set”? It means that it can monitor changes in all objects, old and new, that
it
would
have fetched, in addition to objects it has already fetched. This distinction
will become clearer later in this section.
Let's see this in practice. Make the following change to the class declaration:
