More on UIGestureRecognizer

You have only scratched the surface of UIGestureRecognizer. There are more subclasses, more properties, and more delegate methods – and you can even create recognizers of your own. This section will give you an idea of what UIGestureRecognizer is capable of. You can study the documentation to learn even more.

When a gesture recognizer is on a view, it is really handling all of the UIResponder methods, like touchesBegan(_:with:), for you. Gesture recognizers are pretty greedy, so they typically do not let a view receive touch events, or they at least delay the delivery of those events. You can set properties on the recognizer, like delaysTouchesBegan, delaysTouchesEnded, and cancelsTouchesInView, to change this behavior. If you need finer control than this all-or-nothing approach, you can implement delegate methods for the recognizer.

At times, you may have two gesture recognizers looking for very similar gestures. You can chain recognizers together so that one is required to fail for the next one to start using the method require(toFail:). You used this method in init?(coder:) to make the tap recognizer wait for the double-tap recognizer to fail.

One thing you must understand to master gesture recognizers is how they interpret their state. Overall, there are seven states a recognizer can enter:

  • UIGestureRecognizerState.possible

  • UIGestureRecognizerState.failed

  • UIGestureRecognizerState.began

  • UIGestureRecognizerState.cancelled

  • UIGestureRecognizerState.changed

  • UIGestureRecognizerState.recognized

  • UIGestureRecognizerState.ended

The possible state is where recognizers spend most of their time. When a gesture transitions to any state other than the possible state or the failed state, the action message of the recognizer is sent and its state property can be checked to see why.

The failed state is used by recognizers watching for a multitouch gesture. At some point, the user’s fingers may achieve a position from which they can no longer make that recognizer’s gesture. At that point, the gesture recognizer fails. A recognizer enters the canceled state when it is interrupted, such as by an incoming phone call.

If a gesture is continuous, like a pan, the gesture recognizer will enter the began state and then go into the changed state until the gesture ends. When the gesture ends (or is canceled), the recognizer enters the ended (or canceled) state and sends its action message a final time before returning to the possible state.

For gesture recognizers that pick up on a discrete gesture like a tap, you will only see the recognized state (which has the same value as the ended state).

The four built-in recognizers that you did not implement in this chapter are UIPinchGestureRecognizer, UISwipeGestureRecognizer, UIScreenEdgePanGestureRecognizer, and UIRotationGestureRecognizer. Each has properties that allow you to fine-tune its behavior. The documentation will show you how.

Finally, if there is a gesture that you want to recognize that is not implemented by the built-in subclasses of UIGestureRecognizer, you can subclass UIGestureRecognizer yourself. This is an intense undertaking and outside the scope of this book. You can read the Methods for Subclassing section of the UIGestureRecognizer documentation to learn what is required.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset