I want to implement a feature similar to this:
View A and View B are all child views of the same parent UIView. View A and View B are sibling views. View A is the same frame size as the parent view. View B is only half of the size and it's above View A. I want to capture swipe events/gestures on View B, but still propagate other events/gestures (e.g. Tap) from View B to View A. So user can still interact with View A (e.g. tap on the button on View A) while View B is only capturing swipe gestures.
I have tried implementing following methods on View B
- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event
but seems like it's all or nothing approach. as I cannot detect in these methods if the event is a tap or a swipe. And I didn't find any API which can programatically trigger a tap on a UIView (not calling touch related methods).
You should move your rear sibling view to be a subview of the front view as this effective looks the same but makes the UIResponder chain behave correctly. UIGestureRecognizer can then do the rest of the work for you. Specifically it has a property, CancelsTocuhesInViews that you can turn off so it doesn't eat touch events and it has a delegate with methods that can allow you to specify the conditions under which a UIGestureRegonizer should fire. Implement the UIGestureRecognizerDelegate methods that you want to make your logic work. For instance if you want the overlay view to handle a tap only if a bunch of other gestureRecognizers don't handle the tap first then you implement gestureRecognizer(_:shouldRequireFailureOf:) and have it return true for every other gesture recognizer you want to go first; your gesture recognizer will then only fire when all of these other gesture recognizers have failed to handle the tap.
If I understand you correctly, what you want to do is usually done using UIGestureRecognizer objects and its subclasses. You can make one gesture recognizer (i.e. a swipe (or was it pan?) gesture recognizer) depend on another one (one for taps).
You can tell one gesture recognizer to only trigger when another has failed to detect its gesture. I haven't had to do that yet, so can't give you more detail, but I'd look into those classes and see if there's a way to chain them so it handles a swipe, and just does not handle taps. If you don't handle a tap, it should automatically go to any subview that will handle it, I think.
Related
I have a container view controller managing its own full-screen content view, with several gesture recognizers attached. A child view controller can be overlaid over a portion of the screen; its root view is a UIView providing the opaque background color, which is covered by a UIScrollView, which in turn contains a complex view hierarchy of stack views, etc.
Scrolling in the child works correctly, as well as any user interactions with its subviews. The problem I'm having is that any taps or other non-scrolling gestures on the the scroll view itself (i.e. not inside any of its subviews) fall through the empty UIView behind it and are unexpectedly handled by the gesture recognizers on the root view of the parent (container) controller. I want those touches to be swallowed up by the child's background view so that they are ignored/cancelled.
My first thought was to override nextResponder on the child VC to return nil, assuming that would prevent touch events from passing to the superview. No success there, so I tried overriding the touch handling methods (touchesBegan: etc.) on the child controller, but they never get called. Then I substituted a simple UIView subclass to be the root view of my child controller, likewise trying both of those approaches there instead. Again returning nil for nextResponder has no effect, and the touch methods never get called.
My responder chain looks to be set up exactly as I would expect: scroll view --> child VC's root view --> child VC --> parent's root view --> parent VC. That makes me think my controller containment is set up correctly, and makes me suspect that the gesture recognizers on the parent's root view are somehow winning out over the responder chain in a way that I don't understand.
This seems like it should be easy. What am I missing? Thanks!
I think I understand better what's going on here thanks to this very helpful WWDC video.
Given an incoming touch, first the system associates that touch with the deepest hit-tested view; in my case that's the UIScrollView. Then it apparently walks back up the hierarchy of superviews looking for any other attached recognizers. This behavior is implied by this key bit of documentation:
A gesture recognizer operates on touches hit-tested to a specific view and all of that view’s subviews.
The scroll view has its own internal pan recognizer(s), which either cancel unrecognized touches or possibly fall back on responder methods that don't happen to forward touches up the responder chain. That explains why my responder methods never get called, even when my own recognizers are disabled.
Armed with this information, I can think of a few possible ways to solve my problem, such as:
Use gesture delegate methods to ignore touches if/when the associated view is under a child controller.
Write a "null" gesture recognizer subclass that captures all touches and ignores them, and attach that to the root view of the child controller.
But what I ended up doing was simply to rearrange my view hierarchy with a new empty view at the top, so that my child controller views can be siblings of the main content view rather than its subviews.
So the view hierarchy changes from this:
to this:
This solves my problem: my gesture recognizers no longer interact with touches that are hit-tested to the child controller's views. And I think it better captures the conceptual relationships between my app's controllers, without requiring any additional logic.
I'm trying to enable interactive pop gesture recogniser on my keyboard's accessory view. It does not work by default.
I passed an interactive pop gesture recogniser reference to my accessory view in order to forward its touch events to the recogniser
It particularly works: the navigation bar's title gets changed and the background of the accessory view reveals the previous view controller's view as if the transition did start. But the top view itself remains in place even if the gesture recogniser completes tracking.
I also tried to forward touch events to the navigation controller itself, to its view, to its top view controller and to their window. Nothing changed even after forwarding to all of them simultaneously
Any ideas what is missing?
It looks like it is not possible to reuse touch event instances in the responder chain. Once the sendEvent: on UIWindow is called, there is already a certain view owning the touch, so there is no cense in forwarding the UIEvent instances to other views or their gesture recognisers.
However, the owning view can forward events to its nextResponder()s (e.g.: one of the gesture recognisers attached to this view or to one of the subviews of the view)
The only chance to forward touches to another view (from another view hierarchy) or another view's gesture recognisers is before the UITouch object creation: i.e. on the UIWindow level during the hitTest:withEvent: method invocation, which calls the pointInside:withEvent: method
Anyway I'm not sure whether it is possible to forward touches from one UIWindow to another. Will update the answer later
http://www.russbishop.net/uitouchtypestylus?utm_campaign=iOS%2BDev%2BWeekly&utm_medium=email&utm_source=iOS_Dev_Weekly_Issue_225
http://smnh.me/hit-testing-in-ios/
I want to watch in my UIView subclass for user touches on the screen. Especially there are some additional conditions:
the touch should not be catch by my view (for example, if user taps some button or scrolls something that action should be accepted)
there can be multiple views which are watching for touch and they should not conflict with each other
the approach should be as general as possible (so we can catch taps on tabbar or navigation buttons)
I can suppose to add specific fullscreen view with customized hitTest: method. This view has interface to add/remove delegates for watching for touches. But this method is "hard" in coding terms and I would like to find more elegant and simpler solution.
you can write touchesBegan in that UIView subclass.
Because if it had any subview like button or scrollView, they would be first responders ,and touches on scrollView wont fire touchesBegan of your UIView subclass.
And it wont conflict with other touch listeners unless the listener subView is explicitly passing that touch to your Subclass.
In UIViews, the next responder is its superview by default. In my project, there's a scroll view and a small uiview as scroll view's child view. I want if I touch in the small view, the scroll view shouldn't move. Let the responder chain break at the child view.
I am trying by inheriting the child view, and override the - (UIResponder *)nextResponder method to return nil. But it has no effect.
Update:
It seems that the child view didn't response to the Pan Gesture at all. When I scroll in child view, the - (UIResponder *)nextResponder method never called, but when I tap it, the method is called.
Gesture recognisers and the classic responder chain are mutually exclusive within the same view subtree.
-nextResponder isn't called because events are taking the gesture recognition path rather than the responder chain path.
Just use a gesture recogniser to do whatever event handling you're trying to achieve in the small view.
I have developped a small application with 2 View .
My first UIView is a Menu containing some images. When I click on one of them, I switch on the Second UIView to display it.
Afterwards, I created a new UIView who is a "menu extension" of my first Menu. I created a UIView but when I put the component "Swipe", the application do not switch to my second new menu.
I would like to know, if Iphone App supports several touch event on the UIView ?
Objects of class UIGestureRecognizer are attached to a UIView object, not to UIViewController objects. And it is possible to attach multiple gesture recognizers to a single view, see its gestureRecognizers property.
But you have to be careful: If you want a swipe to be recognized, a single tap recognizer might fire before the swipe could be recognized, since the latter requires the move of the finger. Therefore, you can configure multiple gesture recognizers of the same view such that they show the required behavior, e.g. that a single tap recognizer fires only when a swipe recognizer does not fire, etc., see the docs of UIGestureRecognizer Class Reference.