Core Data: Fundamentals

In the last part you added a data model to your project. The RocketLaunch data model file is where you’re going to do most of the initial work to get the object graph set up. Navigate to the RocketLaunches.xcdatamodeld file if you haven’t already.

Right now you should see just an empty file. On the left is a navigation menu of sorts where you can select the different Entities, Fetch Requests or Configurations you’ve created. Don’t worry if you don’t know what any of that means; you will soon enough.

In the middle there is the editor area where you can set up the Entities or any other objects you create, and finally on the right is the assistant editor where you can customize properties.

Since you’re building a RocketLaunches app you need to model a RocketLaunch and you’ll start by creating an Entity. At the bottom of the editor window you should see a row of buttons; the second from the left says Add Entity. Go ahead and click it to add a new Entity to your data model.

When this entity is created it is given the generic name Entity. Select the it from the list, and in the Data Model Inspector, that’s the very last icon in the Inspector area, change the name to RocketLaunch.

In addition to changing the name, there are several ways to customize your entity:

• Right below the name text field in the editor you can see a checkbox. You would select this Abstract Entity checkbox if you don’t want to create any instances of this entity. In many programming languages there exists the concept of an abstract class which is a class that must be subclassed with specific implementation details before it can be used. An abstract entity is very similar - it serves as a blueprint for a child entity that you can define and the child entity is the one that’s instantiated instead.

• Next you can specify whether an entity has a parent. The parent entity field goes hand in hand with the abstract entity option. If you defined a Vehicle entity as an Abstract entity, and then define a Car and Truck entity each of which reference the Vehicle entity as its parent. Just like subclassing, the Car and Truck entity would inherit the properties of its parent and this allows you to organize your managed objects and keep the model layer nice and clean.

You’re going to ignore the rest of the options here for now. We’ll come back to some but others are a bit too complicated for the simple app you’re building and you’ll ignore those.

Now you have a basic Entity but you need to customize it. Much like you would add stored properties to types, you can add and configure attributes on your Entities. An attribute describes a property of an entity and when creating one you need to define four things at minimum:

• the name of the attribute
• the type of the underlying data
• whether the attribute should be saved in the data store, and
• whether you’re required to supply a value when the attribute is saved

Since this entity represents a RocketLaunch you need to add attributes typically associated with a rocket launch. First up, is the name. You can either hit the plus button at the bottom of the attributes section or, with the entity selected, you can hit the Add Attribute button in the bottom row on the right.

You’ll start by giving this attribute the name name. Next you need to define the type of data. If you tap on the Undefined value that’s there by default you should see a drop down that lists all the types you can store using Core Data. Nearly all of these are pretty self explanatory, except for ones like Transformable and Binary Data but you’ll ignore those for now.

Let’s set the name property to be of type String. With the attribute selected, let’s move over the to data model inspector. Here you will find a lot more that you can customize for each attribute.

The name and type are listed already. As discussed earlier you need to specify whether this property needs to have a value when saved and this rule is defined by the optional checkbox. Optional attributes are not required to have a value when saved to the persistent store, and as you can see attributes are marked optional by default.

It’s important to note that a Core Data optional is not the same as a Swift optional. When you generate code to work with entities, something you will do in a second, you may notice that properties are sometimes generated as optional even when you uncheck this box in the model editor and that’s because a Swift optional can be used to represent a required attribute purely as a means of flexibility. There may be times when you initialize a RocketLaunch at one point and assign a required value at some later point. Representing this required property in code using an optional allows you to provide a value after initialization.

You’re going to uncheck the optional property here because all rocket launches need a title.

Next is the transient configuration. A transient attribute is not saved to the persistent store. You might be thinking what’s even the point? All attributes are saved to the store by default unless they are marked as transient. You would use a transient attribute if you wanted a useful place to temporarily store a calculated or derived value. Think of it like Swift computed properties; you use them to enhance the user experience or your logic in a certain way but they don’t need to be saved. If you mark a property as transient, it will be defined in the object’s generated interface but Core Data will not keep track of it for you. We’ll explore transient properties later on.

Right below that you have the derived option. You would mark an attribute as derived if you want to optimize fetch performance when retrieving values from the store. Notice that when you check the box the options in the model inspector change. Let’s skip this property as well. Optimizing fetches is not something you’re going to worry about with such a simple app.

Next up is the option to give your attribute a default value, in this case a string value. Giving rocket launches a default title wouldn’t make sense so leave that option for now, but this can be very handy.

Just like that your RocketLaunch entity has a name attribute. This is a good start, but it’s not enough to model all the information you need. In the next video, let’s flesh out the RocketLaunch entity.