Chapter 4, part two

The rest of the chapter covers fetch requests, sort descriptors and the managed object context.

Section 4.2: NSFetchRequest

An NSFetchRequest loads managed objects from the persistent store, putting them into an NSArray for your software to examine or manipulate. Now that I’ve seen how they’re used, I’ve started using them myself in my BugTracker application, making sure that required objects are added to new files, or seeing if a given object currently exists. One powerful attribute of the fetch request is that you can set a predicate, and select only the objects you need.

Fetch requests can be made in code, or directly in the data model. To create a request in the data model, select the menu item Design→Data Model→Add Fetch Request. This stored request can be accessed through the NSManagedObjectModel, and then executed just like any other fetch request.

The example fetch request for Grokking Recipes is -bigMeals, which looks for recipes that serve 10 or more.

Section 4.3: NSSortDescriptor

The NSSortDescriptor class predates Core Data, but is commonly used with Core Data. It allows a fetch request to return an NSArray of objects, sorted by the array of sort descriptors that were added to the request.

Section 4.4: NSManagedObjectContext

NSManagedObjectContext is the most-accessed object in Core Date, with the exception of NSManagedObject (the class that holds all the data we’re using). Zarra emphasizes that NSManagedObjectContext isn’t thread safe. Multi-threading gets a chapter of its own towards the end of the book, so we’ll be revisiting this topic later on.

This chapter adds a bit of code to the application delegate’s standard -managedObjectContext method that the template provides. Tha application’s persistent store has a list of recipe types, and it needs to start out with a default set the first time the application runs. For a non-document based application, the -managedObjectContext is a good place to put the code to detect the presence or absence of the required recipe types.

If the MOC doesn’t yet exist, the delegate has to create and initialize it. This requires a persistentStoreCoordinator, so if it doesn’t yet exist, it needs to be created as well. With the coordinator available, the method then creates a new MOC, sets it as the MOC for the coordinator, and then requests any Type entities the store has. If there aren’t any, the application delegate loads the recipe types from the main bundle’s infoDictionary, adds them to the newly-created MOC, and then returns the MOC to the method’s caller.

This chapter wraps up version 1 of Grokking Recipes: chapter 5 is about versioning and migration, which showed me to upgrade my BugTracker application files to when I added a version field to the bug data.

This entry was posted in Core Data. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s