The responder chain is one of those parts of macOS and iOS development that may seem a little strange if you have not done any GUI programming before. Briefly, a responder chain is a hierarichy of objects that can respond to events. So, for example, a click or a tap might be passed up the responder chain until something responds to the action.
But, the responder chain is more than just UI events. We can pass our own custom events up the responder chain as well!
Objective-C
Under Objective-C this was pretty straightforward. Because Objective-C is based around the concept of passing messages (this is derived from Smalltalk, by the way) rather than calling methods, this is pretty easy. You might check to see if a responder responds to a specific message, or proceed up the chain. Something like this:
while(responder != nil) {
if ([responder respondsToSelector:selector]) {
[responder performSelector:selector withObject:sender];
break;
}
responder = responder.nextResponder;
}
Swift
Under Swift, things are a little bit different. Swift is much more traditional when it comes to methods and typing, and the predominent approach is to use Protocols to confirm adherence rather than testing for whether an object has a specific method. But this is where things get really fun.
In Swift, you can use an extension on NSResponder or UIResponder in
combination with generic types. This allows us to do something like this:
public extension NSResponder {
public func next<T>() -> T? {
guard let responder = self.nextResponder() else {
return nil
}
return (responder as? T) ?? responder.next()
}
}
(For the iOS version, change NSResponder to UIResponder).
Now, declare a protocol that your final target will adhere to. This is
equivalent to respondsToSelector in Objective-C.
protocol DoesSomething {
public func doSomething()
}
Now, when you’re ready to bubble your custom event, it’s a simple one-liner!
This is because most controllers, views and many objects descend from
NSResponder\UIResponder. You just call next() and test for adherence to
your protocol.
func clickHandler() {
(next() as DoesSomething?)?.doSomething()
}
You can even use this method to find a specific ancestor in the responder chain
by testing next() with the specific class name. You can also continue to
bubble the event up the responder chain (like if you have multiple classes in
the heirarchy that need to respond to the event) by calling next() again in
your implementation of doSomething().
Hat tip to this now archived blog post with this fabulous approach in it.
