This is the third and final part of a series to help get you up to speed with the basics of Core Data quickly.

In the first part of the Core Data tutorial series, we created a visual data model for our objects, ran a quick and dirty test to make sure it works, and hooked it up to a table view so we could see a list of our objects.

In this part of the series, we’re going to discuss how we can optimize our app by using NSFetchedResultsController, to reduce memory overhead and improve response time.

(You’re going to need access to the project we did in part 2. If you need a fresh copy, you can download it here.)

Why Use NSFetchedResultsController?

So far, we’re at exactly the same point we were using the SQLite3 method. However, we didn’t have to write nearly as much code (notice the absence of a FailedBankDatabase class constructing raw SQL statements), and adding other functionality such as insert/delete operations would be much simpler.

However, there’s one notable thing that we could add pretty easily with Core Data that could give us huge benefits to performance: use NSFetchedResultsController.

Right now we’re loading all of the FailedBankInfo objects from the database into memory at once. That might be fine for this app, but the more data we have the slower this will be, and could have a detrimental impact to the user.

Ideally we’d like to load only a subset of the rows, based on what the user is currently looking at in the table view. Luckily, Apple has made this easy for us by providing a great utility class called NSFetchedResultsController.

So, start by opening up FBCDMasterViewController.h, removing out our old NSArray of failedBankInfos, and adding a new NSFetchedResultsController instead:

In the synthesize section in FBCDMasterViewController.m, remove old failedBankInfos synthesize statement and add:

@synthesize fetchedResultsController = _fetchedResultsController;

Another awesome thing about NSFetchedResultsController is you an set it to nil upon viewDidUnload, which means that all of the data that is in memory can be freed up in low memory conditions (and the view is offscreen). All you have to do is set it to null in viewDidUnload (and make sure it’s re-initialized in viewDidLoad):

-(void)viewDidUnload {
self.fetchedResultsController =nil;
}

Ok, now onto the fun part – creating our fetched results controller! We are going to override the get method for our property so that it checks to see if the fetched results controller exists first. If it does exist, it will return it, otherwise it will create it.

This should look pretty familiar to the code that we used to have in viewDidLoad, to create a fetch request to pull out the FailedBankInfo objects. However, there’s a lot of new stuff here so let’s discuss…

First, any time we use an NSFetchedResultsController, we need to set a sort descriptor on the fetch request. A sort descriptor is just a fancy term for an object we set up to tell Core Data how we want our results sorted.

The cool thing about sort descriptors is they are very powerful. Not only can you sort on any property of the object you are returning, but you can sort on properties of related objects – just like we see here! We want to sort the objects based on the close date in the FailedBankDetails, but still only receive the data in FailedBankInfo – and Core Data can do this!

A very important part is the next statement – to set the batch size on the fetch request to some small size. In fact, this is the very reason we want to use the fetched results controller in this case. This way, the fetched results controller will only retrieve a subset of objects at a time from the underlying database, and automatically fetch mroe as we scroll.

So once we finish tweaking the fetch request with the sort descriptor and batch size, we just create a NSFetchedRequestController and pass in the fetch request. Note it takes a few other parameters too:

For the managed object context, we just pass in our context.

The section name key path lets us sort the data into sections in our table view. We could sort the banks by State if we wanted to, for example, here.

The cacheName the name of the file the fetched results controller should use to cache any repeat work such as setting up sections and ordering contents.

So now that we have a method to return a fetched results controller, let’s modify our class to use it rather than our old array method. First, update viewDidLoad as follows:

Note we split out part of the logic into a separate configureCell method – this is because we’ll need it later.

Ok one more thing – we need to implement the delegate methods for the NSFetchedResultsController. The good news is these are mostly boilerplate – I literally copied and pasted these from an Apple sample. So just add these methods to the bottom of your file:

You can see here that behind the scenes, the NSFetchedResultsController is getting a list of IDs from FailedBankInfo, in the proper sort order. Then, as the user pages through the table, it loads one batch at a time – rather than loading all of the objects into memory at once!

This would have been a lot more code to do with raw SQLite – and is just one of the many reasons why using Core Data can save time and increase performance.

Show Me The Code!

Where to Go From Here?

You should have a good understanding of the basics of Core Data at this point. A good exercise would be to continue this example to add in the detail view that we created in the SQLite tutorial, or to add in support for adding/editing/deleting items.

I’d recommend also taking a look at some of the Apple samples out there – they have 5 different Core Data examples currently available and they all show different and interesting aspects of things you can do.

Also, if you have any advice about Core Data or gotchas that you’ve encountered with Core Data in your projects, please share!

Adam Burkepile is currently a full-time Software Consultant and independent iOS developer. If he isn’t at the computer, he’s probably getting punched in the face at Krav Maga. Check out his latest app – Pocket No Agenda. You can reach him for work or just to chat at Twitter, Github, his website, or email.

Nifty tutorial! When would I have to worry about the size of the fetched IDs in the first underlying query ever, e.g. if I wanted this automatic pagination on a table of tens of thousands of rows? I imagine at some point a simple NSFetchRequest that without any fetchLimit, even that first request for just IDs could be too much, no?

Nice Tutorial there. I downloaded the sample project and just tried changing the textures and it does not work; It works only with the textures you have included; If I use bigger textures, it just draws in black; any clue on what might be wrong?

Hi,
Thank you for your helpful tutorial.
I have problem when running the code from the 2nd time (even when I run the downloaded project). The app crash at line: if (![[self fetchedResultsController] performFetch:&error])
Message:
CoreData: FATAL ERROR: The persistent cache of section information does not match the current configuration. You have illegally mutated the NSFetchedResultsController's fetch request, its predicate, or its sort descriptor without either disabling caching or using +deleteCacheWithName:
Can you help me with this

Solidath in an earlier post wrote:
2. A problem arises when we run the app first time, then close it and rerun. We get the following:
"FATAL ERROR: The persistent cache of section information does not match the current configuration."

The cache seems to be NOT purged. Changing the cacheName:@"Root" to cacheName:nil solves it.

Can we configure NSFetchResultController to work with UIPickerViewController.
Any help appreciated.

Most of the examples for using NSFetchedResultController involve a table view. However, the data source methods used by a picker view to determine content are very similar to those used for a table view.