On Feb 16, 2015, at 12:39 PM, Bill Cheeseman <wjcheese...@gmail.com> wrote:
> Although I follow Mike Ash's advice, I have separate MainMenu.xib and > MainWindow.xib files instead of a single window.xib file. My MainMenu.xib > contains the application's menu bar but no window. The construction of this sentence suggests that this arrangement is contrary to Mike's advice. Rather, it is in concordance with Mike's advice. He clearly says that the MainMenu NIB should _not_ include a window: "MainMenu.xib is a special case: it should contain File's Owner, which is the NSApplication instance, the menu bar, the application delegate, any other objects related to these, but _no NSWindow_ instances." (Emphasis in the original.) > In AppDelegate's applicationDidFinishLaunching delegate method, I set the > AppDelegate's mainWindowController and window instance variables to the new > window controller and to its new window, so that the AppDelegate can refer to > them as needed. I recommend that you declare a read-only property (possibly private) for the mainWindowController. Implement the getter yourself to create the controller if it hasn't already been created and return it. Use that property (i.e. self.mainWindowController) to access the controller and use the window property of the controller (i.e. self.mainWindowController.window) to access the window. This eliminates redundancy, which is an opportunity for things to get out of sync, and makes sure that the controller and its window always exist where they are needed. For example, if an application delegate method is called before -applicationDidFinishLaunching: and tries to manipulate the controller or its window, it will work rather than failing silently. > In order to further compartmentalize my code, each of the more complex views > in the window, such as the tab view items, has its own view controller and > .xib file. Each view controller is instantiated, the view in the .xib file it > owns is loaded, and the view is positioned in the window, all by suitable > methods called in the main window controller, typically in the case of tab > view items in response to the user clicking a tab or button or choosing a > menu item. The main window controller saves instance variables referring to > each view when the view is instantiated so that it can communicate with them. > In addition, each view gets a reference back to the window controller when > the window controller sets the associated property of the view right after > instantiating it (or in a custom init method). Again, I recommend that you create these view controllers on demand in the getters of read-only properties. And don't keep separate track of the views, just use the view property of the controllers. If your view controllers need a reference back to the window controller, that suggests that they haven't been properly encapsulated. They are too closely coupled. Or, at least, that's the case if the view controller knows the class of the window controller. It's reasonable if the view controller declares a general delegate protocol and the window controller adopts that protocol and is acting as the delegate for the view controller. A view controller and its view should be reusable in different contexts, or at least designed as though it might be. Regards, Ken _______________________________________________ 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
