Good morning everyone and welcome. My name is Brad Moore. I work on keyboards, text editing and of course this and today Josh Shaffer and I are going to walk you through Gesture Recognition, which is a new way of dealing with Multi-Touch input on iPhone OS. Now before we get into the nuts and bolts of Gesture Recognition I think it's worth asking why does this matter to us? Why do we care about Multi-Touch processing? And at one level, simply there's no alternative. IOS, iPad, iPhone, they are all built around touch-screen interfaces.

So if you want to respond to user events they are going to be Touch events. But more importantly touch-screen interfaces make for a really incredible user experience. And you as app developers want to tap into that magical interactive quality. So how do you get there? Well if you want to live up to the potential one thing you want to make note of is why Touch interfaces are easy to use. On our system, it's direct manipulation.

You put the fingers on the screen and you physically manipulate content. It feels great and nothing could be simpler. When the iPad first launched you saw videos up on YouTube of first-time computer users including toddlers, a 99-year-old woman, even a cat and they spend one minute with the iPad and they know how to use it. And it's because of this direct manipulation. It's easy and it feels great so you want to be shooting for that. Another reason it's easy to use is that we have a common set of gestures and behaviors. It's a vocabulary that works system wide.

So, for instance, when you encounter new content one of the first things you do is you tap on it. You tap on an icon in the Home screen an app launches. You tap on a text field, a keyboard launches, comes up. You tap on a button and it responds. Tap is so easy, so familiar, and if you come from the mouse and pointer world we don't begrudge that, it's similar to a click.

Something that has no counterpart in the mouse and pointer world is pinch. You put two fingers down on the screen move them together or apart and the content just magically tracks and scales. It feels great. There's no counterpart in the mouse and pointer world because it's a really difficult behavior to implement. You either have a fiddly slider or a text box you enter a percentage into.

On iPhone we have pervasive scalable content because pinch is so natural and it works all over the place and users expect it. Other gestures we have include swipe. You swipe between photos, items in a set. If you swipe an item in a list it will let you delete that.

We have a pan gesture. When you encounter scalable content you just put your finger down on the screen and move it along and the content glides beautifully with your finger and it has a little inertial scroll. It works sometimes free form, sometimes it's locked to a particular direction, but it works everywhere and it works great. One other gesture we support is a bit more advanced, it's the press-and-hold gesture. And it's kind of hard to discover because you put you finger there and don't move it for a while and then something happens. But it gives you advanced things on the Home screen.

An application icon starts jiggling. You can move it around. In a text field you can move the cursor, and bring up a magnifier. And in all sorts of places it brings up the copy/paste UI. Now I said it's a little less discoverable but because it's consistent across the system, once you've encountered it in just one place you know to try it everywhere and that goes for all these gestures. It's a toolbox that users carry around with them and expect them to work in your apps. So it's easy for users. I think you know where this is going. It's hard to write.

There are unique challenges to touch-screen interfaces that use developer space. One of those is the limited precision inherent in touch input. We give you a coordinate that at first blush looks kind of like a mouse coordinate but it's nothing of the sort because it's backed by a finger, which has all the precision of a wobbly sausage. You try to put it where you want and it doesn't go there.

You try to move it by a certain amount and it doesn't move in the direction or the amount you want. You can't even hold it steady, which is the easiest thing in the world with a mouse. So you can't really think of that coordinate as a precise coordinate so much as a disc of possibilities.

Another problem you face is the multi in Multi-Touch. Again there is an analogy when you put your finger down you move it and you lift it. It's almost like mouse down, mouse move, mouse up right? Well sort of, but only if your computer has 20 mice attached to it and each one of them is controlling an independent pointer.

So the added overhead of those different points of onscreen that you have to track, let alone trying to make sense of them, makes your lives a lot harder. But I should mention that these two problems I've listed here you can solve systematically if you insure that your User Interface elements are of a certain size and if you make sure that your User Interface elements respond independently to Touch events you can get really far.

There's another problem though that's really hard to solve systematically and that's the inherent ambiguity of Multi-Touch interfaces. Now what do I mean by that? Well I'll take Safari as an example but you come to Safari, you come to a page and you put your finger on the screen and you don't know what to do. The finger is over a link, maybe you follow a link. It could be a tap.

But it could very well also be a double-tap so when the finger lifts you don't want to immediately respond to that tap but maybe it's not just one finger that's coming down. If you wait a bit another finger is going to come down and it's a pinch and then again maybe one or more fingers are going to come down and move a bit in the same direction, in which case it's a pan.

And maybe it's going to wait there for a while and not move dramatically in which case they want to bring up an action sheet and as if those weren't enough gesture support, you also have the possibility that they're going to tap and then hold, in which case we bring up an accelerated selection you want. So this a bewildering array of possibilities. And you see this sort of thing not just in Safari but all sorts of apps and different context and it leads to a paralysis.

When a finger comes in contact with the screen, I know I want to do something but I don't know what gesture it is so I have to wait. I have to guess. So there are these suboptimal solutions. And you can understand the first, waiting. It comes out of a very good intention of responding to the full set of gestures, right. I wait until the finger is off the screen or I wait until a certain amount of time has gone by and then I can make my determination very accurately.

But what it leads to in practice is I move my fingers and then the content follows and that just kills the direct experience, the direct manipulation experience. So as a user and a framework developer nothing makes me sadder or more frustrated. So we can't do that, it would make me sad. If you recognize the problem of latency, well maybe we'll say I'll take my best guess.

I'll take my shot at it. And when a finger comes down well if it's in an area of the screen that isn't otherwise interesting, I'll wait for another finger to come down, see if it's a pinch. But if it comes down on a link I can reasonably infer that I should follow the link and it does minimize latency but it's pretty frustrating cause you swipe over a link to move the page and you follow a link.

