Swift Optionals on Andrew Bancroft

Core Data Model Attributes and NSManagedObject Property Types Must Match!

Sun, 23 Apr 2017 20:03:34 +0000

I admit – it might have taken me less time to figure out my runtime exception if I hadn’t just migrated my project to Swift 3 when I encountered the bug.

That’s the problem isn’t it? You go in… you intend to do one thing. Before long, you’ve got 15 files with an M out to the right. The project builds (finally), but ah – then there’s runtime.

When the crash occurs, you’re never sure if it was an existing problem, or if it was caused by the code conversion. Who knows – maybe it’s both?

Perhaps this is a story more about code conversion than it is about Core Data. In any case, perhaps it’ll help a poor soul struggling to figure out why just happened.

Data model Attributes and NSManagedObject property types – Match ’em!

Whenever you’re creating a subclass of NSManagedObject for the Entities in your data model, you’re in a mapping process.

Each Attribute on an Entity maps over to a property on the NSManagedObjectSubclass.

Not only must the names of those Attributes and properties match, but the Types of each must match as well.

Optionals are Types

String isn’t the same as String?.

Date isn’t the same as Date?.

They’re different Types.

So what happens if you specify that a certain Attribute named, say, createdOn is a Date with the Optional checkbox checked in the data model designer like this:

And over in the implementation of your NSManagedObject subclass, you have code that’s written like this:

`1`	`@NSManaged var createdOn: Date //instead of Date? (ie, the ? is missing)`

What’ll happen? Well, I can tell you what’ll happen. :]

When you run the app and attempt to load objects from your persistent store that have been saved with nil for the createdOn value, your app will blow up:

Xcode isn’t entirely unhelpful. While the EXC_BAD_INSTRUCTION message in the text editor isn’t very illuminating, the Debug Navigator on the left () provides some clues.

For me, it displayed just the breadcrumb that made me go, “Oh! Let me go check and see if I’ve got a Type mis-match between my data model and my NSManagedObject subclass”:

Interesting… It looks like there was an attempt to go from an NSDate? (optional) instance to a Date (non-optional).

The issue isn’t that I’ve got a mismatch between NSDate and Date. The runtime can swap those around and substitute them easily.

Rather, it’s that I’m trying to go from optional, where nil is fine, to non-optional, where nil…well…crashes things.

Lessons learned

What have I learned?

1 – Map Attributes to NSManagedObject subclass properties carefully.
2 – Don’t accidentally miss a ? to indicate that a property is optional if I’ve got it marked as optional in the data model
3 – Read the Debug Navigator. It’s not just a list of gibberish – it can actually provide helpful clues so you know where to go look to solve your problem!

Resources

Core Data Fundamentals with Swift

How to Unwrap Multiple Optionals with One If-Let in Swift

Wed, 19 Apr 2017 17:25:41 +0000

What do you do when you’ve got two (or more) optionals that you need to safely unwrap and work with?

Code examples

Suppose that you’ve got two arrays, both of which are optional. What I want to do right now is walk through a couple of scenarios where I unwrap them at the same time and print them to the console with a single if-let statement.

First, watch how it’s done to accomplish the goal of this article’s title. :]

Then, compare what you expected to be the print output, to the actual output to make sure your understanding of how the syntax works is complete.

Ready?

Scenario 1: Both arrays are initialized (non-nil)

1var greetings: [String]? = ["Howdy!", "Hello!"]
2var salutations: [String]? = ["Hi!", "Hey!"]

1if let g = greetings, let s = salutations {
2    print(g)
3    print(s)
4}

Output:
[“Howdy!”, “Hello!”]
[“Hi!”, “Hey!”]

Breaking it down

The syntax for unwrapping multiple optionals with a single if-let block is straightforward. It’s if followed by a series of let [constantName] = [optionalName] statements, separated by commas.

The output of this one is pretty much what you’d expect, too. The string form of the arrays is printed to the console window in Xcode or in your Playground.

Scenario 2: One array is initialized (non-nil), and the other is nil

Now suppose that the arrays looked like this:

1var greetings: [String]? = ["Howdy!", "Hello!"]
2var salutations: nil

1if let g = greetings, let s = salutations {
2    print(g)
3    print(s)
4}

Question: What do you think will be printed?

[“Howdy!”, “Hello!”] and “nil”
Just [“Howdy!”, “Hello!”]
Nothing will be printed

If you chose door number 3, you’d be correct.

The if-let block between the {}’s is only executed if both greetings and salutations are non-nil.

Takeaway

Unwrapping multiple optionals with a single if-let statement is pretty easy: if followed by a series of let [constantName] = [optionalName] statements, separated by commas.

