On Mar 9, 2016, at 11:36 , Bill Cheeseman <wjcheese...@gmail.com> wrote: > > But don't I still need to use optionals if I declare the window controller or > content view controller instance variable in AppDelegate but don't set it > until later in the window controller's windowDidLoad() method? I am still at > risk of using the instance variable before its value has been set. (I could > solve that problem, or rather localize it, by not making it an instance > variable but instead a local variable where I actually use it, but the whole > point of my current exercise is to have a chain of storyboard scene cross > references.)
As a mere technical detail, your reference to the window controller has to be nil initially. However, it’s necessarily going to be set by the time you actually reference it, so that’s a good candidate for an implicitly unwrapped optional (“!”) instead of a plain optional (“?”). Why “necessarily”? Because: — NSApplicationMain is documented to instantiate the main storyboard. — What NSApplicationMain does occurs before applicationDidFinishLaunching. (Some of what it does might occur before applicationWillFinishLaunching, too, but that doesn’t make any difference here.) — Therefore your windowDidLoad, where you will set a non-nil value for the window controller reference, will execute before applicationDidFinishLaunching. — Therefore in applicationDidFinishLaunching or anytime later, you can safely refer to your window controller. > You say you would make it a static property of the window controller class. > But I need to refer to it in AppDelegate. So, I guess you're saying I can > refer to a static class variable from anywhere. This is what the Swift > language guide refers to as a "type property," right? I see from the guide > that I can refer to it from any class in my application as a property of the > type as opposed to a property of an instance. It strikes me that this is > exactly what I need. And it feels so much more appropriate to place the > reference in the window controller itself, instead of in AppDelegate. (So, a > Swift "singleton" class can have a type property that refers to its own sole > instance? And that type property is accessible everywhere in the application? > Weird. And amazingly convenient. So much still to learn about Swift!) Yes, that’s a type property. It’s the same thing as Obj-C class methods like “[NSApplication sharedApplication]” except that it’s a genuine property, which can’t be done at the class level in Obj-C. So you can think in terms of singletons, or you can think of global variables (encased within a class’s “namespace”) or you can think of it as a property of the class object, whichever works for you. It’s accessible everywhere, subject to the normal access controls. It can be a property of the app delegate if you want (or a class property of AppDelegate if you want). The decision probably depends on which class you feel is in control of WC instances. > It is uncomfortable, but storyboards are making lots of things uncomfortable > -- or, rather, they are forcing me to do a lot of rethinking of old > principles. I find myself spending a lot of time wondering which scene to use > for code that in the old days used to get thrown into a single, massive > window controller class where worries like this did not intrude. In this > project, I am making heavy use of view controllers to break my code down into > much smaller pieces, which storyboards encourage. In addition, having a lot > of scenes in a single storyboard, as opposed to multiple nib files, > encourages one to think that code can be put anywhere. That's why I'm > inventing all the ways I can think of to create workable cross references > between scenes. And Apple encourages that in the WWDC 2014 video by repeating > way too many times that you really have to implement > prepareForSegue(_:sender:) all over the place if you use storyboards. I guess > it has always been considered more acceptable for view controllers to cross > reference one another, as opposed to model classes and view classes that are > supposed to be as reusable as possible. It sort of doesn’t matter where the code goes, apart from relatively humble considerations (e.g. it’s always been horrible that WCs tend to get bloated with action methods and support code; using VCs allows that to be split up into pieces of more reasonable size). I think that if your background is historically OS X, WCs will seem more natural — because VCs were awkward when they weren’t automatically in the responder chain. If your background is iOS, VCs seem more natural. The big difference is that you can’t create cross-scene connections in IB. But I don’t see any difficulty with using WCs to mediate between view controllers in a fixed hierarchy. I think passing references to information via prepareForSegue is more useful for transient or ad-hoc relationships between view controllers, such as displaying a sheet. Storyboard do require a lot of fumbling around in the dark on OS X, because there’s no platform-appropriate lore that tells us how to use them. Not yet. I also have a sneaking suspicion that there’s another shoe to drop, perhaps that window controllers are going to be phased out. (Actually, I don’t think that’s exactly what’s going to happen. My prediction is that we’re going to get some version of UIKit on OS X, which will coexist with AppKit for a few years, after which AppKit will basically disappear.) _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
