Core Data: Fundamentals

Jul 19 2022 · Swift 5.5, iOS 15.4, Xcode 13.3.1

Part 1: The Core Data Stack

04. Managed Object Context

Episode complete

Play next episode

Next
About this episode

Leave a rating/review

See forum comments
Cinema mode Mark complete Download course materials
Previous episode: 03. Managed Object Model Next episode: 05. Persistent Store Coordinator

Get immediate access to this and 4,000+ other videos and books.

Take your career further with a Kodeco Personal Plan. With unlimited access to over 40+ books and 4,000+ professional videos in a single subscription, it's simply the best investment you can make in your development career.

Learn more Already a subscriber? Sign in.

Notes: 04. Managed Object Context

NS Managed Object Context documentation

Heads up... You've reached locked video content where the transcript will be shown as obfuscated text.

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 scratch pad. When using a real scratch pad, 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 define. Because these are copies, you can modify them however you want without affecting the actual store 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 persistent 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 a 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 (indistinct) save, this context hands off this order to the rest of the core data stack to execute. In code, the NS managed object context 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.