Conflicts with IOS gesture events

There are a few things to emphasize about hand operation:

• Uiimageview default is not interactive, that is, Userinteractionenabled=no, so to receive touch events (gesture recognition), you must set the Userinteractionenabled=yes (in iOS Uilabel, Uiimageview userinteractionenabled default is No,uibutton, Uitextfield, Uiscrollview, UITableView, and so on by default is YES).
• Although a swipe gesture is a continuous gesture, its manipulation events are called only once at the end of recognition, and other consecutive gestures are called multiple times, and the general needs to be state judged, and the swipe gesture supports four directions, but multiple swipe gestures are required to support multiple orientations.

Gesture conflicts

Careful child shoes will be found in the above demo when switching to the next or previous picture does not swipe the picture, but in a blank place to swipe to complete, because if I swipe the picture will cause a drag gesture rather than swipe gesture. In other words, there is a conflict between these two gestures.

The reason for the conflict is simple, the action event of the drag gesture is recognized in the start state (State 1) of the gesture, and the action event of the swipe gesture is performed only at the end of the gesture (state 3), so the swipe gesture is not recognized correctly as the victim. Our ideal situation is of course to move the picture if you drag it on the picture, or flip the picture if you swipe it on the image. How to resolve this conflict?

In iOS, if the recognition part of a gesture A is a sub-section of another gesture B, by default A is recognized and B is not recognized. To resolve this conflict can be exploited -(void) Requiregesturerecognizertofail: (Uigesturerecognizer *) Othergesturerecognizer; method to complete. It is the last method of Uigesturerecognizer in the preceding table, which specifies that a gesture executes if another gesture fails to recognize execution. That is, if we specify that the drag gesture is performed as a swipe gesture fails, then the system will prioritize the swipe gesture when we swipe lightly, and then drag if we finally find that the action is not a swipe. Just add the following code to the add gesture to solve the problem (note that to make it clearer to distinguish between dragging and swiping [in the simulator, a little faster is recognized as a swipe], the premise of long-press gestures is set to drag failure, to avoid the demonstration when dragging the long press gesture will be recognized):

    Resolve the conflict between drag gestures and swipe gestures when swiping on a picture    [Pangesture requiregesturerecognizertofail:swipegesturetoright];    [Pangesture Requiregesturerecognizertofail:swipegesturetoleft];    Resolve conflicts between drag and long-press gestures    [longpressgesture requiregesturerecognizertofail:pangesture];

Two gestures of different controls execute simultaneously

We know that in the touch event of iOS, the event trigger is based on the responder chain, and the upper touch event is no longer propagated downward. Gestures are similar by default, and gestures that are recognized first block gesture recognition from continuing to propagate. So how do you make two of the controls that have a hierarchical relationship and all the gestures added to the gesture correctly? The answer is to use the proxy -(BOOL) Gesturerecognizer: (Uigesturerecognizer *) Gesturerecognizer Shouldrecognizesimultaneouslywithgesturerecognizer: (Uigesturerecognizer *) Othergesturerecognizer method. This proxy method returns no by default, blocking continued recognition gestures, and continuing to propagate recognition downward if yes is returned.

Excerpt from: http://www.cnblogs.com/kenshincui/p/3950646.html Tri Jiangtao Thank bloggers

Conflicts with IOS gesture events