Protocol Extensions in Swift 2.0 – Draggable UIViews

Protocol extensions in Swift 2.0 rule

One of the features I was most excited about when Swift 2.0 was announced was the ability to provide an extension for a protocol. This means that you can provide a default implementation for an object that adheres to a protocol. Think of this like a ruby mixin!

A real world example

What does this look like? Let’s start with something simple: we want to provide a common protocol to make things draggable.  We’ll define the Draggable protocol to have the following:

  • view is is the actual UIView we want to move
  • initialLocation is the starting center when dragging
  • registerDraggability() is called when we want our class to start listening to dragging
  • removeDraggability() is the opposite, where say we no longer want our class  to be draggable anymore
  • didPress and didPan are the two functions to handle the actual pressing and panning

Normally, this would be pretty straight forward: You would create a UIView subclass that would adopt the Draggable protocol to which you’d then implement the necessary properties and functions.

This works great until you need to do this for another subview. So then you repeat: subclass, adopt and implement. All of the sudden, you’re writing what’s basically the same code over and over. That’s bad! As engineers, we want to write code that’s DRY (don’t repeat yourself) so whats our first take at rectifying this?

Composition vs. Inheritance

If your first response was to create a baseclass that adopts and implements the Draggable protocol, you wouldn’t be wrong and infact that’s a perfectly sensible approach.

Inheritance is a powerful and a tried and true programming practice that has its place; however, it is possible to get into hierarchy hell. I know I’ve run into the issue of having too many UI classes that inherit from each other and making one small change in a base class ends up affecting WAY too many of its descendants.

This is where composition shines!

Instead of having a long chain of subclasses that can be somewhat brittle, we’d like to compose our objects to adhere to our various protocols. This becomes very viable with protocol extensions as we now can provide a default implementation of a protocol:

The real beauty of this protocol extension is we’re giving ourselves access to any UIView that adopts the Draggable protocol! How awesome is that? For example, you remember that view property in the Draggable protocol that is required to be implemented? Now we can just do this:

Basically, any UIView that has the Draggable protocol automatically receives the built in functionality. So what about the remainder of the protocol’s definition? Let’s fill them out:

I don’t believe I need to go over the code to drag a UIView as that’s been covered dozens of times, but there are some caveats that I’d like to bring up:

I had to extend the UIGestureRecognizer class in order to add a method called handler. Tyler Tillage over at CapTech did an excellent job explaining why I couldn’t just use the existing addTarget: action: in the protocol extension here. Long story short:

UIKit is still compiled from Objective-C, and Objective-C has no concept of protocol extendability. What this means in practice is that despite our ability to declare extensions on UIKit protocols, UIKit objects can’t see the methods inside our extensions.

To get around this, my handler closure wraps around some object associations to store the closure which is then called on a default selector. I’ll write another post about why I had to do all of this, but feel free to check out this extension.

Just tell me what I need to do to make things draggable!

When all is said and done, we want it to be as easy as pie to make ANY UIView draggable. I feel like I’m almost there with this:

All you need to do is register the draggability on the view, and provide a storage backing for the view’s initial location before it starts dragging. Pretty simple right?

The best part of this is it can now be applied to other, UIView backed classes! How about UICollectionViewCell?

Remember, we’re not creating a single DraggableView baseclass that requires all of our other classes to subclass. We’re simply adding the additional functionality provided by the protocol and its default extension.

So what does this look like in application?

protocol extension uiview dragging protocol extension uicollectionviewcell dragging


Closing thoughts…

I don’t think I’m sold on this implementation yet. I’m not a fan of object association as some of it feels dirty but in the end it does work, pretty well at that too. The biggest limitation right now is that extensions cannot store additional values and they do not support really anything regarding selectors. Once those two features are put in place, we’ll really be able to do some even more amazing things without having to jump through loops.

Feel free to check out the repository on GitHub and let me know what you think! I’d love to clean this up more if anyone has better ideas!