Delegation on Andrew Bancroft

How Delegation Works – A Swift Developer’s Guide

Thu, 09 Apr 2015 01:43:55 +0000

Updated on October 11, 2016 – Swift 3.0

Delegation can be a difficult topic to wrap your head around. I found it easiest to break up posts on the topic to help readers who are new to the pattern grasp the concepts a little better. First, I analyzed what delegation is in “What is Delegation – A Swift Developer’s Guide”. If you’re looking for the “what is it?” behind the “how does it work?”, I recommend giving that first article a read.

Once the terminology is unpacked and a high-level overview of delegation as a design pattern is understood, the next logical place to turn is to the question, “How does delegation work?”. That is the focus of this article.

Introducing the players

For delegation to occur in software, you’d have a situation where one class (a delegat_or_ class) would give control or responsibility for some behavioral logic to another class called a delegate.

So how does one class delegate behavioral logic to another class? With iOS and Swift, the delegation design pattern is achieved by utilizing an abstraction layer called a protocol.

A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality.

Protocols as abstractions

I used the fancy term “abstraction layer” prior to the quote. What is that all about?

Protocols are an “abstraction”, because they do not provide implementation details in their declaration… Only function and property names. Like an outline, or as Apple puts it, a blueprint.

Protocols as blueprints

With a single blueprint, there can be many homes constructed. The fine details of their construction may differ, but in the end, houses of some similarity that satisfy the blueprint’s specifications are built.

So, too with a protocol: Many classes can be built that follow the protocol’s specifications. At the end of the day, the fine details of each class’ implementation (the stuff between the curly braces { ... }) may differ, but if they adopt the protocol, they’ll be similar in at least the fact that they provide the named behavior it specified.

Protocols as contracts

Another analogy from the legal world is popular for describing protocols: Protocols are similar to contracts. It’s this contractual idea that actually makes the most sense to me when it comes to delegation.

A contract is the “thing” in the middle of two parties who are trying to negotiate a deal. To one party, the contract is a guarantee of some terms that will be satisfied. To the other party, the contract is a set of obligations.

In the delegation design pattern, protocols serve the same kind middle-man role as a contract. To the delegat_or_ class, the protocol is a guarantee that some behavior will be supplied by the other party (the delegate). To the delegate class, the protocol is a set of obligations – things it must implement when it “signs the contract”, or in Swift terms, “adopts the protocol”.

While the person signing the contract probably gets something out of the deal, the focus in the analogy we’re making to protocols and the delegation pattern is on the person on the guarantee end.

That person, being guaranteed by the contract that certain terms will be executed by the person who signs the deal, is free to make decisions and take action based on that promise.

So, too with the class delegating to another class. The delegat_or_ class can make perform actions (call methods defined by the protocol) or make decisions (access properties defined by the protocol to use in its logic).

Listing the players

Stepping back from this description, we see three players involved:

A protocol defining the responsibilities that will be delegated
A delegat_or_, which depends on an instance of something conforming to that protocol
A delegate, which adopts the protocol and implements its requirements

Visualize the players

As you can see, there are a few moving parts to delegation. Sometimes it helps to visualize the players involved in the strategy. I created the following diagram for an analysis I wrote on NSNotificationCenter vs Delegation, but I think it gets the point across for this blog entry as well:

An example in code

Hopefully the explanation so far has provided some good groundwork to sort out how to accomplish the delegation design pattern in code. So how does it all get wired up?

Setting up the delegator

A delegat_or_ class typically defines a variable property with the word “delegate” somewhere in the name (oftentimes the property is simply named delegate if that’s explanatory enough). The Type of the variable property is the key to it all. The variable will be of Type whatever-you-named-your-delegate-protocol. So if I named my protocol MySpecialDelegate, I’d specify the Type of the delegate property to be MySpecialDelegate.

Setting up the delegate

The delegate class is what adopts the protocol and implements its requirements. In the class declaration, the name of the protocol(s) that the class intends to adopt are listed separated by commas after the name of the superclass (if the class inherits from a superclass):

class MyClass: SuperClass, Protocol1, Protocol2 { ... }

When the delegat_or_ class gets initialized, a second step is often to immediately assign an instance of the class that’s adopted the delegate protocol to its delegate property so that everything is “wired up”.

Delegation in practice

Working with the delegation pattern in practice usually involves interacting with the protocol from the delegate end of things. Most of the time, we’re working with Apple’s APIs (such as a UITableView or just about any other UI control they provide). We typically only require knowledge of the protocol’s definition so that the class we choose as our delegate can implement the right functions.

