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

Defining a rocket launch entity in the editor isn't enough because you need a way to reference it in code and create instances of it. As mentioned earlier, Core Data models are structured differently from other data types you may have encountered. Core Data stores this data and generic containers using key value entries. But to make life easier, you can represent the entities in code as managed objects subclasses. There are two ways you can do this. The first is to have Core Data do it for you. And the second is to write it out yourself. Obviously you're here to learn so you're gonna do the latter. When you auto generate files, Core Data splits the definition and functionality up into two files. So you'll do the same. Add a new Swift file to the project in the model group and name it rocket launch plus Core Data class. Replace the foundation import with an import of the Core Data framework instead. Next, you're going to define rocket launch as a subclass of the NSManagedObject class. Because you're inheriting from the subclass, you get a lot of behavior for free. All the underlying logic of storing the data using the right keys and values are all taken care of. There's one small edition you need to make to the class definition here. By default, Swift code is only exposed to other Swift code. Makes sense, right? Well, Core Data is an Objective-C framework. So you need to let the Objective-C run time know about this class. That is as simple as annotating the class with the at Objective-C attribute. If you ought to generate this code, and you will later on in this course, you'll notice that the annotation is often followed by the name of the class like this. When exposing this class to the Objective-C runtime, you can rename the class to avoid namespace collisions. Essentially, what that's doing is saying that when this class is referenced by the Objective-C run time, we want the name used to be rocket launch. The Objective-C convention for naming your classes is to put your initials in front as a two or three letter prefix. So you might see that on occasion. All right, so that's it for the class definition. Add another file to the same group and name it rocket launch plus Core Data properties. This is not essential and you could do this in one file but it's how the auto generated code is added, so you'll do the same for consistency. And here you're going to define the interface I mentioned earlier. Since Core Data is going to store the values in generic dictionary like containers with keys and values, you want something nicer to work with and code. This is important because it's super easy to make mistakes when using strings to reference keys everywhere. Start by importing Core Data again and then define an extension of the rocket launch class you just created. In this extension you're going to add properties to interact with the attributes you defined in the model editor. First up is the name property. All right, so what kind of property should you define? You can't define a stored property because you can't do that in extensions. You might be thinking, well, I just defined a class a minute ago. Let's go back to that file. You could add the attribute as a stored property in the class. But now you need to initialize this property with value. You can sidestep this issue by making the property optional but according to the model you define in the editor, this needs to be required. You can also define an initializer for the class that accepts an initial value for the property. But how can you guarantee that this initializer is called when Core Data fetches data from the persistent store and initializes an instance of this class? Well, you can't really. So a custom initializer is not an option. Let's get rid of this code. Back in the extension of rocket launch, you could define name as a computer property. But this doesn't work either. Should you write the logic yourself to fetch the value from the store? No, since that is what Core Data does for you. To tell the compiler that the storage for this property is handled by Core Data, you need to add the at NSManaged keyword. With this in place, Core Data dynamically generates efficient get and set attribute accessor methods for properties that are defined in the entity of a managed object's corresponding managed object model. This is how Core Data can use generic data containers under the hood, but provide us with the proper class instance to interact with the rest of our app. Pretty neat, huh? Go ahead and add the rest of the attributes as managed properties. Now you have a class you can use. Before we wrap this up, it's worth mentioning, just like you couldn't add stored properties to the class because it messed with how Core Data initialized the class, there are other aspects, certain methods in particular that you shouldn't override because Core Data expects managed object subclasses to behave a certain way. We also have one tiny thing left to do, navigate to the rocketlaunch.exe data model D file, select the rocket launch entity and open up the data model inspector. Earlier when I walked you through this section, we skipped this one right here that says class. Remember how I said the Core Data can generate the managed object subclasses for us? If you go to the editor menu, there's a create NSManaged object subclass option at the bottom. Don't worry. You'll use it later. And this section right here is where we map the entity and the editor to the subclass and code. You should see the name rocket launch here and the code gen field set to class definition. Go ahead and change that to manual/none to indicate that you wrote it out yourself. Hit Command + B to build the app and verify that everything compiles properly. All right, in the next video, let's talk about creating instances of this class and saving rocket launches.