So that's not a solution either. What usually ends up happening at this point is you say, "Boy, I've got this wonderful Multi-Touch interface but I'm going to have a mono-gesture interface. I'm going to tap everywhere. I tap to zoom. I tap to follow a link and you litter your application with buttons. And, yeah, tap is direct manipulation but you can do so much better.

Now I should say there's a fourth solution. Some of you out there recognize all of these problems and you write a very tight state machine so there's a minimal amount of latency. You correctly infer user intent and things just work great, except they don't because you haven't used our own definition, the system-wide definition of pinch, swipe and scroll, you've got bizzaro swipe. So the user comes into your app and it's self-consistent but it's not consistent with any other app on the system. So even when you do things perfectly you fail.

So touch-screen interfaces are easy to use but hard to write. Obviously our goal today and with UIGestureRecognizer is to make it very easy for you guys to use. So the topics we're going to cover include a brief recap of Touch handling, we'll contrast that to gesture handling and we're going to step in the mechanics of gesture handling so you know what UIGestureRecognizer is doing on your behalf when you're employing it. Then we're going to go into the nitty gritty details of the API.

Finally we'll talk about how gesture interactors and gesture recognizers interact with each other and how they interact with normal Touch event delivery. So first off, Touch handling, this should all be old hat. A finger comes down on the screen and it's bound to a UITouch right. For the lifetime of that finger's contact with the screen the same UITouch is associated with it.

Also when a finger comes down on the screen its hit test to a view and that UITouch is bound to that view for the duration of the finger's contact with the screen. And finally changes to that touch are delivered to the UIView via a set of methods on UIResponder.

Touch is began, touch is moved, touch is ended and touch is canceled. All this sounds familiar right? So how would you go about detecting a gesture using this raw event handling? Well first of all you need to subclass UIView so you can store state and respond to these responder methods.

Here I'm looking for a swipe so I store away the first touch. And I store away its initial location. So when touch is began I see if it's the first touch and if so I pull it out, get it's location. When touch is moved I look at the current location and then I say, "Well if it's beyond some horizontal threshold, and beneath some vertical threshold, looks like a swipe" and then touch is ended, I just clear the state.

Not so bad, right? Well there are a lot of problems with this. One I've had to subclass to store state, two it's not reusable. If I go to any other view on the system I have to copy/paste this code at best and three, this is a horrible definition of swipe. Please recognize this don't paste this code into your app.

There is a point here and point here, and if my finger moves between them along any path it's going to count as a swipe and it doesn't pay attention to philosophy. There's so many nuances it doesn't get right. So you might go in and try to tweak it and you'll have a more restrictive definition. But it then it's not going to be the system definition at all. So this is a mess and it's a state of the art until UIGestureRecognizer. So let's see what gesture handling is.

Well to use gesture recognizers you instantiate a pre-defined UIGestureRecognizer, optionally configure it. You set up one or more handlers. These are your target action pairs and then you just add it to the view and you're done. So let's look at this example of swiping with UIGestureRecognizer. Here I've subclassed UIView, but I don't really need to but in its initWithFrame method I'm allocating the SwipeGestureRecognizer. I'm setting its target to self and its action to the swipeRecognized method. So when the gesture is recognized swipeRecognized will be called on me.

Then I add it to the view and because the view retains the GestureRecognizer I just release it, and that's it. This is reuseable. I don't have to do any of the work of detecting the gesture, that's left to the GestureRecognizer and best of all I get the system definition of swipe. So when a user comes to my app it feels just like every other app on the system.

Okay so hopefully that whets your appetite. We'll get into more details later. But now the mechanics, how does Gesture Recognition work? Well we're familiar when a finger makes contact with the screen that it's hit test to a view. Then a sequence of touches are delivered to that view over time. But when you add a Gesture Recognizer to the mix the gesture receives the touches in addition to the view receiving the touches. So it looks kind of like this when the swipe comes through and it compares it to its own internal definition of the gesture.

So let's look at that again more slowly. A swipe comes down and as it finds something that it deems to be a swipe it notices that it's a match and it messages your handlers, your target-action pairs and things proceed. It's actually very uncommon for a gesture to be recognized though. Most of the time Gesture Recognizers are not matching, so what happens there is something comes down, something happens to make it reject the definition and then no messages are sent to your target-action pairs and things proceed.

So if we add another Gesture Recognizer to the mix. We're still getting the multicast touch delivery but something I want to point out is that Gesture Recognizers don't know about each other. They independently process touch-info sequences. For example, I have a Tap Recognizer and a Swipe Recognizer here. They're going to be looking at sequences of touch input and not know a thing about the other and they'll independently transition to a recognized or failed state messaging target-action pairs along the way as needed.

So let's look at a more complicated example where there are multiple views to consider, we have a container view and two subviews. We'll let's add Gesture Recognizers to the first subview and the second subview. An important property of Gesture Recognition is that if a touch isn't delivered to a view, then that Gesture Recognizer doesn't do any processing and similarly a touch is delivered to a view. But when a touch is delivered to a view its Gesture Recognizers receive it. So if subview one receives the touch the Tap Gesture Recognizer sees it.

If subview two receives the touch the Swipe Gesture Recognizer receives it and the Tap Gesture Recognizer does not receive any touches delivered to subview 2. And just to drive home the example, if a touch is delivered to the container view absolutely no Gesture Recognizer sees that input sequence. And this is really important because this contextual analysis means we're not considering all possible gestures at all possible times. We're only doing this as needed and that's really important on an embedded device where you don't have infinite processing resources.

