Swift 2.0: Protocol-Oriented MVVM

UPDATE: Read this instead for the most up-to-date implementation.

Ever since the mind-blowing Protocol-Oriented Programming in Swift WWDC Session, I’ve been thinking a lot about using protocols. But in reality, I haven’t really been using them as much. I’m still digesting what protocol-oriented programming means, and where in my code I should be using it instead of my other go-to programming patterns.

So I was very excited where a HUGE use-case came to mind. MVVM! I already use MVVM – see my earlier MVVM blog post if you’d like to learn more. And adding in protocol-oriented just clicks here!

I’m going to use a very simple example. A Settings screen that currently only has one settings – put your app in Minion Mode!, but you can of course extrapolate to multiple settings:

Simulator Screen Shot Aug 17, 2015, 8.26.21 AM

The View Cell

A cell that has a label and switch button is very generic. You can use this same cell in multiple places – a “Remember Me” setting on a Sign-In screen comes to mind for example. So you want to keep it as a generic view.

A Big Configure

Usually, I use a configure method in my cell that keeps track of all the possible settings different parts of my app that use that cell need. So it would look something like this:

With Swift’s default parameters, adding additional settings to the configure method without breaking all the other places in your code that uses is super simple. For example, when a designer comes and says that the switch color should be different, I just add that as a default parameter:

While this might not seem like a big deal in this case, in reality, my configure methods become super long and complicated over time! This is where the cool Protocol-Oriented way comes into play…

The Protocol-Oriented Way

And what happens when the designer wants to add the ability to change the default color? This is where the magic of protocol extensions comes into play!

The protocol extension implements the default switchColor option, so anyone who has already implemented this protocol or doesn’t care about setting a color, doesn’t need to worry about it. Only the new cell that has the one different color can implement it.

The ViewModel

So now, the rest is easy. I’m simply going to have a ViewModel for my MinionMode Setting cell:

The ViewController

The final step is to pass my view model to the cell when configuring the cell in the ViewController:

With protocol extensions, protocol-oriented programming is starting to make a lot of sense and I’m looking forward to figuring out ways to use it more! You can get the full code sample on Github here.

UPDATE: Separating the Data Source and the Delegate

In the comments below, Marc Baldwin suggested separating out the cell’s data source and delegate into two protocols, just like UITableView does, and I LOVE that idea. Here is what that would look like:

The View Cell

The cell would have two protocols, and it could be configured with both:

The ViewModel

You can now separate out the data source vs delegate logic in an extension:

The ViewController

This is the part I’m not as sure about – the ViewController will now pass in the viewModel twice:

I updated the code on Github here!

Enjoy the article? Join over 20,000+ Swift developers and enthusiasts who get my weekly updates.