iOS Delegates — The GodFather Way

Its a red phone, its ringing, gotta answer!

Ah, the joys of learning online — when you want a simple explanation of a concept or something like delegation in iOS, but what you get is something that leaves you more confused than before you started reading. Enter this.

When I started to learn delegation, this topic drove me absolutely nuts in trying to understand it. Sure, if you’ve done some iOS work before, you’ll have heard of delegates, maybe even typed it a few times, but what is a delegate exactly? Well, let’s find out together.


I’m going to start by explaining this so simple that anyone could understand the concept, so forgive me for being over-simplistic. I’ll then back it up later with a more accurate explanation.

Don’t call us, we’ll call you

Imagine the GodFather. You go into see him, you ask him for something and he gives you it; a new gun perhaps, or some access to stuff you didn’t have access to before. Before leaving though he says: ‘Before you go there might be a day, and this day may never come, but if it does, I may call on you for your services.’ Aka: ‘don’t call us, we’ll call you’.

Ominous indeed: what have you just signed yourself up for I wonder? Anyway, the point is delegation is a lot like this. Instead of you downloading someone else’s library and importing it and then having access to their functions, instead you will write your own implementations of the functions (what functions?) the functions in the contract. You’ll guarantee that when required, you’ll answer that phone and answer the call of duty you promised you would do.

This is the essence of being a delegate. You’ve been assigned a task and promised to implement something that will be called later on.

Okay, so that concept should be pretty simple to grasp right? So how do we apply that to code? Just before we dive in, let me say one tiny thing: the delegate is the function that will be called (and you will have to guarantee that it’s all good and will do something) and the delegator is the one who will call you ‘when the time arises’.


Now that we’ve gotten a high level understanding of this lets write some code and come back to why this makes sense to use as it is uses heavily in iOS and macOS.

protocol godFatherContract {
func willCallThisFunctionLaterSoItBetterBeLegit()
}

So the first thing you’ll see in our Swift example above is the use of a protocol. This always confused me at first, but essentially if we’re going to hand over a contract (delegate a contract somewhere else) in our program, then we need to use a protocol. It is iOS’s way of writing a binding contact: no escape! Remember the GodFather.

This protocol is called godFatherContract — whosoever signs up to this must implement the willCallThisFunctionLaterSoItBetterBeLegit() function. They can make it do whatever they want, but it must be present in the implementation.

class SomePoorGuy {
}

SomePoorGuy comes along. The poor guy is in need of ‘some services’ so he signs up to the contract.

class somePoorGuy: GodFatherContract {
// Notice that he now conforms to godFatherContract Protocol?
// So where's the function that he must answer to?
// Read on
}

Now the SomePoorGuy class is signed up. We have to make him conform to the protocol by having a willCallThisFunctionLaterSoItBetterBeLegit function.

class SomePoorGuy: GodFatherContract {
func willCallThisFunctionLaterSoItBetterBeLegit() {
   print("Must... go... do... duty... now....")
  }
}

Congratulations you’ve conformed this poorGuy to the GodFatherContract protocol.

BUT HOW DOES THIS RELATE TO DELEGATES I’M SO CONFUSED???

Excellent. Now let me explain the part where I never understood the connection:

So we have a contract, some poor guy who is waiting on the call, but who is going to call him? Who is the delegator? Enter the GodFather himself:

class GodFather {
var delegate: godFatherContract?

func makeThatCall() {
   delegate?.willCallThisFunctionLaterSoItBetterBeLegit()
  }
}

(Please note all code for these tutorials is available here on github)

Here we have the GodFather. He has an optional variable called delegate who is guaranteed to be on the other end of that line if he calls. Or does he? Well… Its an optional isn’t it? You see, people who do things for the GodFather tend to vanish… a lot. So there may be one or they may not.

If there is one, he’ll makeThatCall(). If there is a delegate he will answer. Or to put it in coding terms: if the delegate optional is unwrapped and isn’t nil, then it will have a function called willCallThisFunctionLaterSoItBetterBeLegit() -> Call it!

The thing is — we now have all 3 parts in place: A contract (the protocol), a Delegate (the PoorGuy) and the delegator (the GodFather). So how do we set the delegate; how does he volunteer for duty?

// Lets make a PoorGuy
let poorGuyJimmy = somePoorGuy()
// And a GodFather
let almightyGodFather = GodFather()
// Lets set the poor guy as the delegate!!!!
almightyGodFather.delegate = poorGuyJimmy // hooray!
// Now let's make the call he wished he'd never had
almightyGodFather.delegate?.willCallThisFunctionLaterSoItBetterBeLegit()

So as you can see we instantiate our PoorGuy and our GodFather and we set the PoorGuy as the delegate. When the GodFather tries to make the call he finds in his phonebook an instance of the PoorGuy! He’s made the call!


Phew, so that was intense and all very dark and masculine. However you’ll have seen this line before if you’ve even worked with UITableViews or UICollectionView:

CollectionView.delegate = self

You are telling the delegator: yeah, I’ve got a delegate and she’ll be ready when you call her. You’re saying: ‘We’ll call you(r function)” as opposed to you calling functions yourself.

But why is this useful?

The reason this is useful is that you can have some functionality tucked away in a class that is only there if something guarantees they will conform to your protocol. Remember, the PoorGuy was poor, but he wasn’t dumb. He got something out of it too. He got money, or some other functionality he never had before. With protocols you get a kind of composition (like functionality passed on) so there are perks, but responsibilities.

These perks are passed on through messages. So if you need a View Controller to communicate with another one, a great way to do this is delegates. You might not be able to think of a reason why you would want to do this just now, but classes being able to communicate data or messages across to each other is VITAL in keeping some sort of order to projects (especially when they get larger) and is a way of maintaining sanity for you as a programmer.


Hopefully that makes some sense to you. The best way is to get out there and use delegates. Remember — you need a contract, a delegate and a delegator to use the delegate pattern.