So let's extend this example and add a Gesture Recognizer to the container view. We've added a Pinch Gesture Recognizer here. And normally views only receive touches that are hit test to that view and you might expect the same thing from Gesture Recognizers. But what actually happens is the Gesture Recognizer receives touches delivered to that view and to descendents of that view. So here we're going to have a finger come down in the first subview, a finger come down in the second subview and only the Pinch Gesture Recognizer is going to know about both of them.

Okay and it matches. So really that's how it works in a nutshell. We send Touch events to more than one thing, the Gesture Recognizer in addition to the view and Gesture Recognizers independently compare that input sequence to their own internal definition. They only do this analysis if they've been attached to a view. If no Gesture Recognizer is attached no processing is going on and it works across multiple views. Specifically a Gesture Recognizer receives touches both delivered both to its view and descendents of that view. So finally into the nuts and bolts of the API.

Well first thing worth messaging is that UIGestureRecognizer is available both on IOS 3.2 and IOS 4.0. So you have it available to you on iPad and iPhone and UIGestureRecognizer is an abstract base class. So it has a lot of useful properties and methods but you don't want to instantiate it directly.

That said we provide of course, a huge number of built-in subclasses that you do want to instantiate. Among these we have TapGestureRecognizer and of course that looks for taps but also double-taps and 2-finger taps. We have PinchGestureRecognizer. We have SwipeGestureRecognizer. We have PanGestureRecognizer and that's a bit more forgiving than its definition. Notice the path that took was slow and all over the screen.

LongPressGestureRecognizer both recognizes long presses and long presses that have some number of taps before them and continue to move after they've been recognized. And one other one that I didn't mention earlier is the Rotation Gesture. It's available on iPad and some Contacts like Photos and you get it as one of the built-in Gesture Recognizers. Now this set is pretty comprehensive.

I don't think you'll often have to go outside of it but it's worth noting the UIGestureRecognizer is designed from the get-go to be subclassed. So if you have some reason to define a custom gesture or otherwise encapsulate your touch handling code, feel free to subclass UIGestureRecognizer. We're not going to talk about that now and you can come to the following session if you're curious but it's worth pointing that out. Okay, So you have UIGestureRecognizer. The most important thing you can do with it is establish a handler and that's reflected in the fact that its initializer takes a target-action pair.

And if you want to manipulate the target-action pairs after you've created it you can add and remove targets. And the action method takes an optional UIGestureRecognizer as an argument. You almost always want to take the GestureRecognizer as an argument and then within the handler, within the action method you want to do something.

Well what do you do? In certain cases if you have a really tiny view and it has a Tap Recognizer on it, the fact that the gesture occurred at all is sufficient information to process it. But in a much larger number of cases you need more information and Gesture Recognizers have properties and methods associated with them that make it really easy to handle them. So the first of these that seems interesting is location, the location on screen.

We have a location and view method on UIGestureRecognizer and it means different things for different concrete subclasses. For instance, in a Swipe Gesture it's going to be the point at which the swipe started. And in a Pinch Gesture it's going to be the center of the pinch, natural right.

Occasionally you want a little more information so you might expect us to just expose an NS array of touches associated with the gesture. But what we actually do is similar to that but we implement location of touchInView on UIGestureRecognizer. Why don't we give the array of touches? Well take for example a DoubleTapRecognizer.

By the time the gesture is Recognizer the finger and the touch associated with it are long gone. So we store away that information and location of touchInView and make it available to you at a later time. Another property that you might want to pull out of GestureRecognizer is the state. There is a state property on UIGestureRecognizer of type UIGestureRecognizerState.

So what values does the UIGestureRecognizerState take on? Well I want to get out of the way that there are a couple that for your purposes are uninteresting, they're just for bookkeeping. The possible state and the failed state although they are very important in the implementation of Gesture Recognition, you'll never receive your action methods while things are in this state, so disregard them. Then there's Discrete Recognizers.

A DiscreteGestureRecognizer is something that recognizes a gesture at a particulate moment in time and then it's done with it. There are no further updates. So you're action method will fire just once and when that happens DiscreteGestrureRecognizers are always in the UIGestureRecognizerStateRecognized state. That was a mouthful. So since it's always in that state maybe it's not very interesting to you and you don't even need to check it. But one case you care about immensely is Continuous Recognizers, recognizers like Pinch and Rotate that happen over time and will cause your action method to be fired multiple times. Here there is the Began, Changed, Ended and Canceled state.

And let's look at that visually. We have the Began state. Every Gesture Recognizer that's continuous starts out in the Began state when you receive it. It might move to the Changed state. It might stay in the Changed state for a while and it will definitely eventually move to a terminal state, like Ended.

Now one thing I want to point out there is an important difference between Gesture Recognizer states and touch phases, which are similar right? You have began, changed, ended, similar to began, moved, ended but the problem with touch phases is that in the began phase you don't really know that you can perform any action.

In Gesture Recognizers you know for sure because we've already waited however much time is necessary to correctly identify the gesture. So in your Began state, you can go and start updating the UI and save any initial state. In the Changed state you can continue updating the UI and in the Ended state you can tear down any transit UI and confirm changes.

Now I mentioned there's a Canceled state as well. So the state diagram actually looks like this from either the Began or Changed states it can move straight to the Canceled. That will happen say when a phone call comes in or we notice that the phone is up to your face with the proximity sensor.

You want to handle this similarly to the Ended state but ideally you won't confirm any user action because the user didn't actually finish that gesture. So let's look at an example of dealing with a ContinuousStateGestureRecognizer. Here we're going to handle a LongPressGestureRecognizer and we're going to try do something similar to what happens on the Home screen.

Your finger is going press something, you want it to start jiggling and you move it around as your finger changes. So the first thing we'll do is pull off the view and the currentLocation. We'll use these in every example and note that UIGestureRecognizer has a handy backpointer to its UIView.

