On Sep 1, 2015, at 18:12 , Alex Hall <[email protected]> wrote: > > I'm not clear on the second option--the First Responder?
It’s a pretense, sort of, but it’s very simple when you know what’s really going on. When you connect a UI element to an action in a controller, the NIB element has an action selector (the name of the method to call) and a target link which points to the controller. To perform the action, the UI element performs that selector on that controller object. There may be some validation involved, but the responder chain is not used — the target is known in advance. When you connect a UI element to “First Responder” in IB, you are really leaving the target link nil, although the selector is still specified (which is how it’s different from not connected at all). To perform the action, the UI element asks the frameworks to look up the responder chain, starting from the current first responder, to see if there is an object that responds to the selector and is prepared to accept the action. If so, that object performs the action. (Look at the NSApplication method ‘sendAction:to:from:’ if you want to understand how this is implemented. The magic is hiding right there out in the open.) So, “First Responder” in IB is a placeholder element that represents whatever object will accept the action at runtime (in the context current at the time). IB aggregates all action methods it knows about — from everywhere in your app and in the frameworks classes — and pretends that the “First Responder” placeholder responds to them all, which is what allows you to connect any action to First Responder anywhere in your storyboard. Note also that there’s a “First Responder” in every scene in your storyboard. That effectively makes every action available from every UI element, across scene boundaries that actions cannot otherwise cross at design time, at the cost of deferring resolution to runtime, plus the conceptual cost of following what’s going on in IB. > Using appDelegate works, as I said, but it feels weird to split my UI code > between that file and my view controller. I get why I have to, and I know > that on OS X, it's more acceptable to put UI code in that file instead of a > dedicated view controller, but the setup seems awkward. Indeed, it still preferable to avoid splitting the code, but with storyboards you need to hook the action up via First Responder to achieve that. Then there’s no difficulty with having the outlets in the view controller itself. The reason this is messier on OS X is that in iOS you don’t really deal with global UI elements like menu items or windows. Nor do you typically have multiple top-level view controllers presented simultaneously — you generally segue between individual controllers instead. Unfortunately, when Apple brought storyboards to OS X, they didn’t provide any additional conceptual documentation (AFAIK) that explained how storyboards dealt with OS X’s extra complexity. _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
