why did apple put this code in its template?

Discussion in 'iOS Programming' started by grandM, Dec 14, 2015.

  1. grandM macrumors 6502a

    grandM

    Joined:
    Oct 14, 2013
    #1
    So I'm using the master-view template. And there is something I do not get. In the detail part apple goes:
    Code:
       @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?
     
  2. Mascots macrumors 65816

    Mascots

    Joined:
    Sep 5, 2009
    #2
    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.
     
  3. grandM thread starter macrumors 6502a

    grandM

    Joined:
    Oct 14, 2013
    #3
    so this if let construction is totally absolete?
     
  4. Mascots macrumors 65816

    Mascots

    Joined:
    Sep 5, 2009
    #4
    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.
     
  5. grandM thread starter macrumors 6502a

    grandM

    Joined:
    Oct 14, 2013
    #5
    If it's implicitly unwrapped can it still be nil then?
     
  6. AxoNeuron macrumors 65816

    AxoNeuron

    Joined:
    Apr 22, 2012
    Location:
    The Left Coast
    #6
    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.
     
  7. grandM thread starter macrumors 6502a

    grandM

    Joined:
    Oct 14, 2013
    #7
    What is the use of unwrapping it implicitly if it can still be nil. That beats the entire purpose of implicitly unwrapped optionals?
     
  8. AxoNeuron macrumors 65816

    AxoNeuron

    Joined:
    Apr 22, 2012
    Location:
    The Left Coast
    #8
    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.
     
  9. grandM thread starter macrumors 6502a

    grandM

    Joined:
    Oct 14, 2013
    #9
    Agreed but in this example the if let is useless then for the UILabel is implicitly unwrapped
     
  10. Mascots macrumors 65816

    Mascots

    Joined:
    Sep 5, 2009
    #10
    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...

    Code:
    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.
     
  11. grandM thread starter macrumors 6502a

    grandM

    Joined:
    Oct 14, 2013
    #11
    Is it wise to pass the managedObjectController? I'm just redeclaring it in the destination VC?
     
  12. Mascots macrumors 65816

    Mascots

    Joined:
    Sep 5, 2009
    #12
    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.
     
  13. eventailapp macrumors member

    eventailapp

    Joined:
    Jan 7, 2016
    #13
    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.
     

Share This Page