It's been added to a view and you can access it from the handler. You want to do that all the time. And the location we're getting in the view is super view so we have a steady reference frame. And then we're going to switch on State. It will go to through four states. In the first we'll store away the startLocation and the centerOffset so we can make geometry deltas in the further states and we'll start the animation, we'll beginJiggling.

In StateChanged we're just going to update the center of the icon. In StateEnded we're going to update the center and stop the animations because it's been confirmed and in StateCanceled we'll do something similar but this time we're going to restore the center to the startLocation because something interrupted the gesture. So all those states were common to every UIGestureRecognizer. There's a lot of specialized state on the concrete subclasses we provide you that is useful for those particular subclasses. For instance UIPinchGestureRecognizer has a scale with it. And UIPanGestureRecognizer has an associated translation.

These method names, these property names should be a very big clue that these ConcereteGestureRecognizers are intended to be used in a very particular way. I can't emphasize this enough. We've done all the trouble of decoupling Gesture Recognition from Gesture Handling. But that doesn't mean that you can mix and match in any old fashion and have a good user experience. It's entirely possibly to have your PinchGesture start rotating the view, but it's not going to make any sense. So please try to use the properties appropriately. OK So that's how we handle gestures. Sometimes you want to customize a Gesture Recognition just slightly.

There's a common way to override behavior without subclassing in Cocoa Touch and that's delegation. Well UIGestureRecognizer does indeed have a delegate. It conforms to the UIGestureRecognizerDelegate property, protocol and it has a number of optional methods. The first of these GestureRecognizerShouldBegin allows you to decide at the last moment that a Gesture Recognizer is not going to be recognized. It is a way of restricting the definition of a gesture without subclassing and without reconfiguring it in any other way.

Another delegate method the GestureRecognizerShouldReceiveTouch allows you to prevent a gesture from even seeing a touch in the first place. This is useful perhaps if you have a Gesture Recognizer on your outer container view and there's one tiny descendent view that you don't want to interact with gestures. So we're looking at this visually.

What happens when a swipe comes in and the Gesture Recognizer says, "Yes it matches my definition?" Well it first sends a message to its delegate asking if it should begin. And so delegate says, "No" the Gesture Recognizer never transitions to the RecognizedState and no action methods are sent.

In the other delegate method when a finger comes in contact with the view and its hit test to the view, we at that point send a message to the delegate asking if it should even receive the touch. And if you say no to that, the SwipeRecognizer never even receives the touch sequence.

So you can use the delegate to override every definition of UIGestureRecognizer or any UIGestureRecognizer but the subclasses offer many more ways to configure those particular Gesture Recognizers. So to give an example TapGestureRecognizer allows you to override both the number of taps, say single versus double and the number of touches required. Say you want to implement a 2-finger tap like you use in Maps to scroll out, or zoom out rather.

There is PanGestureRecognizer. You can specify both a minimum number of touches and a maximum number of touches. And UILongPressGestureRecognizer, which has a huge number of configurable properties. You can specify a number of taps required beforehand and it defaults to 0 but if you set it 1 say you'll get a tap and a half behavior. If you change the number of touches required you can get a 2-finger LongPress Gesture. You can also tweak the minimum press duration and even the allowable movement.

So the built-in subclasses are highly, highly configurable and the jury is out on whether that's a good thing or not; so I want to take this opportunity to caution you all against overly configuring these in very exotic ways. If you create a 4-finger Triple-Tap Gesture it's entirely possible, we've given you the rope to hang yourself by but it's going to make for a very poor user experience for two reasons. It's going to be inconsistent with the rest of the system.

So if for some reason users come to love that gesture in your app it's not going to work anywhere else. And, as sort of the flipside to this is it's going to be very hard to discover it because it's not going to exist anywhere else, so users will come to your app and not know to try that awesome gesture.

So you don't want to hide complex or interesting behaviors behind undiscoverable gestures. That said, if you're determined to shoot yourself in the foot, let us do it for you and use the UIGestureRecognizer and configure it however you want. Okay so that's how to use the API. And now Josh Schaffer is going to come on stage and actually show you in a demo how it works.

Alright thanks Brad.

So I'm really excited to share this with you guys because we've been doing some touch handling things over the last couple of years and it just got a lot easier. So we're going to do two demos today actually. And I've gone ahead and downloaded a couple of the samples off developer.apple.com and we'll take a look at how we did them before and see how we can modify them to make them significantly easier now. So you may have seen this before.

It's part of the Scroll View Suite set of sample applications that went out with last year's Mastering iPhone Scroll View session. And you can pinch in using a UIScrollView and scroll around and that's all part of UIScrollView. But additionally we have the ability to double-tap to zoom in and 2-finger tap to zoom out.

Now the way that was implemented last year and in this sample code that you can download was through a custom subclass of UIImageView called a TapDetectingImageView. And this TapDetectingImageView has a whole bunch of I bars to attract state and defines its own delegate protocol to inform the class that allocated it that there were taps.

Double-taps and 2-finger taps so that's all down here and then within the implementation file there's all this code just to figure out whether we're tapping, double-tapping, 2-finger tapping and then in the end we have to notify our delegate that one of these things has actually happened. So the first thing we're going to do this year is select those two files for the TapDetectingImageView and just delete them [Applause] and now we're done.

No, So we had first allocated our TapDetectingImageView here in our root view controller. So we now can just go back. We don't need a subclass at all anymore and we're just going to create a UIImageView instead. And additionally now we'll delete this set delegate because UIImageView doesn't actually have a delegate protocol so that would not have actually compiled.

