Welcome back to another exciting edition of, drumroll Core Data! We last left off with the an explanation of Core Data and an overview of its architecture. This time we’re going to actually begin writing the skeleton for a very simple app. Accompanying this skeleton will be a continued explanation of Core Data.
The last time I wrote I mentioned the possibility of multiple persistence stores and store coordinators. More often than not you’re not going to need that.
But since I last wrote I left an explanation of the precise role of the persistence store and persistence store coordinator rather opaque. This was intentional. This is because the persistence store family itself are rather opaque objects! Nevertheless it’s a very important piece that we’ll look into more detail later.
The last piece of the puzzle that we need to cover before embarking on our skeleton app is a more through explanation of the persistence store. An instance of the NSPersistanceStore
Quick question. What is the role of core data? Don’t look it up! Try to recall what I discussed in the last entry: core data stores structures data. In order to use Store Data we need to create a model—or what backend developers commonly refer to as a schema.
There are two ways you can define this scheme. One can either define the data model via code. OR they may use Xcode’s native model editor. I would argue for use of the latter tool as it’s much easier to visualize; especially if you’re a Core Data newbie. Compound that with great tools such as MOGenerator, and you have a powerful way of quickly creating and deploying your data models.
To get started is easy. Create a empty Xcode template for an iOS or an OS X App, (for the purposes of this tutorial it won’t matter what) and create your data model by going to File > New and choose “Data Model” from the Core Data Section. If, however, you clicked on the “Use Core Data” checkbox when first creating the project an empty data model will have already been generated for you.
Of course, you don’t need to check this box. Actually for the purpose of this tutorial I suggest you don’t as I want you to create the generated boilerplate code from scratch anyways.
Once you select the data model, Xcode’s data model editor opens up and we can start doing the dirty work…
Entities and Attributes
Entities are the core lego blocks of our data model. Because they are so fundamental to our model we should think of entities as representing a piece of data that’s meaningful to the app. For example, in our case, we are going to create an entity called Current Status which has two attributes: one for a color representing a stage in your workflow, and one for the date of the snapshot. By convention, entity names start with uppercase letters; just like class names.
The best part of Core Data is that it supports a great deal of different data types right out of the box! Numeric types, strings, booleans, dates, binary data and even transformable types that store any object conforming to NSCoding standards, or any object you might have created a custom value transformer for.
For our Current Status entity we want to create two attributes: pne of type Date (named date), and one of type Transformable (workflow colors). Attribute names are typically represented with lowercase letters a la a class or a struct. The colors attribute holds an array of UIColor objects. Since NSArray and UIColor are both NSCoding compliant we can store such an array directly into a transformable entity (woo hoo!)
That’s all for now. Remember when I said last time that we would delve into some Swift code? Turns out there’s a lot more concepts we have to dive into before I can set you guys off with that. Stay tuned though. I plan to throughly flesh out the guide and release this week.