mikeash.com pyblog/friday-qa-2015-12-25-swifty-targetaction.html comments

overcyn - 2017-02-14 22:45:12

Tue, 14 Feb 2017 22:45:12 GMT

AppKit version updated for Swift 3...



let NSControlActionFunctionProtocolAssociatedObjectKey = UnsafeMutablePointer<Int8>.allocate(capacity:1)



class ActionTrampoline<T>: NSObject {

    var action: (T) -> Void

    init(action: @escaping (T) -> Void) {

        self.action = action

    }

    @objc func action(_ sender: NSControl) {

        action(sender as! T)

    }

}



protocol NSControlActionFunctionProtocol {}



extension NSControlActionFunctionProtocol where Self: NSControl {

    func setAction(action: @escaping (Self) -> Void) {

        let trampoline = ActionTrampoline(action: action)

        self.target = trampoline

        self.action = Selector("action:")

        objc_setAssociatedObject(self, NSControlActionFunctionProtocolAssociatedObjectKey, trampoline, .OBJC_ASSOCIATION_RETAIN)

    }

}



extension NSControl: NSControlActionFunctionProtocol {}

<\code>

sveinhal - 2016-01-04 08:56:08

Mon, 04 Jan 2016 08:56:08 GMT

One would also have to make sure to not reference the control from within the action closure, but use the passed argument instead. It is tempting to just use

button.setAction { _ in

    print("Action from: \(button.title)")

}

… rather than

button.setAction { button in

    print("Action from: \(button.title)")

}

And since the control holds a strong reference to the trampoline (through the associated object mechanism) and the trampoline may hold a strong reference to the control, by referencing the variable from the surrounding scope in the closure, this easily leads to retain cycles as well.

Jessy - 2015-12-28 21:35:20

Mon, 28 Dec 2015 21:35:20 GMT

I believe this to be very complicated. Instead, I store a weak-referencing "MultiClosure", and have each control be its own target.

Example usage:
textField.editingDidEndOnExit📡 += onEditingDidEndOnExit

Where onEditingDidEndOnExit is an "EquatableClosure".

Hit me up @jessyMeow on Twitter if interested.

Stephen Celis - 2015-12-26 19:31:46

Sat, 26 Dec 2015 19:31:46 GMT

There was an early discussion on swift-evolution about accepting closures wherever selectors appear. Joe Groff had an idea to address retain cycle concerns by using something like @convention(objc_selector) to enforce a context-free closure:

https://lists.swift.org/pipermail/swift-evolution/2015-December/000200.html

J - 2015-12-26 14:15:34

Sat, 26 Dec 2015 14:15:34 GMT

Max O: but now you're just back to the existing Cocoa target-action API...

Max O - 2015-12-26 00:08:01

Sat, 26 Dec 2015 00:08:01 GMT

There is a clear practical reason why original target-action pattern implementation creates weak relationship. But when converted to block-based API this weak semantics is no longer enforced by the API and becomes responsibility of the programmer which is bad. And implicit capture semantics of blocks/closures makes it hard to maintain and error-prone in practice – as per your note on retain cycles.

Given that we can solve 'stringly-typed' problem but still force weak relationship semantics:



class ActionTrampoline<T: AnyObject, C>: NSObject {

    weak var target: T?

    var method: T -> C -> Void

    

    let associatedObjectKey = UnsafeMutablePointer<Int8>.alloc(1)

    

    init(target: T, method: T -> C -> Void) {

        self.target = target

        self.method = method

    }

    

    @objc func action(sender: UIControl) {

        if let target = target {

            method(target)(sender as! C)

        }

    }

}



protocol NSControlActionFunctionProtocol {}

extension NSControlActionFunctionProtocol where Self: UIControl {

    func addTarget<T: AnyObject>(target: T, method: T -> Self -> Void, events: UIControlEvents) {

        let trampoline = ActionTrampoline(target: target, method: method)

        self.addTarget(trampoline, action: "action:", forControlEvents: events)

        objc_setAssociatedObject(self, trampoline.associatedObjectKey, trampoline, .OBJC_ASSOCIATION_RETAIN)

    }

}

extension UIControl: NSControlActionFunctionProtocol {}



class Controller {

    let button = UIButton()

    

    init() {

        button.addTarget(self, method: self.dynamicType.handleButton, events: [.TouchUpInside])

    }

    

    func handleButton(button: UIButton) {

        print("Action from \(button.titleLabel?.text)")

    }

}



let controller = Controller()

controller.button.sendActionsForControlEvents([.TouchUpInside])

Tobol - 2015-12-25 21:52:17

Fri, 25 Dec 2015 21:52:17 GMT

Hello Mike! Great article as always.

I think you have a bug in the UIKit version. You are always setting the associated object for the same key. If you try to assign an action for another event, target for the previous one will be deallocated:



let button = UIButton()

button.setTitle("my button", forState: .Normal)

button.addAction([.TouchUpInside], {

    print("TouchUpInside action from \($0.titleLabel?.text)")

})

button.addAction([.TouchDown], {

    print("TouchDown action from \($0.titleLabel?.text)")

})

button.sendActionsForControlEvents([.TouchUpInside])

button.sendActionsForControlEvents([.TouchDown])



Output:

TouchDown action from Optional("my button")

Alex - 2015-12-25 18:28:48

Fri, 25 Dec 2015 18:28:48 GMT

I think you can safely use `&` operator for keys, Apple uses it for KVO (note "global context variable"): https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/AdoptingCocoaDesignPatterns.html#//apple_ref/doc/uid/TP40014216-CH7-ID12