And now we can just allocate a couple of UITapGestureRecognizers, actually three because we want to configure tap, double-tap, and 2-finger tap. So we'll go ahead and create three of them. We've got three direct instantiations of UITapGestureRecognizer initing with target self and three different selectors. We've got Handle single-tap, Handle double-tap and Handle 2-finger tap.

Now all of these by default are configured to be single-finger, single-tap because that's the default allocation you get when you allocate a TapGestureRecognizer. So for our double-tap we'll have to set the number of taps required to 2 and for our 2-finger tap the number of touches required to 2, but that's all the configuration that we have to do in order to get all three of these different behaviors. So with that done we can just attach them to that UIImageView so we'll call it ImageView, AddGestureRecognizer, Single-tap, Double-tap and 2-finger tap. And now that they're all retained by the ImageView we can just release them.

We don't have to even hang on to them in high bar or anything. So a single-tap release, double-tap and 2-finger tap all released. So the last thing that's left to do before this actually works is to replace those delegate methods that we had implemented before. Now one thing to take note of in these delegate methods is they actually provided us with a point where the taps had occurred.

So we'll need to solve that as well. But first off we'll just select this and replace our TapDetectingImageView got SingleTapAtPoint with our new action method we defined Handle single-tap and the same for the double-tap, we'll replace that with Handle double-tap and for the 2-finger tap we'll replace that with Handle2-fingerTap.

Now that last part is we no longer have this tap point to find because that was passed to us before by our subclass. But as Brad showed us UIGestureRecognizer knows where the gesture occurred and for any number of taps it's always the centroid of however many fingers were involved.

So if it's a 2-finger tap it's the point that was exactly between them. So we can actually just replace the thing that was passed in with the GestureRecognizer locationInView and since GestureRecognizer knows what view it's attached to and that's the view we want it in, we can just get that view back from the Gesture Recognizer and assign that to our local variable now at tap point. So we just replace exactly what we had been calculating before with something the Gesture Recognizer is already calculating for us, and the same thing down here in Handle 2-finger tap.

So with that done there is not really anything left to do. We can build and run. We still have the same ScrollView functionality we had. We can still pinch. We can scroll around and we can still double-tap to zoom in and 2-finger tap to zoom out with way less code than we had before and with a definition of tap that's the same as everywhere else on the system. So, that's-- [Applause]

Thank you Josh.

As someone who's had to write and maintain code like that before this warms my heart too. And hopefully you're looking at this and salivating and saying, "Boy I can replace a lot of hairy code I've read." So let's now go into what happens when there are multiple Gesture Recognizers and they're interacting with each other in some way.

Well you want to think of the UIGestureRecognizer state machine as a superposition of possibilities. It's like earlier a finger comes down on the screen but you don't know what it is yet. But of course, we only support at most one gesture from a single sequence of touch input and we achieve this by saying that the first Gesture Recognizer to match is the one that wins.

It's the one that gets the target-action paired messages sent. And this works really well in a lot of cases. It reduces latency. I mean as soon as something recognizes, an action happens. And let's look at it visually. Here the swipe has been recognized and there hasn't been anything in the touch input sequence up to this point that disqualifies the touch input sequence from being a pan. The pan is a very promiscuous Gesture Recognizer. But by virtue of the fact that swipe has been recognized the pan will actually be excluded and only the Swipe Recognizer will have its handlers notified.

So that's how we deal with conflicts in general. But if two Gesture Recognizers recognize at exactly the same moment in time in response to precisely the same step in the touch input sequence, well we have to break ties and we do this by favoring views that are closest to leaf nodes in the view hierarchy.

For instance if you have an outer view and an inner view that both have TapGestureRecognizers installed and you tap on the inner view we're going to deliver the target-action pair for the inner view not the outer view. And if two Gesture Recognizers on exactly the same view recognize at the same moment in time, we're going to prefer the Gesture Recognizer that was most recently added. So visually this looks like the following.

We add a SwipeGestureRecognizer to both the outer and the inner view, the container and the subview and then when a touch input sequence come in that matches the swipe we have to choose among the different possibilities and here we choose the more deeply nested view with subview. And that in turn excludes the outer view Swipe Recognizer.

So let's go ahead and add another Swipe Recognizer to the subview and run the same touch input sequence again and here we have to choose between Gesture Recognizers attached to different views so we choose the subview again, but this time we go the more recently added Swipe Recognizer so it's recognized, it's target-action pair fires and it excludes the other SwipeGestureRecognizer. So this is great.

It minimizes latency. It works in a huge number of cases and hopefully makes everyone happy but there are a few cases, well a couple of cases where it falls short. One of these is with Dependent Gestures. And what do I mean by Dependent Gestures? Well where one gesture always has to occur before a second gesture occurs. An obvious example is tap and double-tap and tap always happens before double-tap right? And you might think from what I've just said that if you attach both a Single-tap and a Double-tapRecognizer to a view than the Double-tapRecognizer is never going to fire.

Well if you were paying attention to the demo you know that's not in fact what happens. As a matter of fact, we have very reasonable default behaviors in the UIKit. When a single-tap comes in the single-tap recognizes, it messages its target-action pair, but it does not exclude a Double-tapGestureRecognizer. When a second tap comes in the Double-tap recognizes it as a double-tap but it does exclude the single-tap in this case.

So in a double-tap sequence we get our single-tap firing and then we get a double-tap firing. So two action methods and it works pretty well and it works really well if you have stackable actions on your gestures. For instance take notes, if you want to move the cursor, you tap; if you want to select a word, you double-tap.

Well there's no reason you can't move the cursor immediately before selecting the word and so you can just stack these actions and it works beautifully and there's no latency. An example where it doesn't work so well when you have nonstackable actions is Safari. On tap we follow a link. On double-tap we zoom into the content.

