Protocol-Oriented Segue Identifiers in Swift

Posted on December 17th, 2015

Back in August, I watched the phenomenal Swift in Practice WWDC15 Session. I wrote about the first part of the video that impressed me – A Beautiful Solution to Non-Optional UIImage Named in Swift – and I’m finally getting around to writing about the second and even more exciting part of that video (after all, holidays are best for catching up on blogging!).

This time, I’ll be writing about an elegant solution to handling multiple segue identifiers. You guessed it! There will be protocols.

So today, we’re going on a journey of your choice. You choose: the red pill or the blue pill…

Matrix Red Pill Blue Pill App

The Problem

Unfortunately, Segue Identifiers are hard-coded String based. When you add them in your Storyboard, you have to copy the string everywhere in your code – accidental misspellings are just ready to happen.

// ViewController.swift
    
    @IBAction func onRedPillButtonTap(sender: AnyObject) {
        // I'm hard-coding my Red Pill segue identifier here 😬
        performSegueWithIdentifier("TheRedPillExperience", sender: self)
    }

    @IBAction func onBluePillButtonTap(sender: AnyObject) {
        // I'm hard-coding my Blue Pill segue identifier again here 😬
        performSegueWithIdentifier("TheBluePillExperience", sender: self)
    }

// ViewController.swift

@IBAction func onRedPillButtonTap(sender: AnyObject) {

// I'm hard-coding my Red Pill segue identifier here 😬

performSegueWithIdentifier("TheRedPillExperience", sender: self)

}

@IBAction func onBluePillButtonTap(sender: AnyObject) {

// I'm hard-coding my Blue Pill segue identifier again here 😬

performSegueWithIdentifier("TheBluePillExperience", sender: self)

}

And of course, if you decide to change the name of the segue identifier in the future, you have to change it in every place it was hard-coded… more potential for accidental copy / paste accidents and misspellings.

To mitigate this, I use enums to deal with my segue identifiers whenever there is more than one segue identifier in my ViewController.

// ViewController.swift

    enum SegueIdentifier: String {
        case TheRedPillExperience
        case TheBluePillExperience
    }

// ViewController.swift

enum SegueIdentifier: String {

case TheRedPillExperience

case TheBluePillExperience

}

But that presents another set of problems… Mainly, it’s bloated and ugly:

// ViewController.swift
    
    @IBAction func onRedPillButtonTap(sender: AnyObject) {
        // so this is pretty long...
        performSegueWithIdentifier(SegueIdentifier.TheRedPillExperience.rawValue, sender: self)
    }

    @IBAction func onBluePillButtonTap(sender: AnyObject) {
        // and so is this...
        performSegueWithIdentifier(SegueIdentifier.TheBluePillExperience.rawValue, sender: self)
    }

// ViewController.swift

@IBAction func onRedPillButtonTap(sender: AnyObject) {

// so this is pretty long...

performSegueWithIdentifier(SegueIdentifier.TheRedPillExperience.rawValue, sender: self)

}

@IBAction func onBluePillButtonTap(sender: AnyObject) {

// and so is this...

performSegueWithIdentifier(SegueIdentifier.TheBluePillExperience.rawValue, sender: self)

}

The problem becomes a lot worse when dealing with this in prepareForSegue:

// ViewController.swift

    override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
        
        // unwrap all the things!!!
        if let identifier = segue.identifier {
            if let segueIdentifier = SegueIdentifier(rawValue: identifier) {
                switch segueIdentifier {
                case .TheRedPillExperience:
                    print("😈")
                case .TheBluePillExperience:
                    print("👼")
                }
            }
        }
    }

// ViewController.swift