The behavior is similar to using the && operator in a normal if condition. It’s like saying “if this optional is non-nil AND this optional is non-nil, then do this”

If you expect to work with one of the optionals in the list even if the other is nil, you’re going to need to split that up into multiple if-lets:

1if let g = greetings {
2    print(g)
3}
4
5if let s = salutations {
6    print(s)
7}

Force Unwrapping Swift Optionals: Code Smell!

Tue, 14 Jun 2016 03:54:57 +0000

Do you find your Swift code riddled with !‘s?

I’m becoming more and more uncomfortable with seeing ! throughout my Swift code. It’s just a matter of time before it’s going to bite me.

Often, I do it because it’s the “easy thing” to do at the time. But it’s dangerous.

Swift optionals are trying to help us. They force us to deal with the possibility of something not having a value.

By force unwrapping an optional with the ! operator, we’re declaring, “This will never be without a value”. Really? Never? Are you sure? Only a Sith deals in those kinds of absolutes.

When a function returns an optional, or a property is declared as optional, we are, at the very least, meant to assume that there is a possibility of nil lying underneath.

Therefore, I’m considering it a sort of “code smell” when I see it in my own code. It’s not too much to throw an if let or a guard let in there to handle the possibility of nil.

Two exceptions

Two exceptions to the code smell rule:

1 – IBOutlet and IBAction

IBOutlets and IBActions are force-unwrapped, but that’s because they get injected when the Storyboard is loaded at run-time. It’s assumed that these are connected and will be supplied when the scene is loaded. If they get unwired somehow, we want an instant crash so we know to go back to the Storyboard and re-wire things to the view controller.

2 – Required properties to be set in prepareForSegue

Along those same lines, I consider properties that must be set when navigating to a new view controller to be in the same category as an IBOutlet or an IBAction. I want to know right away if I forget to set those in prepareForSegue in the parent view controller. So I’ll often force unwrap the optional in the declaration so that there’s an as-immediate-as-possible crash if it’s not set.

Hopefully when you’re working with optionals from here on, you’ll take a second sniff when you see the ! operator.

Swift Optionals? Don’t Forget to Unwrap!

Sat, 26 Jul 2014 02:23:53 +0000

There is a compiler error that throws me off every time I see it. It takes the form,

‘ClassName?’ does not have a member named ‘memberName'

This can happen when you’ve declared a variable as an optional, but forget to unwrap that optional when you attempt to call a method on it.

For example, given this class definition:

 1class Bird {
 2	var family: String
 3	var color: String
 4 
 5	init(family: String, color: String) {
 6		self.family = family
 7		self.color = color
 8	}
 9 
10	func isSwift() -> Bool {
11		return self.family == "Apodidae" ? true : false
12	}
13}

If, say in a ViewController, I declare a variable that I intend to reference an optional Bird instance like this:

1var birdInstance: Bird?

And then I later initialize this variable with a Bird instance, perhaps in viewDidLoad() :

1birdInstance = Bird(family: "Apodidae", color: "Black")

If I attempt to invoke the isSwift method on the birdInstance later on, I’ll get a compiler error:

1println(birdInstance.isSwift())

error: ‘Bird?’ does not have a member named ‘isSwift'

This may seem pretty basic — after all, I declared the birdInstance as an optional and I know optionals need special treatment. How could I make this mistake?? Perhaps this is just a consequence of my current stage in life, trying to code in 15-30 minute spurts with my 1 1/2 year old running around, haha.

We all deal with this though: it’s fairly easy to write some code and come back to it later and not remember how you declared your variable in an earlier coding session. Then when you’re presented a message saying that your class doesn’t have a member named “___”, you immediately go to the class definition and see the function there, plain as day. It’s easy to spend 3-5 minutes scratching your head thinking, “What in the world??!” … And then you realize – it’s that optional declaration that you forgot to handle.

To fix this, of course, you can do any number of things, depending on your situation.

Force unwrap the optional and invoke the method:

1birdInstance!.isSwift() // Force unwrapped -- **CAUTION** make sure that birdInstance gets instantiated before you do this,&nbsp;or you'll get a runtime error

Employ optional chaining and invoke the method:

1birdInstance?.isSwift()

Declare the variable as implicitly unwrapped optional, then invoke the method later without extra exclamation or question marks:

1var birdInstance: Bird! // Implicitly unwrapped -- **CAUTION** make sure that birdInstance gets instantiated before you use it, or you'll get a runtime error
2birdInstance = Bird(family: "Apodidae", color: "Black")
3
4// Some time later, invoke isSwift
5
6println(birdInstance.isSwift())

A blog post by Peter Witham over at CompileSwift was the article that caused me to think, “OH! I haven’t done anything with my optional…that’s the problem”. Credit to you, sir, for your post!