Well you don't want to zoom into the content when you've just followed a link. That doesn't work at all. So there needs to be some other way to deal with that and of course, there is. On UIGestureRecognizer we have another method requireGestureRecognizerToFail. And requireGestureRecognizerToFail is called by the dependee on the dependent.

That is first Gesture Recognizer to recognize calls the method against the-- well you call this against the first Gesture Recognizer to recognize against the second Gesture Recognizer to recognize. An example is a single-tap requires a double-tap to fail. So what does that look visually? Well our first tap comes in and the SingleTapRecognizer in some senses recognizes because it knows it's matching its internal definition but we've imposed this failure requirement so it's not quite finished and it's waiting for the double-tap to fail.

Then when another tap comes in the Double-tapGestureRecognizer says, "Ah ha this is a match." It messages its handlers and then by virtue of being recognized it excludes the single-tap. So when a double-tap comes in we immediately get our double-tap action method and there's no action sent for the single-tap, exactly what we want, except consider just the single-tap case. A finger comes in and after some duration a double-tap fails and only then does a single-tap transition fully to a recognized state and message the handlers.

And notice there that this introduces latency, which I said earlier is really, really bad. It makes me sad and you don't want to do this. What you want to do is design your User Interface so that you can work with stackable actions. But if you absolutely cannot have stackable actions for Dependent Gestures you can use this method.

So Dependent Gestures are one example where mutually exclusive Gesture Recognition isn't perfect. Another example is Compatible Gestures. Gestures like pinch and rotate, why not have them happen at the same time. Well by default we're using the same model we used for all gesture recognizers and that's no Gesture Recognizer is compatible with another. So if I put two fingers down on the screen at some point I'm going to decide either it's a pinch or rotate but not both and my action methods won't fire for both. But this is something you can override.

Using a method on the Delegate property what I didn't mention earlier, GestureRecognizer should recognize simultaneously with Gesture Recognizers. And if you return yes to this two Gesture Recognizers can be recognized at the same time and the target-action pairs will fire for both. So visually if I put two fingers down and start panning and pinching together, it's entirely possible to get action methods for both. So that's how Gesture Recognizers interact with each other. I want to emphasize that the default behavior is usually what you want but you can tweak it a little. So let's move on to Hybrid event handling.

What happens when you have Gesture Recognizers interacting with raw Touch event delivery? You have an app say that's been written before the advent of Gesture Recognizers. Good for you. And are you worrying perhaps you need to rewrite everything from the ground up to use this better tool? No absolutely not, the API was designed to mix and match with responder delivery of Touch events. And as a matter of fact, you can easily add Gesture Recognizers to your existing app. Take a particular view add a Tap Recognizer, add a Swipe Recognizer it works great.

There is one thing I should caution you about though, if you haven't systematically been dealing with canceled touches you're going to start having a lot of problems because when a Gesture Recognizer moves to the recognized state and its target-action pairs are messaged, then it actually stops delivering events to the UIView when we do this, because we don't want two distinct things handling the same input sequence that's generally not a good behavior. And so in order to stop delivery we have to complete the state machine so we cancel those touches, so be ready for that. I also want to emphasize that Gesture Recognition is not a replacement for raw event delivery, raw event handling.

For one it builds upon and exposes the UIResponder touch delivery methods in UITouch. But for another reason not everything fits into a gesture. Not everything is a gesture. You have free-form touch input in many cases. If I'm multi-tapping into my keyboard, if I'm taking a piano and typing into it I want free-form touch input. So don't try to fit things that aren't gestures into UIGestureRecognizers.

So if you're curious about this, if you're curious about how Gesture Recognizers interact with raw event delivery, if you're curious about how to subclass Gesture Recognizers stay for the next session because Josh is going to talk all about that. Alright that's really it for the topics and we have one last demo and Josh is going to come up here and offer it.

Alright thanks again Brad. So one more time we've got another app that I've downloaded off of developer.apple.com sample code. This one you may have also seen. It's a bit older but it's the Touches sample app. It basically shows you how to track multiple touches in a single view but manipulating multiple subviews while doing that tracking so we can grab one and drag it around. Or if we put two fingers down we can actually grab two and drag them both around. But this was of course written using just raw Touch events because that's all we had at that time.

So let's, Oops, expand this out here and take a look at what we were doing. So we had-- Here we are-- a view subclass view subclass, MyView and in that view of course we implemented the touchesbegan, moved and ended and canceled methods and we had a whole lot of code that was stashing off different touch locations and origins and all this different stuff.

We had helper methods to dispatch these Touch events, the different subview in case we wanted to track different ones and we also had to disambiguate which views we were trying to touch all on our own. So there's a lot of code in there to handle that kind of stuff. And, Oops, let's add line numbers back in here and our text editing. So we can see, Actually it's pretty small.

You probably can't see there's actually 213 lines of code in this file just to implement what we just looked at of dragging those single views around. So the first thing we'll do is of course grab all that and delete it all. [Laughter] And we can even get rid of all these defines we had up here and our helper methods because we don't need any of that anymore.

Now we're starting out with 38 lines of code so we're kind of back to almost an empty file and just a bit of stuff for cleaning up our memory in dealloc We begin by adding a PanGestureRecognizer. But we actually want to be able to manipulate all three these views and we want to be able to manipulate all three at the same time. So we'll use three different UIPanGestureRecognizers and attach one to each of those subviews.

But in order to do that I'm going to add this one helper method so I don't have to duplicate the code all over the place. So I'm just going to addGestureRecognizerstoView method and in that we're going to take in whatever view we want to attach the gestures to.

