Core Data is Apple's data persistence framework. You can utilize this framework whenever your application needs to store data. Simple data can often be stored in NSUserDefaults, but when you're handling data that's more complex, has relations, or needs some form of efficient searching, Core Data is much better suited for your needs.
You don't need to build a very complex app or have vast amounts of data to make Core Data worth your while. Regardless of your app's size, even if it's really small with only a couple of records or if you're holding on to thousands of records, Core Data has your back.
In this chapter, you'll learn how to add Core Data to an existing app. The app we will build keeps track of a list of favorite movies for all members of a family. The main interface will be a table view that shows a list of family members. If you tap on a family member, you'll see the tapped family member's favorite movies. Adding family members can be done through the overview screen, and adding movies can be done through the detail screen.
We won't build the screens in this app from scratch. In the repository for this book, a starter project called FamilyMovies is included. This starter project contains all of the screens, so we don't have to implement them before we get around to implementing Core Data.
In this chapter, we will cover the following topics:
- Understanding the Core Data stack
- Adding Core Data to an application
- Modeling data in the model editor
We won't store any data yet; this will be covered in the next chapter, Storing and Querying User Data . For now, we'll just focus on what Core Data is and how you can add it to your application. Let's take a look at what Core Data is exactly and how it works.
Before we dive into the start project and add Core Data to it, we'll take a look at how Core Data actually works, what it is, and what it isn't. In order to make efficient use of Core Data, it's essential that you know what you're working with.
When you work with Core Data, you're actually utilizing a stack of layers that starts with managed objects and ends with a data store. This is often an SQLite database but there are different storage options you can use. Let's take a quick look at these layers and discuss their roles in your application briefly:
At the top right of this diagram is the NSManagedObject class. When you work with Core Data, this is the object you'll interact with most often since it's the base class for all Core Data models you will create. For instance, in the app we will build, the family member and movie models will be subclasses of NSManagedObject.
Each managed object belongs to an NSManagedObjectContext. The managed object context is responsible for communicating with the persistent store coordinator. Often, you'll only need a single managed object context and a single persistent store coordinator. However, it is possible for you to use multiple persistent store coordinators and multiple managed object contexts. It's even possible to have multiple managed object contexts for the same persistent store coordinator. A setup like this can be particularly useful if you're performing costly operations on your managed objects, for example if you're importing or synchronizing large amounts of data. We'll stick to using a single managed object context and a single persistent store coordinator because we simply don't have the need for more.
The persistent store coordinator is responsible for communicating to the persistent store. In most scenarios, the persistent store will use SQLite as its underlying storage database. However, you can also use other types of storage, such as an in-memory database. Using an in-memory database is especially useful if you're writing unit tests or if your app has no need for long-term storage. More information on testing can be found in Chapter 19 , Ensuring App Quality with Tests.
If you've worked with MySQL, SQLite, or any other relational database before, it will be tempting to think of Core Data as a layer on top of a relational database. Although this isn't entirely false, Core Data does not work the same as using SQLite directly; it's an abstraction on top of this.
One example of this is the concept of primary keys. Core Data doesn't allow you to specify your own primary keys. Also, when you define relationships, you don't use object IDs or other keys, you simply define the relationship. We will cover more on this subject later. If you try to translate your SQLite experience to Core Data, you will run into issues, simply because Core Data is not SQLite. It just happens to be so that SQLite is one of the ways that data can be stored.
Now that you have an overview of the Core Data stack and where all the moving parts belong, let's add the Core Data stack to the FamilyMovies application.