override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {

// unwrap all the things!!!

if let identifier = segue.identifier {

if let segueIdentifier = SegueIdentifier(rawValue: identifier) {

switch segueIdentifier {

case .TheRedPillExperience:

print("😈")

case .TheBluePillExperience:

print("👼")

}

This was my actual code before Swift 2.0. Now you can at least use guard to deal with the Pyramid of Doom, but it’s still not great:

// ViewController.swift

    override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
        
        guard let identifier = segue.identifier,
            segueIdentifier = SegueIdentifier(rawValue: identifier) else {
            fatalError("Invalid segue identifier \(segue.identifier)."
        }
        
        switch segueIdentifier {
        case .TheRedPillExperience:
            print("😈")
        case .TheBluePillExperience:
            print("👼")
        }
    }

// ViewController.swift

override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {

guard let identifier = segue.identifier,

segueIdentifier = SegueIdentifier(rawValue: identifier) else {

fatalError("Invalid segue identifier \(segue.identifier)."

}

switch segueIdentifier {

case .TheRedPillExperience:

print("😈")

case .TheBluePillExperience:

print("👼")

}

Anyway, this is the problems you’ll have to deal with in every single one of your view controllers throughout your app. So how can you clean it up? Again, you guess it! Protocols to the rescue!

The Solution

The solution is very elegant, and not something I would have come up with myself. Thanks Apple for the great architecture talks at WWDC this year. Seriously, these are awesome!

First, you create a SegueHandlerType that identifies the SegueIdentifier enum as a type:

//  SegueHandlerType.swift

import UIKit
import Foundation

protocol SegueHandlerType {
    typealias SegueIdentifier: RawRepresentable
}

// SegueHandlerType.swift

import UIKit

import Foundation

protocol SegueHandlerType {

typealias SegueIdentifier: RawRepresentable

}

Now you can use the power of protocol extensions to create methods for UIViewControllers with String-based SegueIdentifier enums:

//  SegueHandlerType.swift

// notice the cool use of where here to narrow down 
// what could use these methods. 😍
extension SegueHandlerType where Self: UIViewController,
    SegueIdentifier.RawValue == String
{
    
    func performSegueWithIdentifier(segueIdentifier: SegueIdentifier,
        sender: AnyObject?) {
        
        performSegueWithIdentifier(segueIdentifier.rawValue, sender: sender)
    }
    
    func segueIdentifierForSegue(segue: UIStoryboardSegue) -> SegueIdentifier {
        
        // still have to use guard stuff here, but at least you're 
        // extracting it this time    
        guard let identifier = segue.identifier,
            segueIdentifier = SegueIdentifier(rawValue: identifier) else { 
                fatalError("Invalid segue identifier \(segue.identifier).") }
        
        return segueIdentifier
    }
}

// SegueHandlerType.swift

// notice the cool use of where here to narrow down

// what could use these methods. 😍

extension SegueHandlerType where Self: UIViewController,

SegueIdentifier.RawValue == String

{

func performSegueWithIdentifier(segueIdentifier: SegueIdentifier,

sender: AnyObject?) {

performSegueWithIdentifier(segueIdentifier.rawValue, sender: sender)

}

func segueIdentifierForSegue(segue: UIStoryboardSegue) -> SegueIdentifier {

// still have to use guard stuff here, but at least you're

// extracting it this time

guard let identifier = segue.identifier,

segueIdentifier = SegueIdentifier(rawValue: identifier) else {

fatalError("Invalid segue identifier \(segue.identifier).") }

return segueIdentifier

}

Notice that the methods in the protocol extensions are not declared in the protocol – they’re not meant to be overwritten. The best use-case for this I’ve seen.

So now, using these is simple and beautiful:

// ViewController.swift

import UIKit

// just have your UIViewController conform to SegueHandlerType,
// easy as 🎂
class ViewController: UIViewController, SegueHandlerType {

    // the compiler will now complain if you don't have this implemented
    // you need this to conform to SegueHandlerType
    enum SegueIdentifier: String {
        case TheRedPillExperience
        case TheBluePillExperience
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
    }
    
    override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
        
        // 🎉 goodbye pyramid of doom!
        switch segueIdentifierForSegue(segue) {
        case .TheRedPillExperience:
            print("😈")
        case .TheBluePillExperience:
            print("👼")
        }
    }
    
    @IBAction func onRedPillButtonTap(sender: AnyObject) {
        // ✅ this is how I want to write my code! Beautiful!
        performSegueWithIdentifier(.TheRedPillExperience, sender: self)
    }

    @IBAction func onBluePillButtonTap(sender: AnyObject) {
        performSegueWithIdentifier(.TheBluePillExperience, sender: self)
    }
}

// ViewController.swift

import UIKit

// just have your UIViewController conform to SegueHandlerType,

// easy as 🎂

class ViewController: UIViewController, SegueHandlerType {

// the compiler will now complain if you don't have this implemented

// you need this to conform to SegueHandlerType

enum SegueIdentifier: String {

case TheRedPillExperience

case TheBluePillExperience

}

override func viewDidLoad() {

super.viewDidLoad()

}

override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {

// 🎉 goodbye pyramid of doom!

switch segueIdentifierForSegue(segue) {

case .TheRedPillExperience:

print("😈")

case .TheBluePillExperience:

print("👼")

}

@IBAction func onRedPillButtonTap(sender: AnyObject) {

// ✅ this is how I want to write my code! Beautiful!

performSegueWithIdentifier(.TheRedPillExperience, sender: self)

}

@IBAction func onBluePillButtonTap(sender: AnyObject) {

performSegueWithIdentifier(.TheBluePillExperience, sender: self)

}

Conclusion

From the video, the benefits of using the SegueHandlerType are:

Compiler errors when adding new segues if the new case isn’t handled
Reusable
Convenient syntax

We also get to see the power of Protocols:

Tighten app constraints using protocols with associated types
Share implementation through a constrained protocol extension

The most powerful lesson here is to take advantage of the compiler. If you structure your code in this way, the compiler will work with you, warning you when you’re missing cases!

You can view the full sample code on Github here.