Core Data: Fundamentals

As a user interacts with the app and modifies the data model - whether it be by adding new Books to their library, or deleting older books, you need a way to keep track of all the changes. This is where the next part of the stack comes in - the managed object context.

The managed object context is a really important object in the stack and plays a central role in managing the object graph.

Of the entire Core Data stack, the managed object context is the one that you’ll interact with the most. As a result, it’s the only object that you’re going to expose to the rest of the app when you create your stack later.

Think of the managed object context as an intelligent scratchpad. When using a real scratchpad you keep notes by adding, modifying, and striking out text on the page. In the same way the context keeps track of everything that changes across the object graph layer.

If you diagram the Core Data stack, you have the object graph layer at the top, and the persistence framework at the bottom. When you fetch data from the persistent store, temporary copies of this data are loaded into the scratch pad to create the object graph you defined. Because these are copies you can modify them however you want without affecting the actual stored data.

It’s the context’s job to keep track of all these changes that occur. The changes are not persisted until you save the data.

You must register all managed objects with a managed object context; otherwise you can’t use them. The context inserts it appropriately into the object graph, and ensures that the model layer is in a valid state.

Just like with the temporary copies, the context keeps track of these changes as you add and remove objects. This includes changes to the managed objects themselves, as well as changes in the relationships between all these objects in the object graph. By tracking changes, the context is able to provide undo and redo support automatically.

Once you decide to save these changes, if the managed object model is in the correct state, the framework writes the changes to the persistence store. The framework adds new entries for objects you created, or removes entries for objects you deleted.

This is where the magic of Core Data happens. The managed object context handles most of the how and where of saving data for you. Without it, you’d have to write your own code to archive and unarchive data to keep track of changes to your model objects and implement any functionality for redo and undo. Core Data ends up saving you hundreds, if not thousands of lines of code.

The managed object context is a good example of the command pattern in use. The command pattern is a behavioral design pattern in which an object - the context in this case - is recording or encapsulating all the information needed to perform an action at a later time.

A common illustration of the command pattern is an order at a restaurant. A waiter takes an order from a customer and encapsulates that order by writing it down. The order is then queued for a chef or cook to handle.

Similarly the context notes down all the commands that the app needs to execute. This includes inserting new objects, updating existing ones or deleting old ones. When you call save, this context hands off this order to the rest of the Core Data stack to execute.

In code the NSManagedObjectContext class represents the managed object context, and as mentioned earlier it is the class you will use the most.

It’s important to note that although it is often referred to as the Core Data stack, there can be more than one of any of these objects in use in a single app. For our simple app, one will suffice, but for a variety of reasons that we won’t cover here you can also have more than one context in use.

That’s all for the context; next, let’s look at the persistent store coordinator.