iOS why did apple put this code in its template?

[grandM]

So I'm using the master-view template. And there is something I do not get. In the detail part apple goes:

   @IBOutlet weak var detailDescriptionLabel: UILabel!
    if let label = self.detailDescriptionLabel {

                label.text = ...

    }

Why? Apple puts the label on the screen and even unpacks the label. So you're sure the label is present. Why does apple need the if let construction?

 

[Mascots]

I've never been too keen on the examples that Apple supplies in their template code; they tend to do some unappealing things and then leave it for years. If you were wanting good tips on development, I'd look through what they supply during previous WWDC's, it's a wealth of tips and content.

 

[grandM]

I've never been too keen on the examples that Apple supplies in their template code; they tend to do some unappealing things and then leave it for years. If you were wanting good tips on development, I'd look through what they supply during previous WWDC's, it's a wealth of tips and content.

so this if let construction is totally absolete?

 

[Mascots]

so this if let construction is totally absolete?

Obsolete? No, you've never needed to unwrap implicitly unwrapped optionals, however, because they can be optional, you can check their validity in the if-let context.

It looks like someone at Apple may have included it to emphasize that fact.

 

[grandM]

Obsolete? No, you've never needed to unwrap implicitly unwrapped optionals, however, because they can be optional, you can check their validity in the if-let context.

It looks like someone at Apple may have included it to emphasize that fact.

If it's implicitly unwrapped can it still be nil then?

 

[AxoNeuron]

If it's implicitly unwrapped can it still be nil then?

Yes.

Regular optionals are better in most situations, but in some situations (ie. interacting with Objective-C API's where a pointer may be nil) it's best to use implicitly unwrapped optionals.

 

[grandM]

Yes.

Regular optionals are better in most situations, but in some situations (ie. interacting with Objective-C API's where a pointer may be nil) it's best to use implicitly unwrapped optionals.

What is the use of unwrapping it implicitly if it can still be nil. That beats the entire purpose of implicitly unwrapped optionals?

 

[AxoNeuron]

What is the use of unwrapping it implicitly if it can still be nil. That beats the entire purpose of implicitly unwrapped optionals?

Because if you know for an absolute certainty that the variable won't be nil, then you don't have to write as much code if you use implicit unwrapping.

 

[grandM]

Because if you know for an absolute certainty that the variable won't be nil, then you don't have to write as much code if you use implicit unwrapping.

Agreed but in this example the if let is useless then for the UILabel is implicitly unwrapped

 

[Mascots]

Agreed but in this example the if let is useless then for the UILabel is implicitly unwrapped

Oh yeah, it really makes no sense since there is a 100% chance, programmer errors withstanding, UILabel will be set by Storyboard/A nib before it will ever be accessed by a method on the class.

A use that comes to mind is using NSManagedObjectContext within a UIViewController...

class DetailViewController: UIViewController {
    var moc: NSManagedObjectContext!
}

Set moc on the prepareForSegue: of the class which initiates the above, essentially guaranteeing the variable will be available for use just like any other non-optional. Swift includes a few ways to check against IUO's other than if-let for when you need to use them, as seen in Swift Guide on Assertions.

 

[grandM]

Oh yeah, it really makes no sense since there is a 100% chance, programmer errors withstanding, UILabel will be set by Storyboard/A nib before it will ever be accessed by a method on the class.

A use that comes to mind is using NSManagedObjectContext within a UIViewController...

class DetailViewController: UIViewController {
    var moc: NSManagedObjectContext!
}

Set moc on the prepareForSegue: of the class which initiates the above, essentially guaranteeing the variable will be available for use just like any other non-optional. Swift includes a few ways to check against IUO's other than if-let for when you need to use them, as seen in Swift Guide on Assertions.

Is it wise to pass the managedObjectController? I'm just redeclaring it in the destination VC?

 

[Mascots]

Is it wise to pass the managedObjectController? I'm just redeclaring it in the destination VC?

Yes, I would suggest passing along the pointer, rather than retrieving it from a singleton, in as many cases as possible. It makes controllers, which are hard enough to test already, a little more testable.

It also helps make view controllers more reusable, let's say to pass along a child managed object context when building a list in an editing view.

 

[eventailapp]

I do not know the state of all of the APIs but in early iOS8 an EKCalendarItem.title was a String! that could be nil, because Outlook (and only Outlook) could actually create an event without a title (not an empty title; no title).

This has caused me some funny crashes and it got fixed later. So, if you take implicitly unwrapped optionals from an API you do not control, I would suggest using the if let construct anyway.