iOS Protocols — Why you should learn them

Wish I was this age again!

If you’re new to iOS, one of the things which can be a tiny bit strange is getting used to using, and later creating, Protocols. This is a super-easy introduction and over of Protocols for those who are not familiar with them.

The best way to learn something new is to connect it to something you already know. If you hear the word ‘protocol’ though it probably reminds you of some stale requirement you have to perform in the event of a situation at work, or in contrast something an Android would say in Star Trek. (We do all love Data though).

So to help you understand their function in iOS lets make a high-level overview of their real-world usage in a day-to-day situation.

In iOS when you make a class, it can only inherit from one superclass. That means that you get all the goodness from a UITableViewCell when you inherit it’s functionality, but what if you don’t want all of it or if you want more than is on offer from the superclass? Can you inherit from two classes? Not in iOS. You are limited to one superclass meaning that in some situations you might have to write functionality on your own (which is fine).

Imagine writing something similar to UITAbleViewCell on your own. It may not sound that complex, but it is extremely powerful under the hood and is no mean feat to create something similar.

Enter protocols. A way of adding functionality to many classes is via protocols. They provide a kind of agreement between the conforming class that ensures that standards are met in order to implement them.

I’ve always thought of protocols as a kind of composition of functionality and in this case that is exactly what they are. You can conform to many, many protocols if you wish and it kind of heaps up functionality as you go.

Imagine you have an ImageView and you want to create a way to connect to a URL when that image is tapped. You could just write that in your ImageView class, right? Sure, but what if you wanted to do something similar somewhere else in the app? Maybe it’s a good idea to have a protocol that allows you to connect to the web and you can implement that in LabelViews as well?

Let’s briefly look at a simple Protocol:

protocol Person {
var name: { get set }

Here we have a Person protocol which has one property ‘name’. It’s important to note that there are no implementation details here. We simply want to define that if something is going to conform to a protocol called Person then it must have a property of some value called ‘name’.

The { get set } syntax can look confusing. Essentially this property will be gettable and settable. It is changeable (sort of like how you can change your name in ‘the real world’).

struct John: Person {
var name: String?

Here we have simple value type called a struct. This is a lightweight container for related information and it is called ‘John’. John is a person and he has a name.

What have we achieved here though? Well in this simple example we have indeed created a kind of blueprint for a person however simple it is. However in the future you will create much more complex examples and ensuring functionality is present is going to be super important to you, especially where communication across classes or delegates is involved.

Hopefully this has been of some use to you in the somewhat initially strange world of Protocols in iOS.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.