[Winifred the Woebegone illustrates hit-testing:] Hey nonny nonny, is it you? — Hey nonny nonny nonny no! — Hey nonny nonny, is it you? — Hey nonny nonny nonny no!
A touch is an instance of the user putting a finger on the screen. The system and the hardware, working together, know when a finger contacts the screen and where it is. A finger is fat, but its location is cleverly reduced to a single appropriate point.
A UIView, by virtue of being a UIResponder, is the visible locus of touches. There are other UIResponder subclasses, but none of them is visible on the screen. What the user sees are views; what the user is touching are views. (The user actually sees layers, but a layer is not a UIResponder and is not involved with touches.)
It would make sense, therefore, if every touch were reported directly to the view in which it occurred. However, what the system “sees” is not particular views but an app as a whole. So a touch is represented as an object (a UITouch instance) which is bundled up in an envelope (a UIEvent) which the system delivers to your app. It is then up to your app to deliver the envelope to an appropriate UIView. In the vast majority of cases, this will happen automatically the way you expect, and you will respond to a touch by way of the view in which the touch occurred.
In fact, usually you won’t concern yourself with UIEvents and UITouches at all. Most built-in interface views deal with these low-level touch reports themselves, and notify your code at a higher level — you hear about functionality and intention rather than raw touches. When a UIButton emits an action message to report a control event such as Touch Up Inside, it has already performed a reduction of a complex sequence of touches (“the user put a finger down inside me and then, possibly with some dragging hither and yon, raised it when it was still reasonably close to me”). A UITextField reports touches on the keyboard as changes in its own text. A UITableView reports that the user selected a cell. A UIScrollView, when dragged, reports that it scrolled; when pinched outward, it reports that it zoomed.
Nevertheless, it is useful to know how to respond to touches directly, so that you can implement your own touchable views, and so that you understand what Cocoa’s built-in views are actually doing. This chapter discusses touch detection and response by views (and other UIResponders) at their lowest level, along with a slightly higher-level mechanism, gesture recognizers, that categorizes touches into gesture types for you; then it deconstructs the touch-delivery architecture by which touches are reported to your views in the first place.
Imagine a screen that the user is not touching at all: the screen is “finger-free.” Now the user touches the screen with one or more fingers. From that moment until the time the screen is once again finger-free, all touches and finger movements together constitute what Apple calls a single multitouch sequence.
The system reports to your app, during a given multitouch sequence, every change in finger configuration, so that your app can figure out what the user is doing. Every such report is a UIEvent. In fact, every report having to do with the same multitouch sequence is the same UIEvent instance, arriving repeatedly, each time there’s a change in finger configuration.
Every UIEvent reporting a change in the user’s finger configuration contains one or more UITouch objects. Each UITouch object corresponds to a single finger; conversely, every finger touching the screen is represented in the UIEvent by a UITouch object. Once a UITouch instance has been created to represent a finger that has touched the screen, the same UITouch instance is used to represent that finger throughout this multitouch sequence until the finger leaves the screen.
Now, it might sound as if the system has to bombard the app with huge numbers of reports constantly during a multitouch sequence. But that’s not really true. The system needs to report only changes in the finger configuration. For a given UITouch object (representing, remember, a specific finger), only four things can happen. These are called touch phases, and are described by a UITouch instance’s phase property:
UITouchPhaseBegan
UITouchPhaseMoved
UITouchPhaseStationary
UITouchPhaseEnded
UITouchPhaseBegan, this phase arrives only once. The UITouch instance will now be destroyed and will no longer appear in UIEvents for this multitouch sequence.
Those four phases are sufficient to describe everything that a finger can do. Actually, there is one more possible phase:
UITouchPhaseCancelled
When a UITouch first appears (UITouchPhaseBegan), your app works out which UIView it is associated with. (I’ll give full details, later in this chapter, as to how it does that.) This view is then set as the touch’s view property; from then on, this UITouch is always associated with this view. In other words, a touch’s view is that touch’s view forever (until that finger leaves the screen).
The same UIEvent containing the same UITouches can be sent to multiple views. Accordingly, a UIEvent is distributed to all the views of all the UITouches it contains. Conversely, if a view is sent a UIEvent, it’s because that UIEvent contains at least one UITouch whose view is this view.
If every UITouch in a UIEvent associated with a certain UIView has the phase UITouchPhaseStationary, that UIEvent is not sent to that UIView. There’s no point, because as far as that view is concerned, nothing happened.
A UIResponder, and therefore a UIView, has four methods corresponding to the four UITouch phases that require UIEvent delivery. A UIEvent is delivered to a view by calling one or more of these four methods (the touches... methods):
touchesBegan:withEvent:
touchesMoved:withEvent:
touchesBegan:withEvent: has moved.
touchesEnded:withEvent:
touchesBegan:withEvent: has left the screen.
touchesCancelled:withEvent:
touchesBegan:withEvent:.
The parameters of these methods are:
anyObject (an NSSet doesn’t implement lastObject because a set is unordered).
allTouches message. This means all the event’s touches, including but not necessarily limited to those in the first parameter; there might be touches in a different phase or intended for some other view. You can call touchesForView: or touchesForWindow: to ask for the set of touches associated with a particular view or window.
A UITouch has some useful methods and properties:
locationInView:, previousLocationInView:
self or self.superview; supply nil to get the location with respect to the window. The previous location will be of interest only if the phase is UITouchPhaseMoved.
timestamp
UITouchPhaseBegan) and each time it moves (UITouchPhaseMoved). There can be a delay between the occurrence of a physical touch and the delivery of the corresponding UITouch, so to learn about the timing of touches, consult the timestamp, not the clock.
tapCount
tapCount one larger than the previous one. The default is 1, so if (for example) a touch’s tapCount is 3, then this is the third tap in quick succession in roughly the same spot.
view
Here are some additional UIEvent properties:
type
UIEventTypeTouches. There are other event types, but you’re not going to receive any of them this way.
timestamp
So, when we say that a certain view is receiving a touch, that is a shorthand expression meaning that it is being sent a UIEvent containing this UITouch, over and over, by calling one of its touches... methods, corresponding to the phase this touch is in, from the time the touch is created until the time it is destroyed.
Touch events can be turned off entirely at the application level with UIApplication’s beginIgnoringInteractionEvents. It is quite common to do this during animations and other lengthy operations during which responding to a touch could cause undesirable results. This call should be balanced by endIgnoringInteractionEvents. Pairs can be nested, in which case interactivity won’t be restored until the outermost endIgnoringInteractionEvents has been reached.
A number of UIView properties also restrict the delivery of touches to particular views:
userInteractionEnabled
alpha
0.0 (or extremely close to it), this view (along with its subviews) is excluded from receiving touches. Touches on this view or one of its subviews “fall through” to a view behind it.
hidden
multipleTouchEnabled
exclusiveTouch
exclusiveTouch view receives a touch only if no other views in the same window have touches associated with them; once an exclusiveTouch view has received a touch, then while that touch exists no other view in the same window receives any touches.
Thanks to gesture recognizers (discussed later in this chapter), in most cases you won’t have to interpret touches at all; you’ll let a gesture recognizer do most of that work. Even so, it is beneficial to be conversant with the nature of touch interpretation; this will help you interact with a gesture recognizer, write your own gesture recognizer, or subclass an existing one. Furthermore, not every touch sequence can be codified through a gesture recognizer; sometimes, directly interpreting touches is the best approach.
To figure out what’s going on as touches are received by a view, your code must essentially function as a kind of state machine. You’ll receive various touches... method calls, and your response will partly depend upon what happened previously, so you’ll have to record somehow, such as in instance variables, the information that you’ll need in order to decide what to do when the next touches... method is called. Such an architecture can make writing and maintaining touch-analysis code quite tricky. Moreover, although you can distinguish a particular UITouch or UIEvent object over time by keeping a reference to it, you mustn’t retain that reference; it doesn’t belong to you.
To illustrate the business of interpreting touches, we’ll start with a view that can be dragged with the user’s finger. For simplicity, I’ll assume that this view receives only a single touch at a time. (This assumption is easy to enforce by setting the view’s multipleTouchEnabled to NO, which is the default.)
The trick to making a view follow the user’s finger is to realize that a view is positioned by its center, which is in superview coordinates, but the user’s finger might not be at the center of the view. So at every stage of the drag we must change the view’s center by the change in the user’s finger position in superview coordinates:
- (void) touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event {
UITouch* t = touches.anyObject;
CGPoint loc = [t locationInView: self.superview];
CGPoint oldP = [t previousLocationInView: self.superview];
CGFloat deltaX = loc.x - oldP.x;
CGFloat deltaY = loc.y - oldP.y;
CGPoint c = self.center;
c.x += deltaX;
c.y += deltaY;
self.center = c;
}Next, let’s add a restriction that the view can be dragged only vertically or horizontally. All we have to do is hold one coordinate steady; but which coordinate? Everything seems to depend on what the user does initially. So we’ll do a one-time test the first time we receive touchesMoved:withEvent:. Now we’re maintaining two BOOL state variables, _decided and _horiz:
- (void) touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
self->_decided = NO;
}
- (void) touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event {
UITouch* t = touches.anyObject;
if (!self->_decided) {
self->_decided = YES;
CGPoint then = [t previousLocationInView: self];
CGPoint now = [t locationInView: self];
CGFloat deltaX = fabs(then.x - now.x);
CGFloat deltaY = fabs(then.y - now.y);
self->_horiz = (deltaX >= deltaY);
}
CGPoint loc =
[t locationInView: self.superview];
CGPoint oldP =
[t previousLocationInView: self.superview];
CGFloat deltaX = loc.x - oldP.x;
CGFloat deltaY = loc.y - oldP.y;
CGPoint c = self.center;
if (self->_horiz)
c.x += deltaX;
else
c.y += deltaY;
self.center = c;
}Look at how things are trending. We are maintaining multiple state variables, which we are managing across multiple methods, and we are subdividing a touches... method implementation into tests depending on the state of our state machine. Our state machine is very simple, but already our code is becoming difficult to read and to maintain — and things will only become more messy as we try to make our view’s behavior more sophisticated.
Another area in which manual touch handling can rapidly prove overwhelming is when it comes to distinguishing between different gestures that the user is to be permitted to perform on a view. Imagine, for example, a view that distinguishes between a finger tapping briefly and a finger remaining down for a longer time. We can’t know how long a tap is until it’s over, so one approach might be to wait until then before deciding:
- (void) touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
self->_time = [(UITouch*)touches.anyObject timestamp];
}
- (void) touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
NSTimeInterval diff = event.timestamp - self->_time;
if (diff < 0.4)
NSLog(@"short");
else
NSLog(@"long");
}On the other hand, one might argue that if a tap hasn’t ended after some set time (here, 0.4 seconds), we know that it is long, and so we could begin responding to it without waiting for it to end. The problem is that we don’t automatically get an event after 0.4 seconds. So we’ll create one, using delayed performance:
- (void) touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
self->_time = [(UITouch*)touches.anyObject timestamp];
[self performSelector:@selector(touchWasLong)
withObject:nil afterDelay:0.4];
}
- (void) touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
NSTimeInterval diff = event.timestamp - self->_time;
if (diff < 0.4)
NSLog(@"short");
}
- (void) touchWasLong {
NSLog(@"long");
}But there’s a bug. If the tap is short, we report that it was short, but we also report that it was long. That’s because the delayed call to touchWasLong arrives anyway. We could use some sort of boolean flag to tell us when to ignore that call, but there’s a better way: NSObject has a class method that lets us cancel any pending delayed performance calls:
- (void) touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
self->_time = [(UITouch*)touches.anyObject timestamp];
[self performSelector:@selector(touchWasLong)
withObject:nil afterDelay:0.4];
}
- (void) touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
NSTimeInterval diff = event.timestamp - self->_time;
if (diff < 0.4) {
NSLog(@"short");
[NSObject cancelPreviousPerformRequestsWithTarget:self
selector:@selector(touchWasLong) object:nil];
}
}
- (void) touchWasLong {
NSLog(@"long");
}Here’s another use of the same technique. We’ll distinguish between a single tap and a double tap. The UITouch tapCount property already makes this distinction, but that, by itself, is not enough to help us react differently to the two. What we must do, having received a tap whose tapCount is 1, is to delay responding to it long enough to give a second tap a chance to arrive. This is unfortunate, because it means that if the user intends a single tap, some time will elapse before anything happens in response to it; however, there’s nothing we can easily do about that.
Distributing our various tasks correctly is a bit tricky. We know when we have a double tap as early as touchesBegan:withEvent:, so that’s when we cancel our delayed response to a single tap, but we respond to the double tap in touchesEnded:withEvent:. We don’t start our delayed response to a single tap until touchesEnded:withEvent:, because what matters is the time between the taps as a whole, not between the starts of the taps. This code is adapted from Apple’s own example:
- (void) touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
int ct = [(UITouch*)touches.anyObject tapCount];
if (ct == 2) {
[NSObject cancelPreviousPerformRequestsWithTarget:self
selector:@selector(singleTap) object:nil];
}
}
- (void) touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
int ct = [(UITouch*)touches.anyObject tapCount];
if (ct == 1)
[self performSelector:@selector(singleTap)
withObject:nil afterDelay:0.3];
if (ct == 2)
NSLog(@"double tap");
}
- (void) singleTap {
NSLog(@"single tap");
}Now let’s consider combining our detection for a single or double tap with our earlier code for dragging a view horizontally or vertically. This is to be a view that can detect four kinds of gesture: a single tap, a double tap, a horizontal drag, and a vertical drag. We must include the code for all possibilities and make sure they don’t interfere with each other. The result is rather horrifying — a forced join between two already complicated sets of code, along with an additional pair of state variables to track the decision between the tap gestures on the one hand and the drag gestures on the other:
- (void) touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
// be undecided
self->_decidedTapOrDrag = NO;
// prepare for a tap
int ct = [(UITouch*)touches.anyObject tapCount];
if (ct == 2) {
[NSObject cancelPreviousPerformRequestsWithTarget:self
selector:@selector(singleTap)
object:nil];
self->_decidedTapOrDrag = YES;
self->_drag = NO;
return;
}
// prepare for a drag
self->_decidedDirection = NO;
}
- (void) touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event {
UITouch* t = touches.anyObject;
if (self->_decidedTapOrDrag && !self->_drag)
return;
self->_decidedTapOrDrag = YES;
self->_drag = YES;
if (!self->_decidedDirection) {
self->_decidedDirection = YES;
CGPoint then = [t previousLocationInView: self];
CGPoint now = [t locationInView: self];
CGFloat deltaX = fabs(then.x - now.x);
CGFloat deltaY = fabs(then.y - now.y);
self->_horiz = (deltaX >= deltaY);
}
CGPoint loc = [t locationInView: self.superview];
CGPoint oldP = [t previousLocationInView: self.superview];
CGFloat deltaX = loc.x - oldP.x;
CGFloat deltaY = loc.y - oldP.y;
CGPoint c = self.center;
if (self->_horiz)
c.x += deltaX;
else
c.y += deltaY;
self.center = c;
}
- (void) touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
if (!self->_decidedTapOrDrag || !self->_drag) {
// end for a tap
int ct = [(UITouch*)touches.anyObject tapCount];
if (ct == 1)
[self performSelector:@selector(singleTap)
withObject:nilafterDelay:0.3];
if (ct == 2)
NSLog(@"double tap");
return;
}
}
- (void) singleTap {
NSLog(@"single tap");
}That code seems to work, but it’s hard to say whether it covers all possibilities coherently; it’s barely legible and the logic borders on the mysterious. This is the kind of situation for which gesture recognizers were devised.
Writing and maintaining a state machine that interprets touches across a combination of three or four touches... methods is hard enough when a view confines itself to expecting only one kind of gesture, such as dragging. It becomes even more involved when a view wants to accept and respond differently to different kinds of gesture. Furthermore, many types of gesture are conventional and standard; it seems insane to require developers to implement independently the elements that constitute what is, in effect, a universal vocabulary.
The solution is gesture recognizers, which standardize common gestures and allow the code for different gestures to be separated and encapsulated into different objects.
A gesture recognizer (a subclass of UIGestureRecognizer) is an object whose job is to detect that a multitouch sequence equates to one particular type of gesture. It is attached to a UIView, which has for this purpose methods addGestureRecognizer: and removeGestureRecognizer:, and a gestureRecognizers property. A UIGestureRecognizer implements the four touches... handlers, but it is not a responder (a UIResponder), so it does not participate in the responder chain.
If a new touch is going to be delivered to a view, it is also associated with and delivered to that view’s gesture recognizers if it has any, and that view’s superview’s gesture recognizers if it has any, and so on up the view hierarchy. Thus, the place of a gesture recognizer in the view hierarchy matters, even though it isn’t part of the responder chain.
UITouch and UIEvent provide complementary ways of learning how touches and gesture recognizers are associated. UITouch’s gestureRecognizers lists the gesture recognizers that are currently handling this touch. UIEvent’s touchesForGestureRecognizer: lists the touches that are currently being handled by a particular gesture recognizer.
Each gesture recognizer maintains its own state as touch events arrive, building up evidence as to what kind of gesture this is. When one of them decides that it has recognized its own particular type of gesture, it emits either a single message (to indicate, for example, that a finger has tapped) or a series of messages (to indicate, for example, that a finger is moving); the distinction here is between a discrete and a continuous gesture.
What message a gesture recognizer emits, and to what object it sends it, is set through a target–action dispatch table attached to the gesture recognizer; a gesture recognizer is rather like a UIControl in this regard. Indeed, one might say that a gesture recognizer simplifies the touch handling of any view to be like that of a control. The difference is that one control may report several different control events, whereas each gesture recognizer reports only one gesture type, with different gestures being reported by different gesture recognizers.
This architecture implies that it is unnecessary to subclass UIView merely in order to implement touch analysis.
UIGestureRecognizer itself is abstract, providing methods and properties to its subclasses. Among these are:
initWithTarget:action:
The designated initializer. Each message emitted by a UIGestureRecognizer is a matter of sending the action message to the target. Further target–action pairs may be added with addTarget:action: and removed with removeTarget:action:.
Two forms of action: selector are possible: either there is no parameter, or there is a single parameter which will be the gesture recognizer. Most commonly, you’ll use the second form, so that the target can identify and query the gesture recognizer; moreover, using the second form also gives the target a reference to the view, through the gesture recognizer’s view property.
locationOfTouch:inView:
numberOfTouches property provides a count of current touches; the touches themselves are inaccessible by way of the gesture recognizer.
enabled
state, view
Built-in UIGestureRecognizer subclasses are provided for six common gesture types: tap, pinch (inward or outward), pan (drag), swipe, rotate, and long press. Each embodies properties and methods likely to be needed for each type of gesture, either in order to configure the gesture recognizer beforehand or in order to query it as to the state of an ongoing gesture:
numberOfTapsRequired, numberOfTouchesRequired (“touches” means simultaneous fingers).
scale, velocity.
rotation, velocity.
direction (meaning permitted directions, a bitmask), numberOfTouchesRequired.
Dragging. Configuration: minimumNumberOfTouches, maximumNumberOfTouches. State: translationInView:, setTranslation:inView:, and velocityInView:; the coordinate system of the specified view is used.
numberOfTapsRequired, numberOfTouchesRequired, minimumPressDuration, allowableMovement. The numberOfTapsRequired is the count of taps before the tap that stays down; so it can be 0 (the default). The allowableMovement setting lets you compensate for the fact that the user’s finger is unlikely to remain steady during an extended press; thus we need to provide some limit before deciding that this gesture is, say, a drag, and not a long press after all. On the other hand, once the long press is recognized, the finger is permitted to drag.
UIGestureRecognizer also provides a locationInView: method. This is a single point, even if there are multiple touches. The subclasses implement this variously. For example, for UIPanGestureRecognizer, the location is where the touch is if there’s a single touch, but it’s a sort of midpoint (“centroid”) if there are multiple touches.
We already know enough to implement, using a gesture recognizer, a view that responds to a single tap, or a view that responds to a double tap. We don’t yet know quite enough to implement a view that lets itself be dragged around, or a view that can respond to more than one gesture; we’ll come to that. Meanwhile, here’s code that implements a view (v) that responds to a single tap:
UITapGestureRecognizer* t =
[[UITapGestureRecognizer alloc]
initWithTarget:self
action:@selector(singleTap)];
[v addGestureRecognizer:t];
// ...
- (void) singleTap {
NSLog(@"single");
}And here’s code that implements a view (v) that responds to a double tap:
UITapGestureRecognizer* t =
[[UITapGestureRecognizer alloc]
initWithTarget:self
action:@selector(doubleTap)];
t.numberOfTapsRequired = 2;
[v addGestureRecognizer:t];
// ...
- (void) doubleTap {
NSLog(@"double");
}For a continuous gesture like dragging, we need to know both when the gesture is in progress and when the gesture ends. This brings us to the subject of a gesture recognizer’s state.
A gesture recognizer implements a notion of states (the state property); it passes through these states in a definite progression. The gesture recognizer remains in the Possible state until it can make a decision one way or the other as to whether this is in fact the correct gesture. The documentation neatly lays out the possible progressions:
The actual state names are UIGestureRecognizerStatePossible and so forth. The name UIGestureRecognizerStateRecognized is actually a synonym for the Ended state; I find this unnecessary and confusing and I’ll ignore it in my discussion.
The same action message arrives at the same target every time, so the handler must differentiate by asking about the gesture recognizer’s state. To illustrate, we will implement, using a gesture recognizer, a view (v) that lets itself be dragged around in any direction by a single finger. Our maintenance of state is greatly simplified, because a UIPanGestureRecognizer maintains a delta (translation) for us. This delta, available using translationInView:, is reckoned from the touch’s initial position. So we need to store our center only once:
UIPanGestureRecognizer* p =
[[UIPanGestureRecognizer alloc]
initWithTarget:self
action:@selector(dragging:)];
[v addGestureRecognizer:p];
// ...
- (void) dragging: (UIPanGestureRecognizer*) p {
UIView* vv = p.view;
if (p.state == UIGestureRecognizerStateBegan)
self->_origC = vv.center;
CGPoint delta = [p translationInView: vv.superview];
CGPoint c = self->_origC;
c.x += delta.x; c.y += delta.y;
vv.center = c;
}Actually, it’s possible to write that code without maintaining any state at all, because we are allowed to reset the UIPanGestureRecognizer’s delta, using setTranslation:inView:. So:
- (void) dragging: (UIPanGestureRecognizer*) p {
UIView* vv = p.view;
if (p.state == UIGestureRecognizerStateBegan ||
p.state == UIGestureRecognizerStateChanged) {
CGPoint delta = [p translationInView: vv.superview];
CGPoint c = vv.center;
c.x += delta.x; c.y += delta.y;
vv.center = c;
[p setTranslation: CGPointZero inView: vv.superview];
}
}A pan gesture recognizer can be used also to make a view draggable under the influence of a UIDynamicAnimator (Chapter 4). The strategy here is that the view is attached to one or more anchor points through a UIAttachmentBehavior; as the user drags, we move the anchor point(s), and the view follows. In this example, I set up the whole UIKit dynamics “stack” of objects as the gesture begins, anchoring the view at the point where the touch is; then I move the anchor point to stay with the touch. Instance variables anim and att store the UIDynamicAnimator and the UIAttachmentBehavior, respectively; self.view is our view’s superview, and is the animator’s reference view:
- (void) dragging: (UIPanGestureRecognizer*) g {
if (g.state == UIGestureRecognizerStateBegan) {
self.anim =
[[UIDynamicAnimator alloc] initWithReferenceView:self.view];
CGPoint loc = [g locationOfTouch:0 inView:g.view];
CGPoint cen =
CGPointMake(CGRectGetMidX(g.view.bounds),
CGRectGetMidY(g.view.bounds));
UIOffset off = UIOffsetMake(loc.x-cen.x, loc.y-cen.y);
CGPoint anchor = [g locationOfTouch:0 inView:self.view];
UIAttachmentBehavior* att =
[[UIAttachmentBehavior alloc] initWithItem:g.view
offsetFromCenter:off attachedToAnchor:anchor];
[self.anim addBehavior:att];
self.att = att;
}
else if (g.state == UIGestureRecognizerStateChanged) {
self.att.anchorPoint = [g locationOfTouch:0 inView:self.view];
}
else {
self.anim = nil;
}
}The outcome is that the view both moves and rotates in response to dragging, like a plate being pulled about on a table by a single finger. Another implementation, suggested in a WWDC 2013 video, is to attach the view by springs to four anchor points at some distance outside its corners and move all four anchor points; the view then jiggles while being dragged.
The question naturally arises of what happens when multiple gesture recognizers are in play. This isn’t a matter merely of multiple recognizers attached to a single view, because, as I have said, if a view is touched, not only its own gesture recognizers but any gesture recognizers attached to views further up the view hierarchy are also in play, simultaneously. I like to think of a view as surrounded by a swarm of gesture recognizers — its own, and those of its superview, and so on. (In reality, it is a touch that has a swarm of gesture recognizers; that’s why a UITouch has a gestureRecognizers property, in the plural.)
The superview gesture recognizer swarm comes as a surprise to beginners, but it makes sense, because without it, certain gestures would be impossible. Imagine, for example, a pair of views on each of which the user can tap individually, but which the user can also touch simultaneously (one finger on each view) and rotate together around their mutual centroid. Neither view can detect the rotation qua rotation, because neither view receives both touches; only the superview can detect it, so the fact that the views themselves respond to touches must not prevent the superview’s gesture recognizer from operating.
In general, once a gesture recognizer succeeds in recognizing its gesture, any other gesture recognizers associated with its touches are forced into the Failed state, and whatever touches were associated with those gesture recognizers are no longer sent to them; in effect, the first gesture recognizer in a swarm that recognizes its gesture owns the gesture, and those touches, from then on.
In many cases, this “first past the post” behavior, on its own, will correctly eliminate conflicts. If it doesn’t, you can modify it.
For example, we can add both our UITapGestureRecognizer for a single tap and our UIPanGestureRecognizer to a view and everything will just work; “first past the post” is exactly the desired behavior. What happens, though, if we also add the UITapGestureRecognizer for a double tap? Dragging works, and single tap works; double tap works too, but without preventing the single tap from working. So, on a double tap, both the single tap action handler and the double tap action handler are called.
If that isn’t what we want, we don’t have to use delayed performance, as we did earlier. Instead, we can create a dependency between one gesture recognizer and another, telling the first to suspend judgement until the second has decided whether this is its gesture. We can do this by sending the first gesture recognizer the requireGestureRecognizerToFail: message. (This message is rather badly named; it doesn’t mean “force this other recognizer to fail”, but rather, “you can’t succeed unless this other recognizer has failed.”)
So our view v is now configured as follows:
UITapGestureRecognizer* t2 = [[UITapGestureRecognizer alloc]
initWithTarget:self
action:@selector(doubleTap)];
t2.numberOfTapsRequired = 2;
[v addGestureRecognizer:t2];
UITapGestureRecognizer* t1 = [[UITapGestureRecognizer alloc]
initWithTarget:self
action:@selector(singleTap)];
[t1 requireGestureRecognizerToFail:t2];
[v addGestureRecognizer:t1];
UIPanGestureRecognizer* p = [[UIPanGestureRecognizer alloc]
initWithTarget:self
action:@selector(dragging:)];
[v addGestureRecognizer:p];Apple would prefer, if you’re going to have a view respond both to a single tap and to a double tap, that you not make the former wait upon the latter (because this delays your response after the single tap). Rather, they would like you to arrange things so that it doesn’t matter that you respond to a single tap that is the first tap of a double tap. This isn’t always feasible, of course; Apple’s own Mobile Safari is a clear counterexample.
Another conflict that can arise is between a gesture recognizer and a view that already knows how respond to the same gesture, such as a UIControl. This problem pops up particularly when the gesture recognizer belongs to the UIControl’s superview. The UIControl’s mere presence does not “block” the superview’s gesture recognizer from recognizing a gesture on the UIControl, even if it is a UIControl that responds autonomously to touches. For example, your window’s root view might have a UITapGestureRecognizer attached to it (perhaps because you want to be able to recognize taps on the background), but there is also a UIButton within it. How is that gesture recognizer to ignore a tap on the button?
The UIView instance method gestureRecognizerShouldBegin: solves the problem. It is called automatically; to modify its behavior, use a custom UIView subclass and override it. Its parameter is a gesture recognizer belonging to this view or to a view further up the view hierarchy. That gesture recognizer has recognized its gesture as taking place in this view; but by returning NO, the view can tell the gesture recognizer to bow out and do nothing, not sending any action messages, and permitting this view to respond to the touch as if the gesture recognizer weren’t there.
Thus, for example, a UIButton could return NO for a single tap UITapGestureRecognizer; a single tap on the button would then trigger the button’s action message, not the gesture recognizer’s action message. And in fact a UIButton, by default, does return NO for a single tap UITapGestureRecognizer whose view is not the UIButton itself. (If the gesture recognizer is for some gesture other than a tap, then the problem never arises, because a tap on the button won’t cause the gesture recognizer to recognize in the first place.) Other built-in controls may also implement gestureRecognizerShouldBegin: in such a way as to prevent accidental interaction with a gesture recognizer; the documentation says that a UISlider implements it in such a way that a UISwipeGestureRecognizer won’t prevent the user from sliding the “thumb,” and there may be other cases that aren’t documented explicitly. Naturally, you can take advantage of this feature in your own UIView subclasses.
Another way of resolving possible gesture recognizer conflicts is through the gesture recognizer’s delegate, or with a gesture recognizer subclass. I’ll discuss these in a moment.
To subclass UIGestureRecognizer or a built-in gesture recognizer subclass, you must do the following things:
<UIKit/UIGestureRecognizerSubclass.h>. This file contains a category on UIGestureRecognizer that allows you to set the gesture recognizer’s state (which is otherwise read-only), along with declarations for the methods you may need to override.
touches... methods you need to (as if the gesture recognizer were a UIResponder); if you’re subclassing a built-in gesture recognizer subclass, you will almost certainly call super so as to take advantage of the built-in behavior. In overriding a touches... method, you need to think like a gesture recognizer. As these methods are called, a gesture recognizer is setting its state; you must interact with that process.
To illustrate, we will subclass UIPanGestureRecognizer so as to implement a view that can be moved only horizontally or vertically. Our strategy will be to make two UIPanGestureRecognizer subclasses — one that allows only horizontal movement, and another that allows only vertical movement. They will make their recognition decisions in a mutually exclusive manner, so we can attach an instance of each to our view. This separates the decision-making logic in a gorgeously encapsulated object-oriented manner — a far cry from the spaghetti code we wrote earlier to do this same task.
I will show only the code for the horizontal drag gesture recognizer, because the vertical recognizer is symmetrically identical. We maintain just one instance variable, _origLoc, which we will use once to determine whether the user’s initial movement is horizontal. We override touchesBegan:withEvent: to set our instance variable with the first touch’s location:
- (void) touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
self->_origLoc =
[(UITouch*)touches.anyObject locationInView:self.view.superview];
[super touchesBegan: touches withEvent: event];
}We then override touchesMoved:withEvent:; all the recognition logic is here. This method will be called for the first time with the state still at Possible. At that moment, we look to see if the user’s movement is more horizontal than vertical. If it isn’t, we set the state to Failed. But if it is, we just step back and let the superclass do its thing:
- (void) touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event {
if (self.state == UIGestureRecognizerStatePossible) {
CGPoint loc =
[(UITouch*)touches.anyObject locationInView:self.view.superview];
CGFloat deltaX = fabs(loc.x - self->_origLoc.x);
CGFloat deltaY = fabs(loc.y - self->_origLoc.y);
if (deltaY >= deltaX)
self.state = UIGestureRecognizerStateFailed;
}
[super touchesMoved: touches withEvent:event];
}We now have a view that moves only if the user’s initial gesture is horizontal. But that isn’t the entirety of what we want; we want a view that, itself, moves horizontally only. To implement this, we’ll simply lie to our client about where the user’s finger is, by overriding translationInView::
- (CGPoint)translationInView:(UIView *)v {
CGPoint proposedTranslation = [super translationInView:v];
proposedTranslation.y = 0;
return proposedTranslation;
}That example was simple, because we subclassed a fully functional built-in UIGestureRecognizer subclass. If you were to write your own UIGestureRecognizer subclass entirely from scratch, there would be more work to do:
touches... handlers. Their job, at a minimum, is to advance the gesture recognizer through the canonical progression of its states. When the first touch arrives at a gesture recognizer, its state will be Possible; you never explicitly set the recognizer’s state to Possible yourself. As soon as you know this can’t be our gesture, you set the state to Failed (Apple says that a gesture recognizer should “fail early, fail often”). If the gesture gets past all the failure tests, you set the state instead either to Ended (for a discrete gesture) or to Began (for a continuous gesture); if Began, then you might set it to Changed, and ultimately you must set it to Ended. Action messages will be sent automatically at the appropriate moments.
reset. This is called after you reach the end of the progression of states to notify you that the gesture recognizer’s state is about to be set back to Possible; it is your chance to return your state machine to its starting configuration (resetting instance variables, for example).
Keep in mind that your gesture recognizer might stop receiving touches without notice. Just because it gets a touchesBegan:withEvent: call for a particular touch doesn’t mean it will ever get touchesEnded:withEvent: for that touch. If your gesture recognizer fails to recognize its gesture, either because it declares failure or because it is still in the Possible state when another gesture recognizer recognizes, it won’t get any more touches... calls for any of the touches that were being sent to it. This is why reset is so important; it’s the one reliable signal that it’s time to clean up and get ready to receive the beginning of another possible gesture.
A gesture recognizer can have a delegate (UIGestureRecognizerDelegate), which can perform two types of task.
These delegate methods can block a gesture recognizer’s operation:
gestureRecognizerShouldBegin:
gestureRecognizerShouldBegin: has been sent to the view in which the touch took place. That view must not have returned NO, or we wouldn’t have reached this stage.)
gestureRecognizer:shouldReceiveTouch:
touchesBegan:... method; return NO to prevent that touch from ever being sent to the gesture recognizer.
These delegate methods can mediate gesture recognition conflict:
gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer:
gestureRecognizer:shouldRequireFailureOfGestureRecognizer:
gestureRecognizer:shouldBeRequiredToFailByGestureRecognizer:
requireGestureRecognizerToFail: into a live decision that can be made freshly every time a gesture occurs.
As an example, we will use delegate messages to combine a UILongPressGestureRecognizer and a UIPanGestureRecognizer, as follows: the user must perform a tap-and-a-half (tap and hold) to “get the view’s attention,” which we will indicate by a pulsing animation on the view; then (and only then) the user can drag the view.
The UILongPressGestureRecognizer’s handler will take care of starting and stopping the animation (and the UIPanGestureRecognizer’s handler will take care of the drag, as shown earlier in this chapter):
- (void) longPress: (UILongPressGestureRecognizer*) lp {
if (lp.state == UIGestureRecognizerStateBegan) {
CABasicAnimation* anim =
[CABasicAnimation animationWithKeyPath: @"transform"];
anim.toValue =
[NSValue valueWithCATransform3D:
CATransform3DMakeScale(1.1, 1.1, 1)];
anim.fromValue =
[NSValue valueWithCATransform3D:CATransform3DIdentity];
anim.repeatCount = HUGE_VALF;
anim.autoreverses = YES;
[lp.view.layer addAnimation:anim forKey:nil];
}
if (lp.state == UIGestureRecognizerStateEnded ||
lp.state == UIGestureRecognizerStateCancelled) {
[lp.view.layer removeAllAnimations];
}
}As we created our gesture recognizers, we kept a reference to the UILongPressGestureRecognizer (longPresser), and we made ourself the UIPanGestureRecognizer’s delegate. So we will receive delegate messages. If the UIPanGestureRecognizer tries to declare success while the UILongPressGestureRecognizer’s state is Failed or still at Possible, we prevent it. If the UILongPressGestureRecognizer succeeds, we permit the UIPanGestureRecognizer to operate as well:
- (BOOL) gestureRecognizerShouldBegin: (UIGestureRecognizer*) g {
if (self.longPresser.state == UIGestureRecognizerStatePossible ||
self.longPresser.state == UIGestureRecognizerStateFailed)
return NO;
return YES;
}
- (BOOL)gestureRecognizer: (UIGestureRecognizer*) g1
shouldRecognizeSimultaneouslyWithGestureRecognizer:
(UIGestureRecognizer*) g2 {
return YES;
}The result is that the view can be dragged only while it is pulsing; in effect, what we’ve done is to compensate, using delegate methods, for the fact that UIGestureRecognizer has no requireGestureRecognizerToSucceed: method.
If you are subclassing a gesture recognizer class, you can incorporate delegate-like behavior into the subclass, by overriding the following methods:
canPreventGestureRecognizer:
canBePreventedByGestureRecognizer:
shouldRequireFailureOfGestureRecognizer:
shouldBeRequiredToFailByGestureRecognizer:
The “Prevent” methods are similar to the delegate shouldBegin: method, and the “Fail” methods are similar to the delegate “Fail” methods. In this way, you can mediate gesture recognizer conflict at the class level. The built-in gesture recognizer subclasses already do this; that is why, for example, a single tap UITapGestureRecognizer does not, by recognizing its gesture, cause the failure of a double tap UITapGestureRecognizer.
You can also, in a gesture recognizer subclass, send ignoreTouch:forEvent: directly to a gesture recognizer (typically, to self). This has the same effect as the delegate method gestureRecognizer:shouldReceiveTouch: returning NO, blocking all future delivery of that touch to the gesture recognizer. For example, if you’re in the middle of an already recognized gesture and a new touch arrives, you might well elect to ignore it.
Instead of instantiating a gesture recognizer in code, you can create and configure it in a .xib or .storyboard file. In the nib editor, drag a gesture recognizer from the Object library into a view; the gesture recognizer becomes a top-level nib object, and the view’s gestureRecognizers outlet is connected to the gesture recognizer. (You can add more than one gesture recognizer to a view in the nib: the view’s gestureRecognizers property is an array, and its gestureRecognizers outlet is an outlet collection.) The gesture recognizer’s properties are configurable in the Attributes inspector, and the gesture recognizer has a delegate outlet. The gesture recognizer is a full-fledged nib object, so you can make an outlet to it.
To configure a gesture recognizer’s target–action pair in the nib, treat it like a UIControl’s control event. The action method’s signature should return IBAction, and it should take a single parameter, which will be a reference to the gesture recognizer. You will then be able to form the Sent Action connection in the usual way.
A gesture recognizer can have multiple target–action pairs, but only one target–action pair can be configured for a gesture recognizer using the nib editor.
A view retains its gesture recognizers, so there will usually be no need for additional memory management on a gesture recognizer instantiated from a nib.
Here’s the full standard procedure by which a touch is delivered to views and gesture recognizers:
userInteractionEnabled, hidden, and alpha is implemented at this stage.
Each time the touch situation changes, the application calls its own sendEvent:, which in turn calls the window’s sendEvent:. The window delivers each of an event’s touches by calling the appropriate touches... method(s), as follows:
As a touch first appears, the logic of obedience to multipleTouchEnabled and exclusiveTouch is considered. If permitted by that logic (which I’ll discuss in detail later):
If a gesture is recognized by a gesture recognizer, then for any touch associated with this gesture recognizer:
touchesCancelled:forEvent: is sent to the touch’s view, and the touch is no longer delivered to its view.
touches... method, a responder further up the responder chain is sought that does respond to it, and the touch is delivered there.
The rest of this chapter discusses the details. As you’ll see, nearly every bit of that standard procedure can be customized to some extent.
Hit-testing is the determination of what view the user touched. View hit-testing uses the UIView instance method hitTest:withEvent:, which returns either a view (the hit-test view) or nil. The idea is to find the frontmost view containing the touch point. This method uses an elegant recursive algorithm, as follows:
hitTest:withEvent: first calls the same method on its own subviews, if it has any, because a subview is considered to be in front of its superview. The subviews are queried in reverse order, because that’s front-to-back order (Chapter 1): thus, if two sibling views overlap, the one in front reports the hit first.
If, on the other hand, a view has no subviews, or if all of its subviews return nil (indicating that neither they nor their subviews was hit), then the view calls pointInside:withEvent: on itself. If this call reveals that the touch was inside this view, the view returns itself, declaring itself the hit-test view; otherwise it returns nil.
No problem arises if a view has a transform, because pointInside:withEvent: takes the transform into account. That’s why a rotated button continues to work correctly.
It is also up to hitTest:withEvent: to implement the logic of touch restrictions exclusive to a view. If a view’s userInteractionEnabled is NO, or its hidden is YES, or its alpha is close to 0.0, it returns nil without hit-testing any of its subviews and without calling pointInside:withEvent:. Thus these restrictions do not, of themselves, exclude a view from being hit-tested; on the contrary, they operate precisely by modifying a view’s hit-test result.
However, hit-testing knows nothing about multipleTouchEnabled (which involves multiple touches) or exclusiveTouch (which involves multiple views). The logic of obedience to these properties is implemented at a later stage of the story.
You can use hit-testing yourself at any moment where it might prove useful. In calling hitTest:withEvent:, supply a point in the coordinates of the view to which the message is sent. The second parameter can be nil if you have no event.
For example, suppose we have a UIView with two UIImageView subviews. We want to detect a tap in either UIImageView, but we want to handle this at the level of the UIView. We can attach a UITapGestureRecognizer to the UIView, but how will we know which subview, if any, the tap was in?
First, verify that userInteractionEnabled is YES for both UIImageViews. UIImageView is one of the few built-in view classes where this is NO by default, and a view whose userInteractionEnabled is NO won’t normally be the result of a call to hitTest:withEvent:. Then, when our gesture recognizer’s action handler is called, we can use hit-testing to determine where the tap was:
// g is the gesture recognizer
CGPoint p = [g locationOfTouch:0 inView:g.view];
UIView* v = [g.view hitTest:p withEvent:nil];
if (v && [v isKindOfClass:[UIImageView class]]) { // ...You can also override hitTest:withEvent: in a view subclass, to alter its results during touch delivery, thus customizing the touch delivery mechanism. I call this hit-test munging. Hit-test munging can be used selectively as a way of turning user interaction on or off in an area of the interface. In this way, some unusual effects can be produced.
An important use of hit-test munging is to permit the touching of parts of subviews outside the bounds of their superview. If a view’s clipsToBounds is NO, a paradox arises: the user can see the regions of its subviews that are outside its bounds, but can’t touch them. This can be confusing and seems wrong. The solution is for the view to override hitTest:withEvent: as follows:
-(UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event {
UIView* result = [super hitTest:point withEvent:event];
if (result)
return result;
for (UIView* sub in [self.subviews reverseObjectEnumerator]) {
CGPoint pt = [self convertPoint:point toView:sub];
result = [sub hitTest:pt withEvent:event];
if (result)
return result;
}
return nil;
}There is also hit-testing for layers. It doesn’t happen automatically, as part of sendEvent: or anything else; it’s up to you. It’s just a convenient way of finding out which layer would receive a touch at a point, if layers received touches. To hit-test layers, call hitTest: on a layer, with a point in superlayer coordinates.
Keep in mind, though, that layers do not receive touches. A touch is reported to a view, not a layer. A layer, except insofar as it is a view’s underlying layer and gets touch reporting because of its view, is completely untouchable; from the point of view of touches and touch reporting, it’s as if the layer weren’t on the screen at all. No matter where a layer may appear to be, a touch falls through the layer, to whatever view is behind it.
In the case of the layer that is a view’s underlying layer, you don’t need hit-testing. It is the view’s drawing; where it appears is where the view is. So a touch in that layer is equivalent to a touch in its view. Indeed, one might say (and it is often said) that this is what views are actually for: to provide layers with touchability.
The only layers on which you’d need special hit-testing, then, would presumably be layers that are not themselves any view’s underlying layer, because those are the only ones you don’t find out about by normal view hit-testing. However, all layers, including a layer that is its view’s underlying layer, are part of the layer hierarchy, and can participate in layer hit-testing. So the most comprehensive way to hit-test layers is to start with the topmost layer, the window’s layer. In this example, we subclass UIWindow and override its hitTest:withEvent: so as to get layer hit-testing every time there is view hit-testing:
- (UIView*) hitTest:(CGPoint)point withEvent:(UIEvent *)event {
CALayer* lay = [self.layer hitTest:point];
// ... possibly do something with that information ...
return [super hitTest:point withEvent:event];
}In that example, the view hit-test point works as the layer hit-test point; window bounds are screen bounds (Chapter 1). But usually you’ll have to convert to superlayer coordinates. In this next example, we return to the CompassView developed in Chapter 3, in which all the parts of the compass are layers; we want to know whether the user tapped on the arrow layer. For simplicity, we’ve given the CompassView a UITapGestureRecognizer, and this is its action handler, in the CompassView itself. We convert to our superview’s coordinates, because these are also our layer’s superlayer coordinates:
// self is the CompassView CGPoint p = [t locationOfTouch: 0 inView: self.superview]; CALayer* hitLayer = [self.layer hitTest:p]; if (hitLayer == ((CompassLayer*)self.layer).arrow) // ...
Layer hit-testing works by calling containsPoint:. However, containsPoint: takes a point in the layer’s coordinates, so to hand it a point that arrives through hitTest: you must first convert from superlayer coordinates:
BOOL hit =
[lay containsPoint: [lay convertPoint:point fromLayer:lay.superlayer]];Layer hit-testing knows nothing of the restrictions on touch delivery; it just reports on every sublayer, even one whose view (for example) has userInteractionEnabled set to NO.
The documentation warns that hitTest: must not be called on a CATransformLayer.
The preceding example (letting the user tap on the compass arrow) worked, but we might complain that it is reporting a hit on the arrow even if the hit misses the drawing of the arrow. That’s true for view hit-testing as well. A hit is reported if we are within the view or layer as a whole; hit-testing knows nothing of drawing, transparent areas, and so forth.
If you know how the region is drawn and can reproduce the edge of that drawing as a CGPath, you can test whether a point is inside it with CGPathContainsPoint. So, for a layer, you could override hitTest along these lines:
- (CALayer*) hitTest:(CGPoint)p {
CGPoint pt = [self convertPoint:p fromLayer:self.superlayer];
CGMutablePathRef path = CGPathCreateMutable();
// ... draw path here ...
CALayer* result =
CGPathContainsPoint(path, nil, pt, true) ? self : nil;
CGPathRelease(path);
return result;
}Alternatively, it might be the case that if a pixel of the drawing is transparent, it’s outside the drawn region, so that it suffices to detect whether the pixel tapped is transparent. Unfortunately, there’s no way to ask a drawing (or a view, or a layer) for the color of a pixel; you have to make a bitmap and copy the drawing into it, and then ask the bitmap for the color of a pixel. If you can reproduce the content as an image, and all you care about is transparency, you can make a one-pixel alpha-only bitmap, draw the image in such a way that the pixel you want to test is the pixel drawn into the bitmap, and examine the transparency of the resulting pixel:
// assume im is a UIImage, point is the CGPoint to test
unsigned char pixel[1] = {0};
CGContextRef context =
CGBitmapContextCreate(pixel, 1, 1, 8, 1, nil,
(CGBitmapInfo)kCGImageAlphaOnly);
UIGraphicsPushContext(context);
[im drawAtPoint:CGPointMake(-point.x, -point.y)];
UIGraphicsPopContext();
CGContextRelease(context);
CGFloat alpha = pixel[0]/255.0;
BOOL transparent = alpha < 0.01;However, there may not be a one-to-one relationship between the pixels of the underlying drawing and the points of the drawing as portrayed on the screen — because the drawing is stretched, for example. In many cases, the CALayer method renderInContext: can be helpful here. This method allows you to copy a layer’s actual drawing into a context of your choice. If that context is, say, an image context created with UIGraphicsBeginImageContextWithOptions, you can now use the resulting image as im in the code above:
UIGraphicsBeginImageContextWithOptions(self.bounds.size, NO, 0); CALayer* lay = // ... the layer whose content we're interested in [lay renderInContext:UIGraphicsGetCurrentContext()]; UIImage* im = UIGraphicsGetImageFromCurrentImageContext(); UIGraphicsEndImageContext(); // ... and the rest is as before
The simplest solution to the problem of touch during animation is to disallow it entirely. By default, view animation turns off touchability of a view while it’s being animated (though you can prevent that with UIViewAnimationOptionAllowUserInteraction in the options: argument), and you can temporarily turn off touchability altogether with UIApplication’s beginIgnoringInteractionEvents, as I mentioned earlier in this chapter.
If user interaction is allowed during an animation that moves a view from one place to another, then if the user taps on the animated view, the tap might mysteriously fail because the view in the model layer is elsewhere; conversely, the user might accidentally tap where the view actually is in the model layer, and the tap will hit the animated view even though it appears to be elsewhere. If the position of a view or layer is being animated and you want the user to be able to tap on it, therefore, you’ll need to hit-test the presentation layer.
In this simple example, we have a superview containing a subview. To allow the user to tap on the subview even when it is being animated, we implement hit-test munging in the superview:
- (UIView*) hitTest:(CGPoint)point withEvent:(UIEvent *)event {
// v is the animated subview
CALayer* lay = [v.layer presentationLayer];
CALayer* hitLayer = [lay hitTest: point];
if (hitLayer == lay)
return v;
UIView* hitView = [super hitTest:point withEvent:event];
if (hitView == v)
return self;
return hitView;
}If the user taps outside the presentation layer, we cannot simply call super, because the user might tap at the spot to which the subview has in reality already moved (behind the “animation movie”), in which case super will report that it hit the subview. So if super does report this, we return self (assuming that we are what’s behind the animated subview at its new location).
However, as Apple puts it in the WWDC 2011 videos, the animated view “swallows the touch.” For example, suppose the view in motion is a button. Although our hit-test munging makes it possible for the user to tap the button as it is being animated, and although the user sees the button highlight in response, the button’s action message is not sent in response to this highlighting if the animation is in-flight when the tap takes place. This behavior seems unfortunate, but it’s generally possible to work around it (for instance, with a gesture recognizer).
When the touch situation changes, an event containing all touches is handed to the UIApplication instance by calling its sendEvent:, and the UIApplication in turn hands it to the relevant UIWindow by calling its sendEvent:. The UIWindow then performs the complicated logic of examining, for every touch, the hit-test view and its superviews and their gesture recognizers and deciding which of them should be sent a touches... message, and does so.
These are delicate and crucial maneuvers, and you wouldn’t want to lame your application by interfering with them. Nevertheless, you can override sendEvent: in a subclass, and this is just about the only reason you might have for subclassing UIApplication; if you do, remember to change the third argument in the call to UIApplicationMain in your main.m file to the string name of your UIApplication subclass, so that your subclass is used to generate the app’s singleton UIApplication instance. Subclassing UIWindow is discussed in Chapter 1.
It is unlikely, however, that you will need to resort to such measures. A typical case before the advent of gesture recognizers was that you needed to detect touches directed to an object of some built-in interface class in a way that subclassing it wouldn’t permit. For example, you want to know when the user swipes a UIWebView; you’re not allowed to subclass UIWebView, and in any case it eats the touch. The solution used to be to subclass UIWindow and override sendEvent:; you would then work out whether this was a swipe on the UIWebView and respond accordingly, or else call super. Now, however, you can attach a UISwipeGestureRecognizer to the UIWebView.
When a touch first appears and is delivered to a gesture recognizer, it is also delivered to its hit-test view, the same touches... method being called on both. Later, if a gesture recognizer in a view’s swarm recognizes its gesture, that view is sent touchesCancelled:withEvent: for any touches that went to that gesture recognizer and were hit-tested to that view, and subsequently the view no longer receives those touches.
This comes as a surprise to beginners, but it is the most reasonable approach, as it means that touch interpretation by a view isn’t jettisoned just because gesture recognizers are in the picture. Later on in the multitouch sequence, if all the gesture recognizers in a view’s swarm declare failure to recognize their gesture, that view’s internal touch interpretation just proceeds as if gesture recognizers had never been invented.
Moreover, touches and gestures are two different things; sometimes you want to respond to both. In one of my apps, where the user can tap cards, each card has a single tap gesture recognizer and a double tap gesture recognizer, but it also responds directly to touchesBegan:withEvent: by reducing its own opacity (and restores its opacity on touchesEnded:withEvent: and touchesCancelled:withEvent:). The result is that user always sees feedback when touching a card, instantly, regardless of what the gesture turns out to be.
This behavior can be changed by setting a gesture recognizer’s cancelsTouchesInView property to NO. If this is the case for every gesture recognizer in a view’s swarm, the view will receive touch events more or less as if no gesture recognizers were in the picture.
If a gesture recognizer happens to be ignoring a touch (because, for example, it was told to do so by ignoreTouch:forEvent:), then touchesCancelled:withEvent: won’t be sent to the view for that touch when that gesture recognizer recognizes its gesture. Thus, a gesture recognizer’s ignoring a touch is the same as simply letting it fall through to the view, as if the gesture recognizer weren’t there.
Gesture recognizers can also delay the delivery of touches to a view, and by default they do. The UIGestureRecognizer property delaysTouchesEnded is YES by default, meaning that when a touch reaches UITouchPhaseEnded and the gesture recognizer’s touchesEnded:withEvent: is called, if the gesture recognizer is still allowing touches to be delivered to the view because its state is still Possible, it doesn’t deliver this touch until it has resolved the gesture. When it does, either it will recognize the gesture, in which case the view will have touchesCancelled:withEvent: called instead (as already explained), or it will declare failure and now the view will have touchesEnded:withEvent: called.
The reason for this behavior is most obvious with a gesture where multiple taps are required. The first tap ends, but this is insufficient for the gesture recognizer to declare success or failure, so it withholds that touch from the view. In this way, the gesture recognizer gets the proper priority. In particular, if there is a second tap, the gesture recognizer should succeed and send touchesCancelled:withEvent: to the view — but it can’t do that if the view has already been sent touchesEnded:withEvent:.
It is also possible to delay the entire suite of touches... methods from being called on a view, by setting a gesture recognizer’s delaysTouchesBegan property to YES. Again, this delay would be until the gesture recognizer can resolve the gesture: either it will recognize it, in which case the view will have touchesCancelled:withEvent: called, or it will declare failure, in which case the view will receive touchesBegan:withEvent: plus any further touches... calls that were withheld — except that it will receive at most one touchesMoved:withEvent: call, the last one, because if a lot of these were withheld, to queue them all up and send them all at once now would be simply insane.
It is unlikely that you’ll change a gesture recognizer’s delaysTouchesBegan property to YES, however. You might do so, for example, if you have an elaborate touch analysis within a view that simply cannot operate simultaneously with a gesture recognizer, but this is improbable, and the latency involved may look strange to your user.
When touches are delayed and then delivered, what’s delivered is the original touch with the original event, which still have their original timestamps. Because of the delay, these timestamps may differ significantly from now. For this reason (and many others), Apple warns that touch analysis that is concerned with timing should always look at the timestamp, not the clock.
It is up to the UIWindow’s sendEvent: to implement the logic of multipleTouchEnabled and exclusiveTouch.
If a new touch is hit-tested to a view whose multipleTouchEnabled is NO and which already has an existing touch hit-tested to it, then sendEvent: never delivers the new touch to that view. However, that touch is delivered to the view’s swarm of gesture recognizers.
Similarly, if there’s an exclusiveTouch view in the window, then sendEvent: must decide whether a particular touch should be delivered, in accordance with the meaning of exclusiveTouch, which I described earlier. If a touch is not delivered to a view because of exclusiveTouch restrictions, it is not delivered to its swarm of gesture recognizers either.
The logic of touch delivery to gesture recognizers in response to exclusiveTouch has changed in a confusing and possibly buggy way from system to system, but I believe I’m describing it correctly for the current system. The statement in Apple’s SimpleGestureRecognizers sample code that “Recognizers ignore the exclusive touch setting for views” probably dates back to an earlier implementation; it appears to be flat-out false at this point.
When a gesture recognizer recognizes its gesture, everything changes. As we’ve already seen, the touches for this gesture recognizer are sent to their hit-test views as a touchesCancelled:forEvent: message, and then no longer arrive at those views (unless the gesture recognizer’s cancelsTouchesInView is NO). Moreover, all other gesture recognizers pending with regard to these touches are made to fail, and then are no longer sent the touches they were receiving either.
If the very same event would cause more than one gesture recognizer to recognize, there’s an algorithm for picking the one that will succeed and make the others fail: a gesture recognizer lower down the view hierarchy (closer to the hit-test view) prevails over one higher up the hierarchy, and a gesture recognizer more recently added to its view prevails over one less recently added.
There are various means for modifying this “first past the post” behavior:
Certain methods institute a dependency order, causing a gesture recognizer to be put on hold when it tries to transition from the Possible state to the Began (continuous) or Ended (discrete) state; only if a certain other gesture recognizer fails is this one permitted to perform that transition. Apple says that in a dependency like this, the gesture recognizer that fails first is not sent reset (and won’t receive any touches) until the second finishes its state sequence and is sent reset, so that they resume recognizing together. The methods are:
requireGestureRecognizerToFail: (sent to a gesture recognizer)
shouldRequireFailureOfGestureRecognizer: (overridden in a subclass)
shouldBeRequiredToFailByGestureRecognizer: (overridden in a subclass)
gestureRecognizer:shouldRequireFailureOfGestureRecognizer: (implemented by the delegate)
gestureRecognizer:shouldBeRequiredToFailByGestureRecognizer: (implemented by the delegate)
The first of those methods sets up a permanent relationship between two gesture recognizers, and cannot be undone; but the others are sent every time a gesture starts in a view whose swarm includes both gesture recognizers, and applies only on this occasion.
The delegate methods work together as follows. For each pair of gesture recognizers in the hit-test view’s swarm, the members of that pair are arranged in a fixed order (as I’ve already described). The first of the pair is sent shouldRequire and then shouldBeRequired, and then the second of the pair is sent shouldRequire and then shouldBeRequired. But if any of those four methods returns YES, the relationship between that pair is settled; the sequence stops (and we proceed to the next pair).
Certain methods, by returning NO, turn success into failure; at the moment when the gesture recognizer is about to declare that it recognizes its gesture, transitioning from the Possible state to the Began (continuous) or Ended (discrete) state, it is forced to fail instead:
gestureRecognizerShouldBegin:
gestureRecognizerShouldBegin:
A gesture recognizer succeeds, but some other gesture recognizer is not forced to fail, in accordance with these methods:
gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer: (implemented by the delegate)
canPreventGestureRecognizer: (overridden in a subclass)
canBePreventedByGestureRecognizer: (overridden in a subclass)
In the subclass methods, “prevent” means “by succeeding, you force failure upon this other,” and “be prevented” means “by succeeding, this other forces failure on you.” They work together as follows. canPreventGestureRecognizer: is called first; if it returns NO, that’s the end of the story for that gesture recognizer, and canPreventGestureRecognizer: is called on the other gesture recognizer. But if canPreventGestureRecognizer: returns YES when it is first called, the other gesture recognizer is sent canBePreventedByGestureRecognizer:. If it returns YES, that’s the end of the story; if it returns NO, the process starts over the other way around, sending canPreventGestureRecognizer: to the second gesture recognizer, and so forth. In this way, conflicting answers are resolved without the device exploding: prevention is regarded as exceptional (even though it is in fact the norm) and will happen only if it is acquiesced to by everyone involved.
A UIView is a responder, and participates in the responder chain. In particular, if a touch is to be delivered to a UIView (because, for example, it’s the hit-test view) and that view doesn’t implement the relevant touches... method, a walk up the responder chain is performed, looking for a responder that does implement it; if such a responder is found, the touch is delivered to that responder. Moreover, the default implementation of the touches... methods — the behavior that you get if you call super — is to perform the same walk up the responder chain, starting with the next responder in the chain.
The relationship between touch delivery and the responder chain can be useful, but you must be careful not to allow it to develop into an incoherency. For example, if touchesBegan:withEvent: is implemented in a superview but not in a subview, then a touch to the subview will result in the superview’s touchesBegan:withEvent: being called, with the first parameter (the touches) containing a touch whose view is the subview. But most UIView implementations of the touches... methods rely upon the assumption that the first parameter consists of all and only touches whose view is self; built-in UIView subclasses certainly assume this.
Again, if touchesBegan:withEvent: is implemented in both a superview and a subview, and you call super in the subview’s implementation, passing along the same arguments that came in, then the same touch delivered to the subview will trigger both the subview’s touchesBegan:withEvent: and the superview’s touchesBegan:withEvent: (and once again the first parameter to the superview’s touchesBegan:withEvent: will contain a touch whose view is the subview).
The solution is to behave rationally, as follows:
touches... events together in one class, so that touches arrive at an instance either because it was the hit-test view or because it is up the responder chain from the hit-test view, and do not call super in any of them. In this way, “the buck stops here” — the touch handling for this object or for objects below it in the responder chain is bottlenecked into one well-defined place.
touches... event, but you do need to call super so that the built-in touch handling can occur.
Don’t allow touches to arrive from lower down the responder chain at an instance of a built-in UIView subclass that implements built-in touch handling, because such a class is completely unprepared for the first parameter of a touches... method containing a touch not intended for itself. Judicious use of userInteractionEnabled or hit-test munging can be a big help here.
I’m not saying, however, that you have to block all touches from percolating up the responder chain; it’s normal for unhandled touches to arrive at the UIWindow or UIApplication, for example, because these classes do not (by default) do any touch handling — so those touches will remain unhandled and will percolate right off the end of the responder chain, which is perfectly fine.
touches... method directly (except to call super).
Apple’s documentation has some discussion of a technique called event forwarding where you do call touches... methods directly. But you are far less likely to need this now that gesture recognizers exist, and it can be extremely tricky and even downright dangerous to implement, so I won’t give an example, and I suggest that you not use it.