Complete example

There may be some situations where you may decide to follow Apple’s lead and use the delegation design pattern for your own code. Maybe you’re making a special UIView subclass or a special picker control (much like UIImagePickerController). Or maybe you’re into game development and would like to communicate from your SKScene back to the View Controller. These are just a few that came to mind, but they all present possibilities for utilizing the delegation strategy.

To give a simple example, suppose that we’ve decided to create a class to encapsulate all of the logic for a special rating picker control. We’d like to offer the ability to customize the picker some by allowing the user of our control to specify a preferred rating symbol. We’d also like to provide a feedback loop to notify the user of our control when certain events have occurred. Delegation is a great tool to provide both customization options and communication between classes. What would this example look like in code?

Create the protocol

First, the protocol:

1protocol RatingPickerDelegate {
2    func preferredRatingSymbol(picker: RatingPicker) -> UIImage?
3    func didSelectRating(picker: RatingPicker, rating: Int)
4    func didCancel(picker: RatingPicker)
5}

Notice how this protocol definition allows both the customization point and the feedback loop we were hoping for. It’s always nice for the delegate to have access to the public API of the instance calling its methods, so the RatingPicker (or UITableView or UIScrollView or whatever) is often passed along as an argument.

Create the delegator

With the protocol defined, our RatingPicker (the delegat_or_ in this case) can now set itself up to use that protocol:

 1// Disclaimer:  There is much more logic that would go into a real UIView subclass or a picker control in real life
 2// This example is contrived and is only meant to serve as a "shell" of what code could look like
 3// that uses a delegate within its implementation
 4
 5class RatingPicker {
 6    weak var delegate: RatingPickerDelegate?
 7    
 8    init(withDelegate delegate: RatingPickerDelegate?) {
 9        self.delegate = delegate
10    }
11 
12    func setup() {
13        let preferredRatingSymbol = delegate?.preferredRatingSymbol(picker: self)
14        
15        // Set up the picker with the preferred rating symbol if it was specified
16    }
17    
18    func selectRating(selectedRating: Int) {
19        delegate?.didSelectRating(picker: self, rating: selectedRating)
20        // Other logic related to selecting a rating
21    }
22    
23    func cancel() {
24        delegate?.didCancel(picker: self)
25        // Other logic related to canceling
26    }
27}

The delegate property is strongly typed to be a RatingPickerDelegate.

Since it’s optional here in this implementation, the delegate is not absolutely essential for the RatingPicker to work. If it were essential, we’d parameterize init and assign it during initialization.

I’ve used optional chaining to get at the delegate's methods if the delegate isn’t nil.

Choosing the delegate

Choosing the delegate class is the final decision to make. It’s not uncommon for a View Controller to take up the responsibility of being a delegate. In “Pick a Delegate, Any Delegate”, I attempted to show how it’s not necessary to use the View Controller as your one stop delegate shop. For this example, I’ll avoid giving the View Controller more responsibility than it needs and I’ll create a simple handler class to assume the delegated responsibilities:

 1class RatingPickerHandler: RatingPickerDelegate {
 2    func preferredRatingSymbol(picker: RatingPicker) -> UIImage? {
 3        return UIImage(contentsOfFile: "Star.png")
 4    }
 5    
 6    func didSelectRating(picker: RatingPicker, rating: Int) {
 7        // do something in response to a rating being selected
 8    }
 9    
10    func didCancel(picker: RatingPicker) {
11        // do something in response to the rating picker canceling
12    }
13}

Wrapping up

Once the terminology of delegation is unpacked, understanding how it works is the next logical step for grasping the design pattern as a whole. Here we explored all the players involved in the strategy and related protocols, which are integral to the strategy, to some real-world analogies. Finally, we took a look at how delegation works in practice, and demonstrated each role in delegation with code.

What is Delegation? – A Swift Developer’s Guide

Fri, 27 Mar 2015 03:29:01 +0000

Of the major design patterns that are prevalent in iOS development, delegation is one that appears quite often. For many developers entering app development for the iOS platform, dealing with delegates is a new concept. It certainly was for me.

In my analysis of NSNotificationCenter vs Delegation, I wrote some about delegation, but only in comparison to how NSNotificationCenter works. I haven’t yet given delegation dedicated time and analysis, but I intend to do so now.

My aim in this blog entry is to try and make some sense out of the question, “What is delegation?”. Explore with me…

