Swift protocol and extensions for adding support to closures in UIKit classes. Extension support for UIButton, UIGestureRecognizer, UIBarButtonItem etc. Swift 3.0.

100%

Swift protocol and extensions for adding support to closures in UIKit classes. Extension support for UIButton, UIGestureRecognizer, UIBarButtonItem etc. Swift 3.0.

✓ Published0🌍 Public

Last edited Feb 4, 2017

Created on Mar 29, 2016

This example demonstrates a Swift protocol that adds closure-based event handling to UIKit classes, replacing traditional target-action patterns. Code extensions for UIButton, UIPageControl, UIGestureRecognizer, and UIBarButtonItem use the Closurable protocol to wrap callbacks in a ClosureContainer object, stored via objc_setAssociatedObject. The container exposes an @objc selector that invokes the stored closure, allowing UIKit to call the handler dynamically. The code pairs each UI component’s standard addTarget or initializer with custom convenience methods, keeping the call site concise. No external libraries are required; the implementation relies solely on Swift 3.0 and the Objective-C runtime.

AI-generated description

Similar vizzes

Loading thumbnail…

Examples how to use closures

This example shows two ways to define and call functions that accept closures in Swift. The first passes an inline closure that takes an integer and returns a string, producing a computed result. The second uses an escaping closure that returns a `UIViewController`, demonstrating how to instantiate a view controller lazily. The code relies on Swift’s closure syntax and the UIKit `UIViewController` class, with the second closure marked `@escaping` to allow storage beyond the function call.

MMoximillian

65% match

Loading thumbnail…

An eventing mechanism for Swift

This example demonstrates an eventing mechanism for Swift, showing how to create type-safe events with multiple handlers and automatic cleanup. It defines an `Event<T>` class that manages a collection of handler wrappers, allowing observers to subscribe and unsubscribe dynamically. The implementation uses the `Disposable` protocol for tear-down logic and the `Invocable` private protocol to abstract handler invocation, with `EventHandlerWrapper` holding a weak reference to the target to prevent retain cycles. The code highlights Swift’s protocol-oriented and generics features, as well as curried instance methods, to build a reusable notification system without relying on external libraries.

CColinEberhardt

61% match

Loading thumbnail…

Journey into PAT-land

This example shows a programmer’s repeated attempts to create a unified interface for dequeuing reusable cells across UITableView and UICollectionView in Swift, using protocols with associated types and generics. The code illustrates the progression from a simple protocol that fails to preserve type information, through generic and PAT-based approaches, to a final multiprotocol solution incorporating a parent protocol and Self-typed static methods. It highlights the Swift compiler’s constraints, such as lack of parametrized extensions and existential casting limitations, while referencing ProtoKit, UITableView, UICollectionView, and IndexPath.

MMoximillian

57% match

Loading thumbnail…

Example of how init/func behaves in protocols and protocol extensions

This example demonstrates how Swift handles `init` and `func` declarations in protocols versus protocol extensions. It defines two similar protocol pairs—one where `P1` declares both members, and another where `P2` is empty and relies entirely on its extension—to show that a struct’s own implementations always take precedence over those in the extension. The code creates instances of `S1` and `S2` and calls their methods, printing "S1 init"/"S1 func" and "S2 init"/"S2 func" respectively, proving that the extension’s fallback implementations are never invoked when the struct provides its own.

MMoximillian

56% match

Loading thumbnail…

Gist b7643abc7d460e1673981d3f41bb9b40

This example demonstrates a Swift language extension that optimizes the `reversed()` operation on lazy collections. It defines a `ReversedCollectionProtocol` for bidirectional collections, and an extension that lets reversing a lazy reversed collection return a lazy representation of the original, avoiding unnecessary materialization. The code uses Swift generics and associated types (`Elements.Base`) to express this optimization, and notes a fallback using parametrized extensions for Swift versions prior to 4.2.

MMoximillian

51% match

Loading thumbnail…

Gist af897f78753e7f850cce144cb3a1ce26

This example demonstrates a Sketch plugin interface with synchronized slider, input field, and stepper controls that all adjust the same numeric value. The code uses Objective-C with Apple's Cocoa and JavaScriptCore APIs, including `MOJavaScriptObject` for bridging JavaScript callbacks. It loads a user interface from a NIB file via `loadNibFile` and `NSBundle`, and shows how `sliderChange`, `inputChange`, and `stepperChange` actions keep the three widgets in sync. The `clickHello` method invokes a JavaScript function through `callFunctionWithArguments`, connecting the native UI to scripted behavior.

KKevinGutowski

50% match

Loading thumbnail…

Gist 402351

This example shows an Objective-C class definition, `ITCocoaWindowAdapter`, which subclasses `NSWindow` to manage a window reference and event handling. The code declares an `OpaqueWindowPtr` structure and an `OpaqueEventHandlerRef` to track the underlying Carbon window and event handler, alongside flags for focus searching and drawing via HIView. It includes an `NSGraphicsContext` for drawing operations. The snippet relies on the AppKit and Carbon APIs, specifically `NSWindow`, `NSGraphicsContext`, and opaque pointer types, to adapt Cocoa window behavior for legacy drawing and event processing. The visualization is a static code listing without data or rendering logic.

CCaged

50% match

Loading thumbnail…

Gist 6ec7e2d2e5b12c1bce0d09b7faa51ee2

This example demonstrates a key-value observing (KVO) binding mechanism in Swift, where changes to a property on one NSObject subclass (Foo.bar) automatically update a property on another (Zoq.fot). The code uses the Foundation framework, specifically the `observe(_:options:changeHandler:)` method with KeyPaths, and stores a `Disposable` object via `objc_setAssociatedObject` to manage observation lifecycle. Reassigning the target object (Zoq) triggers the `Disposable` deinit, which invalidates the observation and stops further updates, as shown by the printed deinit messages and unchanged `fot` values after reassignment.

MMoximillian

49% match