I am enjoying the Core Data by Tutorial and getting allot out of the book. Great guide for someone like me. I am a beginner with Core Data and have allot to learn. I have pasted a paragraph here from chapter 5, page 197. You say that other notifications or techniques might be better… Can you give some examples of other context you’re referring to? Can you expand on this paragraph?
“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.”
Excerpt From: By Pietro Rea. “Core Data by Tutorials.” iBooks.
@thomasg_peters. Thanks very much for your question! The first thing I would point out for NSFetchedResultsController is that it is meant to work with UITableViews, which is why the integration is so seamless, and is a big benefit of using Core Data. Once changes are made in your local store, those changes are then visible to the user via the UITableView. This functionality suffices for most users, so outside of this, you’d really have to have a very specific use case in terms of being notified of any changes to your local store within Core Data. Majority of cases, NSFetchedResultsController should do the job.
Now that being said, the other method of notification that one can use is of course, NSNotificationCenter. This class allows you to inform multiple parts of your app if necessary that a particular change has occurred somewhere else. The benefit here is that the relationship can be one to many: one event can alert multiple areas, so it can be quite powerful. When using delegates, as is the case here when using NSFetchedResultsController, the relationship is one to one. One event (inside Core Data) triggers one destination (the UITableView). As I pointed out, when using Core Data, it’s best to use the tools that it’s API comes with, because they are designed such that they would cover most use cases for your apps.