Core Data and Swift Best Practices Part 3

Welcome back to another episode of Core Data my young Core Data padawans. Remember how last time I said we were going to write the beginnings of a skeleton app? Well this time we are actually going to do it! But first… A little talk on attribute options. From there we’ll move to managed object subclasses ad finally *drumroll* we’ll begin setting up our stack!

When I last wrote I discussed the importance of Entities and Attributes. But we didn’t have a chance to dive into the additional options attributes possess that we might need to adjust in our demo app. We mark the date attribute as non-optional/indexed, and the color sequence attribute as non-optional.

When dealing with a non-optional attribute, there are a couple of things to take into consideration. First, non optional attributes have to have a valid value assigned to them in order to be able to save the data. marking an attribute as indexed creates an index on your underlying SQL database table (more on this later).

There are pros and cons to using such an index system. Using an index certainly speeds up the process of sorting/finding records by the attribute; but it comes at a cost of performance, particularly when one is inserting new records and some additional storage space. In our case, we’ll display the current status objects sorted by date, making it understandable to index the attribute. If you wanna learn more about indexes and dive deeper into their relationship with performance, comment or tweet at me! Would love to write more about them.

**Managed Object Subclasses **

Now that we’ve created the data model, we have to create a managed object subclass that represents the “Current Status” Entity in the code. The entity is ultimately just a description of the data that belongs to each status. To actually manipulate the data in our code we must create a class that possesses the properties representative of the attributes we defined in the entity.

A quick note about naming. Entities have names which always begin with a capital letter, further it’s best practice to name the classes by what they actually represent rather than what might be intuitive like “StatusEntity.” Our class will simply be called Status. Why such a hard line to the naming? Because an entity is very distinct from your run-of-the-mill class. And because we’re proper software engineers we ensure that are naming is precise and reflects that.

When you finally get to creating the class there’s two ways you can go about it. (1) You can use Xcode’s code generation tool. This works by navigating to the top tab and clicking

 (Editor > Create NSManaged Subclass..)

This is how I went about things at first to minimize the possibility of making mistakes. But upon further reflection I’ve come to the conclusion that one should simply write it by hand. It’s not much code, you only have to type it once, and there’s the advantage of being in full control of of how you write it. It also makes the process much clearer since it forces you to see how all the pieces connect.

Or Status Entity Should like this:

public final class Status: ManagedObjectModel {
@NSManaged public private(set) var date: NSDate
@NSManaged public private(set) var color: (UIColor)

The Superclass, ManagedObject, is simply an empty subclass of NSManagedObject:

public class ManagedObject: NSManagedObject{

Let’s explain what’s going on up here. We need the above because of the way generic type constraints work in Swift. There’s no need to delve too deep into this so for now you can just consider it to be equivalent to NSManagedObject.

The @NSManaged attributes on the properties in our class tell the compiler, “Hey, these properties are backed up by the Core Data attributes.” The `private(set)` access control modifiers signal that both properties are publicly readable, but not writeable. Core Data actually isn’t picky about such things, but if we explicitly note this in our class definition, the compiler will.

So why are our access control modifiers set to ensure that our properties are only readable? Because there’s no need to expose our attributes as writable to the world. We want to protect our data and only allow the helper methods we will later create to to insert new statuses with specific values upon creation. In short, only expose what you really need to expose.

**Catches Breath** Man that was a lot. Look for the next phase where we’ll set up our stack later this afternoon on the blog.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s