So we'll allocate UIPanGestureRecognizer the same way we did with the tap end with target Self and action will be PanPiece a new selector we'll define in a minute. We're going to attach it to that view that we just passed in so ViewAddGestureRecognizer PanGestureRecognizer and we don't have to hang on to it again because the View is retaining it. So PanGestureRelease is all we have to there.

Now because this view I know is being loaded from a Nib I'm going to do the configuration of the Gesture Recognizers in the awakeFromNib method. So in awakeFromNib I will call AddGestureRecognizerstoView for all three of those piece views. These were connections that were set up in IB. We didn't just do it now but it's the same as the sample code. I wanted to change it as little as possible. So you can check it out for yourself. So now we've attached all these Gesture Recognizers so next we actually want to implement that PanPiece method.

So the strategy we're going to use for panning the piece is very similar to what was being done in the original Touch handling code. Every view has a center point which is defined in the coordinate space of that view's superview and that determines where in that view that subview appears.

So we're just going to adjust the center point by the amount that the user has panned their finger. So to start out with we'll figure out which view we're trying to pan and because we've attached the GestureRecognizer to each of the individual subviews we can just ask for the GestureRecognizer's view and that's the thing we're trying to pan.

Then we want to figure out when we want to adjust the location and Brad talked about the different states that a Gesture Recognizer may be in. So since we're a PanGestureRecognizer which is continuous and we report changes over time, we want to adjust our location any time we're in stateBegan or stateChanged. By the time we get to stateBegan, as Brad said, we already know that we've ruled out any other possibilities.

We're really trying to pan a piece. So in those two states we know we can update our location. In order to figure out what to update we want to start out by knowing where we are now and we can get that by just pulling the center off the piece.

So we'll get the piece's center and stash that in a local CG point, which we're going to adjust in a second and in order-- and we want to know how far we want to move it. Now normally you'd have to calculate that yourself by figuring out the delta between the last touch location and the current touch location but UIPanGestureRecognizer tracks it for you. So we can just ask the PanGestureRecognizer for its translation in any particular view.

And since the center is always in the coordinate space of our View-SuperView we also want to get our translation in the coordinate space of our View-SuperView. So we'll get the GestureRecognizer translation in View, piece in SuperView and that's the amount that we want to move our piece by.

So knowing the center and how much we want to move it we can adjust the center by that amount. So our new piece's center is CGPointMake the original center X plus translation X and the same for the Y. Now this next part is a little bit odd. So all of the continuous Gesture Recognizers that you'll find as part of the UIKit pan, pinch and rotate, they all report a cumulative offset. So TranslationInView normally is the total accumulated translation for the entire duration of that gesture.

So it's the translation from the original begin point to the current location even if your action method has been fired 500 times. But as you just saw here, we're actually adjusting our current center point by that delta. So it would actually shoot out from under our finger if we kept doing this.

But one nice thing about the property TranslationInView and scale and rotation on the other two is that they are writable as well. So if we don't actually want a cumulative value here, we can get deltas by just setting it back to 0 after we've pulled out the current value.

So in this case we'll call it GestureRecognizerSetTranslation, CG point 0 in that same piece, in that same SuperView rather, so that the next time our action method is called we know it's going to be a delta from 0 instead of a total cumulative translation causing it to shoot out from under our finger. An alternative is you could just stash away the original point but there are cases where you may want to do that. But for purposes of our demo it means we don't have to keep any additional state around.

So that's actually all we have to do there. So if we now build and run you'll find that we still have the exact same stuff we had. Uh oh, well we almost had it. So, this is something that's bitten people alive. So I wanted to actually make it by me so you would see it.

You have probably hit this in your own code at some point. UIImageView is one of the few subclasses in UIKit that has user action disabled by default. Now as Brad was telling us UIGestureRecognizer only receives touches if its view is receiving touches. And since our user interaction is disabled on these ImageViews their Gesture Recognizers aren't going to receive touches either.

So, they are actually defined in our main window Nib, just open that up and select, well maybe, this is going to be a much shorter demo if I can't open Interface Building, we'll open that up in there maybe this time. Oh man, what's going on? Hey there we go. Good call thanks. For some reason opening the XIB wasn't working and opening the localization was.

So anyway now we can select all three of these guys and go over to our inspector and turn on UserAction and if we build and run now this time for sure we can actually drag it around. Now one thing I didn't point out when I originally did this was that when I started dragging the piece actually jumped to be underneath our cursor because we were directly setting the center to the current touch location but that we're using deltas it's much more what we want. So actually if we're grabbing the corner it sticks to the corner rather than jumping to the center.

We can still do two at a time because Gesture Recognizers that are not related to each other by a View hierarchy these are actually in sibling views can recognize simultaneously. So these pans will continue to track independent Views at the same time. And it would work for three fingers if I could do 3-fingers in the simulator but sadly no can do.

[Applause] Alright so that's pretty cool right. There almost no code anymore. We've got just these 10 lines of code that we added and deleted 213 lines. But now our design team has come to us and said, well that's really cool I love that I can still do that and you made it better, why do I care about that. But what I really want is also to be able to pinch in there to make them scale those views bigger.

Now if you had gone and already implemented that touch tracking before and wanted to switch to adding this new pinch ability as well, it'd probably start to get pretty complicated and you'd have to figure out how to look at multiple touches and figure out which views they were in and then from touches figure out how much to scale your view so you'd have to do a bunch of math to calculate that.

And it becomes pretty complex pretty quick and you end with a big state machine that you're trying to track and a lot of additional state that you're keeping track of. But with UIAdjusterRecognizer it's actually quite easy. So we tell our design team, "Hey no problem. We'll get back to you in five minutes." And we allocate a UIPinchAdjusterRecognizer and end at targetSelf, selectorScalePiece add it to the View and release it, the same as everything else, but now because we know that our design team is a little bit fickle and as soon as we implement this they're going to say I want rotation too, we saw ahead and decide we're going to do the same thing already to save ourselves some time so we add a UIRotationGestureRecognizer.

