Database Reference
In-Depth Information
As for how the Wenderland flag made it into the app: Hey, we're developers! We
need to plan for all kinds of possibilities. ;]
Where to go from here?
You've seen how powerful and useful
NSFetchedResultsController
can be, and
you've learned how well it works together with a table view. Table views are so
common in iOS apps and you've seen first hand how the fetched results controller
can save you a lot of time and code!
With some adaptation to the delegate methods, you can also use a fetched results
controller to drive a collection view—the main difference being that collection views
don't bracket their updates with begin and end calls, so it's necessary to store up
the changes and apply them all in a batch at the end.
There are a few things you should bear in mind before using fetched results
controllers in other contexts. They're not designed as general Core Data monitoring
tools—there are other notifications or techniques that probably do the job better.
Be mindful of how you implement the fetched results controller delegate methods.
Even the slightest change in the underlying data will fire those change notifications,
so avoid performing any expensive operations that you're not comfortable
performing over and over.
It's not every day that a single class gets an entire chapter in a book; that honor is
reserved for the select few.
NSFetchedResultsController
is one of them. As you've
seen in this chapter, the reason this class exists is to save you time.
NSFetchedResultsController
is important for another reason: it fills a gap that iOS
developers have faced compared to their OS X developer counterparts. OS X has
Cocoa bindings, which provide a way to tightly couple a view with its underlying
data model. Sound familiar?
If you ever find yourself writing complex logic to compute sections or breaking a
sweat trying to get your table view to play nicely with Core Data says, think back to
this chapter!
