Core Data, Part 1: An Introduction

In my last post I published SKDatabase, a more complete database library than we were able to offer in iPhone in Action. But, when I did, I noted that it was already obsolete, thanks to the inclusion of Core Data in iPhone OS 3.0. And that's the topic of this post. To complement the information that we offered in chapter 16 of iPhone in Action, covering lots of different ways to read and store data, I'll be writing about the new functionality of Core Data over the next several posts.

What Core Data Is

Core Data is an abstract data model. You'll generally interact only with the front end of Core Data, telling it what data to retrieve, what data to modify, and what data to save. Though you can define a specific type of storage to use (such as a database or an XML file), you are not required to, and generally you don't need to know the details of what sort of data storage is being used at all.

The object of Core Data is to free you from worries about anything but the data objects themselves, and though I find some of the terminology of Core Data a bit overly complex, once you get past that, the actual system has a lot to recommend it.

Core Data will, however, take some time to learn, and if you're just programming a one-time piece of software, and you don't have the time to learn a whole new system, then you might want to stick with something you already understand, such as one of the other methods we cover in chapter 16, or the expanded database library which I recently posted. But if you plan to do lots of iPhone programming involving data storage, then ... read on ...

Core Data's Three Main Concepts

Core Data centers around three main concepts (and two subconcepts). I find their names to be very intimidating, but once you get past them, they make sense as object-oriented data elements.

The Managed Object Model. Before you can do any data storage, you need to define what data you're  storing. The Managed Object Model is that definition. Under SQL, it'd be the structure of your tables: how many tables there are, how many columns each table has, and what data type each column uses. Under the Managed Object Model, tables become entities, columns become attributes, and relationships represent table joins ... but in general, they're the same things with fancy names.

By extension, a Managed Object is an individual data element.

The Persistent Storage Coordinator. This is what actually stores your data for you. It integrates your Managed Object Model (data structure) with your Persistent Store. The store itself, to do away with Apple's ten-dollar words, is simply the back-end that you're storing to. By default it's a SQLite database.

A Peristent Storage Coordinator can be a little fancier than this suggests. It can actually manage a number of different Persistent Stores, and make sure that you don't have to worry about which data elements are being stored where. But at the most basic level, you can just consider the Persistent Storage Coordinator to be the thing that turns your program's data into stored data.

The Managed Object Context. This is the one element in Core Data that doesn't have a simple correlation with the data work that you've already been doing. The Managed Object Context is like a whiteboard. It's a temporary storage area. You can pull things out of your Persistent Store and write them to the Context; from there you can directly access the data from your program. Likewise you can modify the data in the Context and you can write new data to it.

So how is the Managed Object Context separate from the Persistent Store? Most notably, it's temporary. Often times, you'll tell Core Data to save information to the Persistent Store (via the Persistent Storage Coordinator) as soon as you enter that data--but you could also use the Managed Object Context to store totally ephemeral information, without changing your startup date.

Go back and reread those definitions until you're comfortable with them. If you have them in hand, Core Data will be a lot less intimidating.

Getting Started

The easiest way to get started with Core Data is create a "New Project" that is a "Window-based Application". When you select the Window-based template, you should see a checkbox under options that says "Use Core Data for storage". If you check that, your new project will be all set up for Core Data.

When you look at your new project, you'll see that the AppDelegate's header file includes three properties: managedObjectModel, managedObjectContext, and persistentStoreCoordinator. These define the three elements that we've just been discussing. For many Core Data programs, you'll only need to deal with the managedObjectContext property.

You'll also see some standard method calls within the AppDelegate for managedObjectContext, managedObjectModel, and persistentStoreCoordinator. You probably won't have to mess with those at all, though do note that the last method is the one that sets a SQLite file as the default sort of Persistent Store.

Finally, in your "Resources" section (in the column to the left of Xcode), you should see a .xcdatamodel file. That's the file which contains the actual data structure for your project--or the Managed Object Model if you prefer. It's really easy to set up, thanks to a built-in Xcode UI, which will be the topic of the next article in this series.

Coming Next: Part 2: Designing the Data Model.

Comments

[Edgar Schmidt]

This is by far the clearest explanation to CoreData on the iPhone I've found so far. I really liked the analogies used to explain the components created by Apple.

Thanks! Keep up the good work.

[Beat Ito]

great read on Core Data, as i went through apple's "locations" tutorial I had a feeling most of the material was just apples re-wording of things that already exist, thanks for clarifying the apple jargon for us all! great work!

[BJ Miller]

Great clarification! I look forward to using it, after reading your post it seems less of a beast. Thanks!

[jeevanantham]

This clarification apparent to understand the basic structure of core data! Great article! Thank you!

[Eliza]

This is extremely helpful. Thank you for the clear explanation.