cs193p – Lecture #6 Protocols and Delegation, Gestures

By GRPH3B18 (Own work) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

Please note, this blog entry is from a previous course. You might want to check out the current one.

The sixth lecture contains theory interspersed with demos of the just learned topics.


Extensions allow to add methods and properties to classes even if the source is not available. It is not possible to override existing methods and properties. New properties can not be used to store data.


Protocols define APIs of methods and properties a caller should provide. It has no storage or implementation associated.

protocol SomeProtocol : class, InheritedProtocol1, InheritedProtocol2 {
    var someProperty: Int { get set }
    func aMethod(arg1: Double, anotherArgument: String) -> SomeType 
    mutating func changeIt()
    init(arg: Type)

  • Any implementation of a protocol must also implement all inherited protocols.
  • Properties need to be specified as get only or both get and set.
  • Functions which will change the receiver have to be marked mutating, unless the protocol is limited to classes.
  • Protocols can demand the implementation of initializers.

If a class is implementing protocols, they are listed after the superclass:

class SomeClass : SuperclassOfSomeClass, SomeProtocol, AnotherProtocol {
    // implementation of SomeClass here!
    // which must include all the properties and methods in SomeProtocol & AnotherProtocol
    required init(...)
enum SomeEnum : SomeProtocol, AnotherProtocol {
    // implementation of SomeEnum here!
    // which must include all the properties and methods in SomeProtocol & AnotherProtocol
struct SomeStruct : SomeProtocol, AnotherProtocol {
    // implementation of SomeStruct here!
    // which must include all the properties and methods in SomeProtocol & AnotherProtocol

The implementation of an initializer must be marked required.

Protocols can be added via extensions:

extension Something : SomeProtocol {
    // implementation of SomeProtocol here! 
    // no stored properties though!


An important use of protocols are delegations – a way to communicate between view and controller:

  1. A delegation protocols defines what the view wants the controller to take care of.
  2. A delegate property in the view is used to access methods and properties of the controller defined in the protocol.
  3. The controller implements the protocol and sets itself as delegate of the view.


Gestures recognizers allow to detect gestures within a certain view and define the objects and methods to handle their occurrence, e.g.:

@IBOutlet weak var pannableView: UIView { 
    didSet {
        let recognizer = UIPanGestureRecognizer(target: self, action: “pan:”)

Depending on the kind of gesture the gesture recognizers provide different methods:

// UIPanGestureRecognizer
func translationInView(view: UIView) -> CGPoint
func velocityInView(view: UIView) -> CGPoint
func setTranslation(translation: CGPoint, inView: UIView)

// UIPinchGestureRecognizer
var scale: CGFloat
var velocity: CGFloat { get }

// UIRotationGestureRecognizer
var rotation: CGFloat 
var velocity: CGFloat { get }

// UISwipeGestureRecognizer
var direction: UISwipeGestureRecoginzerDirection 
var numberOfTouchesRequired: Int

// UITapGestureRecognizer
var numberOfTapsRequired: Int 
var numberOfTouchesRequired: Int

and state information .Possible, .Recognized, .Began, .Changed, .Ended, .Failed and .Canceled.

The lecture and its slides are available via iTunes named “6. Protocols and Delegation, Gestures”. The code for the happiness demo is available on GitHub and at Stanford.


3 thoughts on “cs193p – Lecture #6 Protocols and Delegation, Gestures”

  1. Hi,

    I am going back through Paul Hegarty’s lectures, while I await the arrival of some of the newer lectures/demos, as the trickle slowly into my iTunes U, and this one little thing from lecture 6 is making my head spin, just like one of Eschers prints.

    The line of code that is used to bounds check the value for happiness, I am finding difficult to understand. I know what it does but for the life of me when I look at it I can’t understand why it is constructed like that:

    min(max(happiness, 0), 100)

    Why is max() inside min(). Why is max 0 and min 100. I would intuitively think those values to be the other way around. But of course there is obviously some logical explanation that is just eluding me.

    1. It ensures that happiness is within the given bounds. max() makes sure that it is not smaller than zero (otherwise it would return zero). min() makes sure that it is not higher than 100 (otherwise it would return 100).

  2. Hi Martin,

    Cheers for the answer. I know this is what it does. But anyway I looked again, with a fresh mind and it makes sense now.

    In brief:

    max(happiness, 0)
    makes sure that the x figure in
    min(x, 100)
    is always above 0 and min() will always return the lower value, guaranteed to be 100 or less in this instance.

    It’s the nesting that is a head wreck…such is the world of programming.

    Therefore if Carlsberg did programming, programmers would get 10 hours sleep a night, two hours work in the morning and then the rest of the day on the beach, a nice restaurant, and then a nightclub.

Leave a Reply

Your email address will not be published.