Question

After reading lots of documentation and examples of Core Data framework, I still don’t quite get it. What happens is that I sort of understand parts of a sample code or documentation, but often can’t fit it into a larger picture. The second time I read the same code, I still need lots of time to figure it out just like the first time. It’s so frustrating.

The NSFetchedResultsControllerDelegate vs NSFetchedResultsController is one of those concepts in Core Data that confuse me.

I think what I need is a simple and conceptual explanation, maybe analogy will be helpful.

Answer 1

All your core data objects have to be accessed via managed object context.

Think of NSFetchRequest as a representation of the database query. When you tell the NSManagedObjectContext (MOC) to fetch data, you give it a fetch request, so it knows what to fetch.

Now, let’s say you have a table view. You make a fetch, and have all the data, even for the stuff you don’t need to display. Each time the table view changes, and you need to refetch the data. There are a few other issues with just using a fetch request, though it can be done.

To solve some of these problems, enter NSFetchedResultsController (FRC). It manages the database so that you only have the objects in memory that are actually needed at the time. Furthermore, it hooks into the MOC so that when the database changes, it automatically changes its own data.

So, you create a FRC and give it a fetch request. Now, it manages the data so it only has in memory what you want. But, you need to tell it what to grab, and it need to tell you when it has data.

Thus is where the NSFetchedResultsControllerDelegate comes in.

The delegate is the glue between the table view (or some other component) and the FRC. The delegate methods are the communication channel that informs the FRC what data to get, when to get it, then hand it off to the table view.

EDIT

Yes, FRC manages the actual data part. However, when its data changes, it has to have some way to notify the guy who is watching the data. That’s what the delegate is for. Let’s take a different attack by looking at the delegate methods.

Imagine that the database has been changed in some way. The FRC, through its special magical incantations, has noticed the change, and, like a teenager with a new iPhone, needs to tell someone.

Specifically, again, in your case, it needs to tell the table view that is responsible for displaying the data to the user. Well, how is it going to tell the table view that the data has changed? There are actually several patterns used in iOS, and in this case, we use a delegate.

The guy who is interested in receiving this information from the FRC give him a pointer to an object that implements the delegate methods. When the FRC wants to notify the guy interested, it calls the appropriate methods on the object that is was given as the delegate.

Consider a change has happened. The FRC code would look something like this (ultra-simplified but to give the algorithmic idea).

[delegate controllerWillChangeContent:self];

// Process all the changes...

for (SectionChangeInfo *info in changedSections) {
    [delegate controller:self didChangeSection:info.sectionInfo atIndex:info.index forChangeType:info.changeType];
}

for (ObjectChangeInfo *info in changedObjects) {
    [delegate controller:self didChangeObject:info.object atIndexPath:info.indexPath forChangeType:info.changeType newIndexPath:index.newIndexPath];
}

[delegate controllerDidChangeContent:self];

Thus, the FRC can tell “somebody” about changes when they occur. In your case, when you give the FRC a delegate, it will call those methods, thus giving you a chance to handle the changes when they happen.

The other delegate method is called to ask the delegate what it wants to use as a section title. So, assume the FRC needs to know what to use, it will call…

NSString *sectionTitle = [[section substringToIndex:1] uppercase];
if ([delegate respondsToSelector:@selector(controller:sectionIndexTitleForSectionName:)]) {
    sectionTitle = [delegate controller:self sectionIndexTitleForSectionName:section];
}