What is the delegation design pattern?

To read that “delegation is a design pattern that [insert explanation here]” never really clicked with me. Many who are new to programming have not dealt extensively with “design patterns”, so it doesn’t always suffice to define delegation in those terms.

I suspect that since Swift has lowered the barrier to entry for iOS development, many who are new to the platform are also new to coding in general, so here’s my attempt to explain what clicked for me regarding what delegation is:

Design pattern

First, take the phrase “design pattern”.

Design implies architecture. It connotes a strategy for organizing something. Design conveys the method by which components will work together to accomplish an end.

Pattern implies that there is some repeatable process that has honed in around a common thread… a common practice… a predictable method for doing something. “Pattern” gives the impression that such a practice has converged over time into something that is now well-known, well-understood, and commonly used. I imagine a sort of “survival of the fittest” approach to process and practice. Things that didn’t converge or that were weaker in the real world fell away and the strongest survived into this thing we call “pattern”.

A design pattern in software terms, then, is a method for architecting, strategizing about, and organizing an application’s code in such a way that has been found to be commonplace, repeatable, and practically sound over time.

Delegation

Now take the word delegation. Three things come to my mind:

The verb, “to delegate”, meaning “to give control”
The noun, “a delegate”, meaning “a person acting for another”
The made-up noun, “a delegat_or_”, or more properly, a principal, meaning “a person who delegates to another”

In the real world, the word delegation encapsulates relationship and responsibility. A delegator/principal (noun) would delegate (verb) control or responsibility to another person called a delegate.

How could we map this to software? Well, it actually falls in line quite nicely.

Rather than people, we’re dealing with instances of classes (or other data structures like structs, but I’m just going to keep it simple and say “class” to encapsulate the idea). For delegation to occur in software, you’d have a situation where one class (a delegator/principal class) would delegate control or responsibility, here meaning behavioral logic, to another class called a delegate.

How is delegation used?

So yes… delegation is a design pattern. It’s a design pattern that exists on other platforms, but it is one that has been heavily adopted by Apple and is ubiquitous throughout the iOS APIs. It’s a design pattern that shifts responsibility from one class to another, thereby creating a separation of responsibilities and concerns. But what kinds of responsibilities and concerns? How is delegation used in practice?

Communication

In practice, delegation is most often used as a way for one class to communicate to another class. Observing some of the actions that delegates perform from Apple’s own APIs give us clues about this. Take the following samples from UITableViewDelegate as an example:

tableView(_:_will_SelectRowAtIndexPath:)
tableView(_:_did_SelectRowAtIndexPath:)
tableView(_:_did_HighlightRowAtIndexPath:)

Or how about a sampling from UIScrollViewDelegate:

scrollView**Did_Scroll**(:)
scrollView**WillBegin_Dragging**(:)
scrollView**WillEnd_Dragging**(:withVelocity:targetContentOffset:)
scrollView**DidEnd_Dragging**(:willDecelerate:)

My observation of Apple’s APIs indicates to me that one of the intended uses for delegation is to allow one instance to communicate back to some other instance that something will/did happen. The table view or scroll view delegates the opportunity to perform some action in response to some lifecycle event to another class, namely, its delegate.

It’s also worth noting the scope of the communication that delegation is intended to be used for. Whereas NSNotificationCenter fits the need for one instance to broadcast a message intended for more than one listening instance, delegation fits the scenario where an instance only needs to send a message to a single listener (the delegate).

Customization

Another common usage for delegation is to provide a delegate instance the opportunity to customize certain aspects of the delegat_ing_ instance’s internal state. Once again, clues from a few of Apple’s APIs shed some light on this usage scenario. Let’s look at UITableViewDelegate first:

tableView(_:heightForRowAtIndexPath:)
tableView(_:editActionsForRowAtIndexPath:)
tableView(_:indentationLevelForRowAtIndexPath:)
tableView(_:shouldHighlightRowAtIndexPath:)

These are all customization-points that a UITableView allows its delegate to have a say in. Some of the methods are so important that the table view can’t display itself unless it gets this information from its delegate. The point here is that the table view is shifting responsibility for the implementation of that logic off to its delegate, allowing for greater controlled flexibility and customization.

Wrapping up

With delegation being such a heavily utilized strategy for organizing an iOS application’s logic, understanding what it is becomes key concern. In this article we unpacked the terms “design pattern” and “delegation” to get a grasp of why those words were chosen to describe the strategy. Finally, we looked at how the delegation pattern is used in practice, observing that two common use-cases for delegation: class-to-class communication and customization.

