Welcome to Core Data Fundamentals. In this series, you'll learn the ins and outs of Apple's popular Core Data framework. Even though we'll be building an iOS application, the Core Data framework is available on iOS, tvOS, macOS, and watchOS, and the contents of this series apply to each of these platforms.

Developers new to Core Data usually don't take the time to learn the framework. Not knowing what Core Data is, makes it hard and frustrating to wrap your head around the ins and outs of the framework. I'd like to start by spending a few minutes exploring the nature of Core Data and, more important, explain to you what Core Data is and isn't.

Notes is a simple application for iOS that manages a list of notes. It's a fine case study to teach you the fundamentals of the Core Data framework. In this episode, I'd like to show you what Notes is capable of.

Earlier in this series, you learned what Core Data is and isn't. This episode zooms in on the building blocks of the Core Data framework.

Before we set up the Core Data stack, we need to create the project for Notes. Open Xcode and create a new project based on the Single View App template.

It's time to write some code. Had we checked the Use Core Data checkbox during the setup of the project, Xcode would have put the code for the Core Data stack in the application delegate. This is something I don't like and we won't be cluttering the application delegate with the setup of the Core Data stack.

I'm not going to lie. I don't like singletons. Singletons are fine if they're used correctly, but I don't like singletons for convenience. They almost always lead to problems down the line. This means that the Core Data manager isn't going to be a singleton.

The data model is a key component of the Core Data stack and an integral part of a Core Data application. In this episode, we explore the data model and learn about entities and attributes.

Core Data is great at managing relationships. In this episode, we continue our exploration of the data model by taking a close look at relationships.

Core Data is much more than a database and this becomes clear when you start working with relationships. Relationships in Core Data are powerful because the framework does a lot of the heavy lifting for you.

Core Data records are represented by the NSManagedObject class, a key class of the framework. In this episode, you learn how to create a managed object, what classes are involved, and how a managed object is saved to a persistent store.

In the previous episode, we used the NSManagedObject class to represent and interact with records stored in the persistent store. This works fine, but the syntax is verbose, we can't take advantage of Xcode's autocompletion, and type safety is also an issue.

In the next episodes, we add the ability to create, read, update, and delete notes. Before we start, we need to make some preparations.

You may be wondering why we didn't save the note immediately after creating it. That's a fair question. We could have. But why would we? Why would we push the changes of the managed object context to the persistent store every time something changes in the managed object context? That's a waste of resources and it may even impact performance, depending on the complexity of the operation.

In this episode, we fetch the user's notes from the persistent store and display them in a table view. The notes view controller is in charge of these tasks.

The application we're building wouldn't be very useful if it didn't include the ability to edit notes. Would it? If the user taps a note in the notes view controller, they should be able to modify the title and contents of the note.

The application currently supports creating, reading, and updating notes. But it should also be possible to delete notes. The pieces we need to add the ability to delete notes are already present in the notes view controller. In fact, we only need to implement one additional method of the UITableViewDataSource protocol to add support for deleting notes.

The application now supports creating, reading, updating, and deleting notes. And this works fine. But Core Data has another trick up its sleeve.

To update the table view, we listened for notifications sent by the managed object context of the Core Data manager. This is a perfectly fine solution. But it can be messy to sift through the managed objects contained in the userInfo dictionary of the notification. In a complex Core Data application, the NSManagedObjectContextObjectsDidChange notification is sent very frequently. It includes every change of every managed object, even the ones we may not be interested in. We need to make sure we only respond to the changes of the managed objects we are interested in.

To help users manage their notes, it's helpful to allow them to categorize their notes. Earlier in this series, we added the Category entity to the data model. Remember that a note can belong to only one category, but a category can have many notes. In other words, the Note and Category entities have a One-To-Many relationship. The data model editor visualizes this.

In this episode, I'd like to add the ability to assign a color to a category. This makes it easier to visualize which category a note belongs to.

An application that grows and gains features also gains new requirements. The data model, for example, grows and changes. Core Data handles changes pretty well as long as you play by the rules of the framework.

In the previous episode, we exposed the root cause of the crash we ran into earlier. The solution is versioning the data model.

The last feature I want to add is the ability to tag notes. This feature is interesting because of the Many-To-Many relationship of the Note and Tag entities. In this episode, you learn how to work with such a relationship.

We currently use one managed object context, which we created in the CoreDataManager class. In the application, we pass the managed object context to the objects that need it. This works fine, but there will be times when one managed object context won't cut it.

It's time to refactor the CoreDataManager class. Let me walk you through the changes we need to make. Don't worry, though, most of the implementation of the CoreDataManager class remains unchanged.

Because we updated the CoreDataManager class in the previous episode, we need to make a few changes in the project.

The CoreDataManager class is in charge of the Core Data stack of the application. It encapsulates the Core Data stack and only exposes the main managed object context to the rest of the application.

In this episode, I'd like to discuss a concept that often confuses developers new to Core Data, faulting. Before I explain what faulting is, I want to show it to you.

My hope is that this series has taught you that Core Data isn't as difficult as many developers believe it to be. Core Data isn't complex once you understand how the various pieces of the framework fit together.