Day 31: NSResponder actions
For 365Cocoa day three and four I’ve talked about NSClassFromString and its counterpart NSStringFromClass and noted how useful I find them and I gave a few examples. During the next few days I want to describe how in Sketch I handle toolbar and menu-item actions. These make heavy use of these dynamic functions and will demonstrate these functions in a broader context.
The first thing I have to mention is NSResponder and the responder chain. While I do not want to get into details today, it is important to know a bit about them. The responder chain is basicaly a linked; every responder links to the next responder and actions are thus forwarded along. The -firstResponder of a window will receive the action initially. If it responds to it, the action will be performed. If not, it’ll be forwared to the -nextResponder of the current responder and so forth till the end.
We start today with identifying the problem one faces with these actions. In the following days I’ll outline the road I took. The idea of a responder chain is a nice one but in increasingly complex UIs it has a few problems. The first reponder if a window is always the view which has focus at the moment. This can be a text view, a table or any other view which accepts first responder status. Now lets suppose we have a typical application with a source list on the left and something on the right. If we have added our method implementations to main view, we’ll get a beep if the source list has focus because no items in its responder chain respond to the method. A solution would be to take a responder that is in both responder chains but that’s not exactly good style either. I suppose the responder they both have in common is the NSWindow. Subclassing this and add your methods there far from good design I gather.
The second problem with this approach is that we’d end up with one gargantuan source file containing all our methods - even when only forwarding them to other classes. An added problem which I faced with this approach in Sketch was that many methods would be almost identical copies of another. This clearly violates the DRY principle so I really wanted to a good way to solve this. (To clarify why they were nearly identical copies; in Sketch I implemented a lot of functionality in ‘event handlers’ and many actions just tell the view to switch to a different event handler. Check back tomorrow for the first article outlining a possible solution.
