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

Now that you understand the basics of how to customize and configure your entities with attributes, it's time to do a challenge. In this challenge, you'll add some additional attributes to the RocketLaunch entity. I'm intentionally not specifying which attributes you need to add because in addition to adding the attributes, I find it useful to run through the exercise of figuring out how to model an object from the real world. So what attributes would you add to a rocket launch? When you're done, join me, and we'll walk through my implementation together. Good luck. (upbeat music) Welcome back. Hopefully, that wasn't too hard. Let's compare notes. I decided to keep my RocketLaunch model fairly simple because these things can get very complicated very quickly. The first thing you need to know about rocket launches, and arguably the most important, is whether you viewed them or not. They're so awesome to watch. For that, let's add an isviewed property that is of type Boolean. And you certainly don't want this to be an optional property, so you can uncheck that box. Earlier, when we talked about default values, I glossed over it. This is a good place to use it. By default, all new RocketLaunches should have isviewed set defaults. Why have RocketLaunches that are completed when you create it? You'll notice that instead of a text field, there is a dropdown for the default value. Xcode is smart on occasion, and can figure out that there can only be two types of default values for a Boolean property. It's not so smart to figure out that you're using Swift, apparently, because instead of a true or false value, you have Objective-C's yes and no. Let's set this to no. Right below that, you should see another checkbox, Use Scalar Type. in just a minute, you're going to generate the code to work with these entities, and when you do so, Core Data is going to make some choices about what the types of these attributes should be. With this box, unchecked, Core Data is going to use objects to represent these values instead of the primitive data types that you normally work with. For example, with this box unchecked, the type of this attribute in code would be NSNumber, which is an Objective-C type that wraps around a value of zero or one to represent a Boolean. With the box checked, you'll get the non-object type instead, which in this case is BOOL. For the next attribute, let's add launch date, which also should not be optional. You're not going to be doing anything fancy with a date in this app, but this gives us a chance to look at the different data types and the flexibility you get with Core Data. In addition to the options you've seen already, you'll notice that with dates, you can specify a range to validate against. It is somewhat limited though, and only accepts a static date range. If it were flexible, you could set the minimum date to be greater than the date at which the RocketLaunch was created. To round it off, let's add a few more attributes. Notes of type string to the RocketLaunch, and launchpad, which is also of type string. Both of these can be optional. We may not know the exact launchpad or have notes to keep until we've watched the launch. That looks good for now. If you added any other attributes, that's awesome. Feel free to continue using your model, but just keep in mind that the user interface is somewhat limited. In the next video, let's talk about managed object subclasses.