Core Data and Swift Best Practices Part 2

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

Data Modeling

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.

The Simple Programmer and the Quest to Market Oneself

Marketing is a dirty word in the tech industry.

We developers can be a proud bunch. We tend to believe–despite all evidence to the contrary–that the best idea should and always win. It can be frustrating to communicate this dissonance to my fellow developers, particularly when the truth of the matter is so obvious to me. So what’s a young developer to do? Give up and resign themselves to the status quo? Or maybe–just maybe–they should try to attack the problem in another way. Maybe they should demonstrate the importance of self promotion to their fellow devs by reaping its benefits firsthand. In the end that’s the path I chose.

Enter John Sonmez of the SimpleProgrammer.

I’ve never actually met John in person. Instead I heard his name while I was getting ready to submit an audition for the PluralSight series. After speaking with PluralSight Editor, Stephanie Evans, and exploring the PluralSight website his name came up:

I asked, “Hey Steph, who’s this guy with a million courses?”

She slowly smiled. “Oh him? That’s John Sonmez. …He’s actually a millionaire.”

My jaw dropped. ‘A millionaire dev who isn’t working for any member of the Big 4?’ I thought to myself. But how?

After doggishly stalking John’s blog for days it quickly became apparent why he was able to reach the level that he’s at. When the man isn’t coding and keeping up with technology he’s making use of all his non-work hours to promote himself and his business.

And he doesn’t just promote for himself, he teaches other devs how to reach the milestones that he’s reached. He does it through his website and through his free email series. I love this. Most successful people tend to hide how they’ve achieved success behind a series of paywalls and smoke and mirrors.

And that’s what I love about John. He doesn’t hide all the information he’s aggregated behind some sort of paywall (although he does have a training series that he sells). One can still reap a wealth’s worth of knowledge from the free content that is all available on the SimpleProgrammer. Truth be told I will purchase his books anyways because I’ve already benefited from the free material he has posted on his website.

I took his free email series on blogging and have already implemented many of his suggestions. I am now blogging once a week (and more when I get the chance). I’ve narrowed my focus to mobile development with a sprinkle of soft skills. I have a schedule of topics I’ll be writing on for the next few months.

For those of you who hesitate to write a blog because of fear for lack of topics, let me assure you from personal experience that this is the least of your worries. Once I sat down and decided on what I wanted to write I quickly realized I had too many things to write about and the actual battle would be finding time and remaining consistent. Something John comments on as well, coincidently.

Just implementing the few steps above has increased traffic to my site dramatically. I went from only about a few views a month to 300. In just one month!

I know, I know. You’re thinking, ‘I’m not some poser Kacheflowe. I care about my tech skills. How does blogging help me?’ To you I say, look at those developers most prolific and most well known in your community. Would you say that these developers lack the technical chops to tackle the problems we devs encounter everyday? Of course not! More often then not these are the same people you reference when trying out a new technology. So blogging consistently can increase your technical proficiency and credibility.

That’s all for now. I implore you to check out John’s site and think more about promoting yourself as a developer. This stuff matters.