Home > 2010 Fall DPS913 > Core Data introduction for new iOS programmers

Core Data introduction for new iOS programmers

October 14, 2010 Leave a comment Go to comments

Core Data is an object management and persistence framework. It helps you manage the lifecycle of objects and object graphs. Core Data provides classes that are abstractions for common operations, including retrieve, create, delete, and update.


The Core Data Overview states the following important point:

Core Data is not an entry-level technology. It leverages many other Cocoa technologies and design patterns. You must understand [a number] of technologies and patterns before you can use Core Data effectively.

Is it difficult to learn? No, it is not. If you have the foundational knowledge and experience, you will find that Core Data is an elegant way to provide object lifecycle and persistence management.


Locating help documentation

Apple publishes a number of good-quality documents that we will use. We will also use the course notes (blog posts). To get started, I will suggest the following resources:

This blog post

Getting Started With Core Data

Technology Overview, and Core Data Basics, from the Core Data Programming Guide

“Reference Card” handouts

Careful study of the “CD Intro” example app (it is well-commented)

Next week’s blog post

Careful study of next week’s “CD Complete” example app (it too is well-commented)


Checkpoint: Where are we? What do we know?

At this point, your professor suggests that you pause and think about where you are in your learning path, and also about what you know about iOS programming. Specifically, think about the progress that you’ve made in three topic areas:

  1. Model objects (data)
  2. App styles
  3. Table views


Model objects (data):

  • You have been using model objects from the beginning of the course
  • Some model objects have been really simple – strings and so on
  • You then learned about and used arrays and dictionaries as model objects
  • And, you created (or learned to create) model objects of your own design

Now, you’re ready to use Core Data to manage and persist your model objects.


App styles:

  • Your first apps used a single view (+ view controller)
  • Then, you added the ability to show modal views on this style of app
  • We then introduced apps that support multiple views, in a tab bar, or navigation-based style

We will continue to use multiple views, typically in a navigation-based style, in apps that use Core Data.


Table views

  • In your first table view example, you saw that it used an array data source, and the array was created when the program launched
  • Then, we moved on to apps that used arrays that were persisted, typically in a plist
  • Finally, we were able to support multiple levels of navigation by using a carefully-structured dictionary as the data source, and dictionary methods that generated arrays

We will build on that understanding, by supporting table view editing operations, and by using Core Data as the persistent store.


Core Data introduction

Some authors and reference resources like to compare Core Data concepts and operations with traditional database concepts and operations. We will NOT do that here.

Your professor believes that you shouldn’t strongly link and/or compare the two technologies, even though you are tempted to do so. Instead, you should learn the fundamental Core Data concepts, and if you have to make comparisons to aid your understanding, then you can do so on your own.

The task here will be to provide a high-level overview of Core Data, so you can use it in the right way.


Data model

First, we start with a “data model”. It models the real-world entities that you want to work with. An entity has attributes and relationships. A “Student” entity, for example, would have attributes for name, student ID number, and so on. A student may have multiple addresses (e.g. mailing, residence, etc.), so we may also have an “Address” entity. There would be a relationship between “Student” and “Address”, maybe one-to-many. In a “Student” object, this relationship is realized as a property, perhaps named “Addresses”, which is a collection of “Address” objects.

So far, you may be thinking that an entity is the same as an object of our own design. Well, it’s almost the same. An object of your own design is a subclass of NSObject. An entity object is a subclass of NSManagedObject, and is usually known as a “managed object”. But they’re fairly similar. Both model something in real life.


Persistent store

Your objects are stored in a persistent store. The format and structure of the store shouldn’t really matter to you. (Does the format and structure of an “archive” matter to you? Didn’t think so.) The store is located in the app’s “Documents” directory, in a named file.

At this point, we’ve covered two components – the data model, and the persistent store. You understand both of them. Next, you’ll learn about a new concept.



An app that uses Core Data has an object called a context. (It gets created in the app delegate when the app launches.) The context is a “work area”. You can also think of it as a scratch pad or a white board.

What do we put in a context? One or more “managed objects”. In a well-designed app, the context object is available to all of the classes (typically view controllers etc.) that need to work with managed objects.

How do we add a managed object to a context? There are typically three ways:

  1. We fetch some objects from the persistent store; think of these as results from a query
  2. We modify one (or more) of these objects, perhaps by changing an attribute value
  3. We add a new object, which will (eventually) be persisted in the store

As a “work area”, the context is pretty useful. Fetch results are automatically placed in the context. We can ask the context to save changes. And, we can perform other typical data and object management operations.



Let’s explore the task of fetching objects from the persistent store. Core Data has a “fetch” object (NSFetchRequest), which gets configured (by you) with fetch settings, typically in a view controller. For example, what entity do you want to fetch? Should all of the entity objects be fetched, or just a filtered subset? Should the fetch results be sorted/sequenced in some way?

At this point, you may be thinking that a fetch object is similar to a query. You would be correct.

A fetch object gets configured with the name of the entity that you want to fetch. Optionally, the fetch object can be configured with a predicate, to filter the selection. It can also be configured with one or more sort descriptors, to sequence the selection.

So, let’s assume that you have a configured fetch object. When you execute the fetch, a collection of managed objects is returned, and placed in the context. This collection can be used in any way you want – for example, you can extract a “name” attribute, so that you can display a list of names in the user interface.

What about editing or adding managed objects? Well, a fetch request that returns one object will deliver a managed object to the context. You can change one or more of its attributes, and when you save the context, the updated managed object is persisted. Alternatively, you can create a new managed object, configure its attributes, and again, save the context.

At this point, we hope that you “get” Core Data. There’s not much more to it. Sure, there’s syntax, coding patterns, and best practices, but they’re straightforward and fairly easy to follow.


Fetched results controller

One more thing… We often use Core Data when working with table views (UITableView). In this scenario, we always use an object called a “fetched results controller” (NSFetchedResultsController). The fetched results controller is an awesome chunk of functionality, providing state and behaviour that matches up very nicely to the needs of a table view.


Where can I see Core Data in an app?

( more to come )

Short form:

  • The app delegate creates three Core Data objects
  • One of them – the managed object context – is passed on to the root view controller (and then to any other controller that needs access to the context)
  • You know that a view controller is always configured with a data-bearing property; with Core Data, the data-bearing property is often a managed object
  • A view controller has a fetched results controller; this initializes the fetch object, and so on


Today’s example apps

( more to come )

Short form:

  • We will create a throw-away app, so that we can see what the project template provides
  • We will create another throw-away app, which adds some functionality to a template-provided app
  • We will then explore a fairly simple example app (CD Intro)



Categories: 2010 Fall DPS913
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

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

WordPress.com Logo

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: