Core Data: Fundamentals

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

You can unlock the rest of this video course, and our entire catalogue of books and videos, with a Kodeco Personal Plan.

Unlock now

When you use the Rocket Launcher's app, you need a way to model the concept of a launch. You could create a Swift type using a struct or a class. This is how you would normally do it, but creating instances of this class isn't sufficient to store or persist the data permanently. One way you could handle this is to write the instances of this type to a file on the disk when you call the Save method. You could have type adopt the Codable protocol. And whenever you want to save, you could use a PropertyListEncoder to encode the data as a plist. Unfortunately, this approach would only take you so far. When retrieving the launches from the plist file, you would have to fetch them all at once. This is because there's no way for you to easily decode partial documents. You would also have to figure out how to search this file and update entries. Even worse, creating relationships between types would be quite difficult. Imagine that you want to add launches to specific lists. You could create a list type that stores a reference to each launch as an array of IDs, but how do you easily and quickly fetch launches that only belong to a particular list? At this point, you want to figure out how and where to store this particular data instead of focusing on your app's logic, which is far more important. With Core Data, you don't use plain Swift types to model your data. Instead, you use a managed object. A managed object looks and feels like a Swift class, but you should think of it more as a representation of the data held in the persistent store. Instead of being a specific type, a managed object is a subclass of NSManagedObject and is more like a generic container that we can store our data in, much like a dictionary. When creating managed objects, you can specify what kind of shape you want the data to take, and Core Data provides a programmatic interface to interact with the underlying generic container. What does that mean? Instead of creating objects directly in code, Core Data provides a visual interface to define the types that you'll use to represent your data. Core Data refers to these types as entities. So, for example, you could use this visual editor to create the Book entity. Under the hood, Core Data doesn't actually create an actual type just a generic container that uses keys and values to store data. It would be a pain, though, if that's how you had to interact with the object, not to mention, very error prone. Instead, Core Data provides an interface for you that restricts access to the underlying data using properties on the subclass. And this way, it feels like you're working with a book, author, or Rocket Launch type. Core Data deals with mechanics around saving those types under the hood. Since these are generic containers, how does Core Data know which table in the underlying store maps to which type? When creating an instance of these types, use an entity description, which specifies an entity's name, properties, and the class that represents it. This object is then used to keep the convenience code that Core Data has created for you and the underlying stores and sync. You won't worry about this part too much, though, because you won't be interacting with the entity descriptions directly. Let's look at the hypothetical example introduced earlier, an app to record the books you're reading. In this particular case, you would have a separate entity to represent a book, author, and genre. All the managed objects together, comprise the Managed Object Model and is the object graph manager aspect of Core Data. Defining the Managed Object Model is the first part of working with a Core Data stack. And the better you define your Managed Object Model, the easier it is to work with these objects, as Core Data can provide some rich support. So that's the first part of the stack, the object graph layer represented here as the Managed Object Model. In the next episode, let's talk about the Managed Object Context.