A Swift Journey: Episode 1 — Generic Protocols In Action

Hey there, and welcome to our Swift Journey! In this one, we will talk about Connected2me’s iOS client, like:

• How we embraced a Swifty way,
• Problems we have tackled with,
• Architecture patterns we have applied,
• And much more…

So, fasten your seatbelts, now it’s time to get S(ch)wifty!

Part 1: A View Controller, born from XIB!

Let’s start with an example, shall we? So, let’s say you need a brand new ViewController in your app, and you’d like to have a UI in a XIB or Storyboard. The first test is with a XIB (nib?), like in the below:

So far so good… So, how are we going to utilize C2MViewController?

No need to cast our ViewController, great! But…

… the created .xib is the same name with the class itself, do we really need to write that? And also, you are probably using the same bundle (or nil), so we may also get rid of writing that, too.

So, let’s start with our first protocol, namely: NibInitiable

Good, but not good enough.

With this way, we don’t need to write the nib name (or the bundle) every time we need this VC. Not bad, but could be better. How about casting it automatically? In order to do that we need to utilize Generic Protocols (Self in action!).

We can’t use it like this, sorry.

In order to utilize Self , we need to extend our protocol for our class, because of the way Self works.

Nice, but there’s one last step.

Now, every time you need to create this VC from XIB programmatically, you just need loadFromNib()! How about extending this to other ViewControllers?

And also, we know that we have a .xib with the name of our ViewController, so why not get rid of our optional, too?

Neat, isn’t it?

Aaand, cut! After implementing this protocol, for any ViewController you’re creating with a XIB, you will just need to add NibInitiable conformance to our new class.

Part 2: Powering-Up NibInitiable for UIView

We will wrap up our protocols with an addition to NibInitiable for ourUIView instances. The idea is the same, but it would be a UIView that conforms to our protocol this time. And since loadFromNibForced does not change according to the class, we may just extend our protocol directly.

No more casting, no more long calls. Noice!

Do not forget to set the view’s class as your own (C2MView in this case), and make sure that the names (of your class and your .xib’s) match, since Xcode does not let us create a .xib with a brand new UIViewclass.

Part 3: Another View Controller, born from Storyboard!

In the last part, we will create a brand new protocol, namely StoryboardInitiable. So, normally we would go with something like:

It needs casting.

.. but it’s not that great, the previous improvements can be applied in here, as well. We can get rid of writing the storyboard’s name, bundle, and the identifier. Same problem, not-so-different solution. Anyways, we’re wrapping up, and you’re probably waiting for teh codez, so…

Here it is!

I’m more of a XIB fan though…

We usually set the identifier to the class’ name, and we mostly go with “Main” storyboard, so the example is set accordingly. Feel free to change these according to your needs. (Tip: If you don’t supply bundle parameter, it will be set to .main automatically.)

Conclusion

In this part, we learned about the potential of Generic Protocols, and we powered-up our application with them. In our next parts, we will be presenting a more challenging use of Generic Protocols, and much more (spoiler alert: it may include a type of snakes).

We hope you enjoyed this episode, and stay tuned for more!

Would like to get in touch? Reach me out on Connected2.me:

edusta

… or on LinkedIn:

Engin Deniz Usta - iOS Developer - Connected2.me | LinkedIn