So the action method for that will be rotatePiece. So we can come down here and add these two new action methods below our PanPiece. So if we're going to add a ScalePiece method and this is going to be implemented almost exactly the same way as our PanPiece method except instead of adjusting the center point we're going to adjust the transform on the View. So we'll get out the current piece the same way and check to see if we're in stateBegan or Changed so that we know we actually want to apply this.

Now instead of getting center we're going to get the transform off of the View, so PieceTransform and instead of getting translation from a PanGestureRecognizer we'll get ScaleFromAPinchGestureRecognizer. And we want to scale our transform the current transform by the scale that the GestureRecognizer has calculated for us. So we don't even have to look at the touches and figure out how far they were or how much they moved or how to get a scale from that. It's already been done. So we'll adjust the pieces transformed by using CGOutlineTransformScale and we'll scale the transform both horizontially and vertically by the scale we got from the Gesture Recognizer.

And as I said PanGestureRecognizer is the same as sorry, PinchGestureRecognizer is the same as Pan in that it's a cumulative scale. So we really want deltas so we're going to go ahead and set the scale back to 1, 1 would be the identity for a scale and we'll do the exact same thing for rotate except instead of getting the scale out we're going to get the pieces transformed and get the RotationGestureRecognizer as rotation and the identify value for rotation is 0. With no rotation it would be 0.

And we'll have rotated with CGOutlineTransferAndRotate. So if we were to build and run now you'd find that we actually could scale and rotate these pieces but we can't do them both at the same time because as Brad said, they're mutually exclusive, if I could talk today, so we can do both but that's not really ideal but there is a very quick solution to this. It's that-- long to say but quick to implement, GestureRecognizer should recognize simultaneously with GestureRecognizerDelegate method.

[Laughter and applause] Oh well thank you. I've been practicing. So we're going to go and set the PanGestureRecognizer's Delegate to ourself, set the PinchGestureRecognizer's Delegate to ourself and set the RotationGestureRecognizer Delegate the same way and then we'll implement GestureRecognizer should then recognize simultaneously with GestureRecognizer [Laughter] right down here [Laughter] I had to say it fast because it could take the rest of the session otherwise.

So what we're going to do with this one is by default we want to keep the normal behavior. No two gestures recognized at the same time so by default we're going to continue to return no, they should not recognize simultaneously. How you decide whether two gestures should recognize at the same time is kind of up to you. In most cases you've probably stashed pointers to the gesture so you can be explicit about saying these two specific ones should recognize simultaneously but for simple implementation here we're just going to say that any two gestures attached to the same view can recognize at the same time.

So if the GestureRecognizer that we're being asked about if its view is the same as the other GestureRecognizer that we're being asked to view, we'll say yes they can recognize together, otherwise default behavior and nope they can't recognize. So with that just form five more lines of code, build and run and now we can pinch, rotate, translate all at the same time and if we do in two different views we can still move them around.

[Applause] There is one last piece that I didn't go over here and it's, I'm not going to get into too much detail about it, but we generally want to pinch and rotate around the center of our fingers. And the rotations and scales when you apply transference to views are applied around the center of the View not around the center of your fingers. So CALayer has a property called an anchor point that allows you to adjust the location around which a scale and a rotation would be applied. I've written a helper method we won't look at it right now because it's not directly related to Gesture Recognizers.

But I'm going to adjust it by adjusting anchor point to be between my fingers so that the pieces would actually remain attached to my fingers as we were manipulating them. Oops, went a little too far in my setup things. So I'll show you that in just a second too, but now that we've got all that working our design team has come back to us one more time and they've said, "Wow, that's awesome you did it in five minutes, that's incredible. What can you do in ten?" [Laughter] Really we should have waited a couple of days before we showed them.

Now they want us to be able to pinch and rotate and pan all of these views all together at one time if we're not in one view with both our fingers. So the whole collection of views all at once, so now you wrote all this not using GestureRecognizer. You're like, "Aw geez, I have to start over I don't know what to do." No problem with GestureRecognizer though, we can do this with one line of code.

So we're going to go back to the top and in our awakeFormNib method, I added some warnings for you guys, I hadn't declared this as a GestureRecognizerDelegate so don't leave those in your code when you check it in, it looks bad and it's embarrassing when you're on stage.

So in our awakeFromNib method we had our AddGestureRecognizersToViewHelper method and we were adding them to the three pieces, well, how about we add them to ourself as well. We are UIView subclass and these ImageViews are subclasses of us. So add them to ourself and we're the SuperView of these ImageViews. One line of code, let's build and run. Now we can pinch this guy, still rotate, we get a finger outside, I can pinch and rotate all of them.

[Laughter and applause] So I happened to have already built this for an iPad, I thought I'd show you here. It's a little bit easier to see. We can now pinch this guy and we can pinch this guy and we can pinch that guy and we can get all this fingers down and we can pinch all of them [Laughter] and we can grab the whole set.

So that's all I've got. Thanks. [Applause]

Thanks Josh that's awesome. So just to recap Gesture Recognizers, why you want to use them-- less code to write, you can spend your time handling gestures, not detecting them and most importantly you're going to get consistency with the system-wide definition of gestures and how you use them. It's simple.

You instantiate a Gesture Recognizer, you set your target-action pairs, you configure it using delegate or subclass properties and you attach it to a view and that's it. So if you want more information you can contact our Evangelist, go online to docs or devforums. Stay for the next session if you want a subclass UIGestureRecognizer or learn more about how to configure the Gesture Recognizers interaction with normal touch delivery. Cool, Thank you.