Pick a Delegate… Any Delegate… On Clean View Controllers in Swift

Wed, 27 Aug 2014 04:43:29 +0000

The delegation pattern is ubiquitous in iOS development – the pattern is a “core competency” for developing in Cocoa, and if you program with the iOS SDK for any length of time and you’ll end up writing some code that resembles someInstance.delegate = someDelegate.

One of the toughest things that I’ve experienced is choosing what someDelegate is. All too often, a View Controller ends up being assigned the responsibility of being the delegate for everything in its hierarchy. My question is: Is there a cleaner way?

Let’s pick up on the example I proposed in my recent post about sending e-mails in-app. For “quick and dirty” pragmatism, I just crammed everything into the View Controller with the promise of coming back and (hopefully) showing a cleaner way. Here is a quick link to example posed before if you’d like to review it before proceeding.

What if…

What if we could make some adjustments so that the View Controller was trimmed down to the example on the right (click for larger view):

I’ve created a fully-working example on GitHub if you’d like to download it and play.

So the question at hand: Is the class labeled “Clean Example” preferable (ie, better)? First, let’s explore how I accomplished the “clean” View Controller. Then I’ll tip my hand on and share what I like about this approach…

EmailComposer

In order to accomplish the self-declared Clean View Controller above, I placed all of the configuration processes and the delegate method for the MFMailComposeViewController in a new class called EmailComposer. It should look familiar if you recall the previous example:

 1import Foundation
 2import MessageUI
 3
 4class EmailComposer: NSObject, MFMailComposeViewControllerDelegate {
 5    // Did this in order to mitigate needing to import MessageUI in my View Controller
 6    func canSendMail() -> Bool {
 7        return MFMailComposeViewController.canSendMail()
 8    }
 9    
10    func configuredMailComposeViewController() -> MFMailComposeViewController {
11        let mailComposerVC = MFMailComposeViewController()
12        mailComposerVC.mailComposeDelegate = self
13        
14        mailComposerVC.setToRecipients(["someone@somewhere.com"])
15        mailComposerVC.setSubject("Sending you an in-app e-mail...")
16        mailComposerVC.setMessageBody("Sending e-mail in-app is not so bad!", isHTML: false)
17        
18        return mailComposerVC
19    }
20    
21    // MARK: MFMailComposeViewControllerDelegate Method
22    func mailComposeController(controller: MFMailComposeViewController!, didFinishWithResult result: MFMailComposeResult, error: NSError!) {
23        controller.dismissViewControllerAnimated(true, completion: nil)
24    }
25}

So literally, the only thing I did is

Cut the function definitions for configuredMailComposeViewController, and the MFMailComposeViewControllerDelegate method.
Paste them into the new EmailComposer class, which inherits from NSObject (a requirement for this particular delegate protocol’s conformity), and conforms to the MFMailComposeViewControllerDelegate protocol.
Adjust my View Controller to create an instance of EmailComposer , obtain a configured MFMailComposeViewController, and present it whenever the user taps on a button in my UI.

Conclusions

The View Controller in its final version is focused. It’s primary concern is presentation and handling of user interaction with the View itself, rather than needing to worry with configuring an MFMailComposeViewController and its delegate callback.
EmailComposer is less of a hassle to test, in the sense that I no longer need to instantiate a View Controller in my XCTestCase class just to test my MFMailComposeViewController stuff. It’s a real pain to test an actual View Controller instance, so I like that I can easily create an instance of EmailComposer and test away without the bulk.
No need to import MessageUI in my View Controller.

All in all, this is the cleanest, simplest, most balanced solution (that I could think of) to factoring out some logic to another class, so as to make my View Controller as clean as possible.

The goal was to make sure the appropriate responsibilities are assigned to the right classes. Presentation logic is all in the View Controller. Configuration and delegate callback implementation is done in EmailComposer.

I’m thinking through applying this same idea to other more complicated examples (UITableViewDataSource and UITableViewDelegate come to mind), and I think it would do us a lot of good to strategize on how to avoid making the View Controller the “catch-all” delegate / data source class for everything that’s currently on the screen_._

Hopefully these thoughts spark some ideas in the Swift community. This post has already been revised slightly based on feedback that I’ve received from folks on Twitter. If you have additional ideas in regards to choosing the right delegate, holler my way! I’d love to hear from you.

Thanks for reading.