Suppose there are two UIVIew subclasses in two different regions of the screen.
The first UIView subclass is a table or collectionView
The second view is a simple UIView.
Is it possible for gestures inside the second view to be "carried over" to the first view so that for example, a swipe up gesture in the second view would make the table/collection view scroll up ?
In WWDC 2012 Session 223: Enhancing User Experience with Scroll Views, Apple engineers explained that you can take a scroll view's panGestureRecognizer and add it to a different view to make that other view control the scroll view's scrolling.
Note that UITableView and UICollectionView are subclasses of UIScrollView.
So if you can put your table view and your second view into a common superview, you can move the table view's panGestureRecognizer to the superview and it will detect touches on both subviews.
[commonSuperview addGestureRecognizer:tableView.panGestureRecognizer];
The best way to achieve that is to encapsulate your 2 views in a another view and to add the GestureRecognizer on the motherView.
This way when the gesture triggers, with the location of the touch you can figure out if it started in one view or the other and you can track the move all the way to the second view.
Related
I've got a UITableView and a big "button" view in front of it. The "button" view, which has transparent areas, should be able to response to a tap. But enabling user interaction for this view blocks any scrolling touches from getting to the table view located under the "button" view.
The upper view is a UIView (not UIButton). Given how the two views work together, the upper view is essentially part of what's going on with the table view and reacts to the table view being scrolled. But scrolling is the main thing and I'd like the user to have the largest scrolling area possible.
How do I best resolve this conflict so that the table view is scrollable as usual?
I guess you could subclass your UIButton and UITableView common superview, and override its hitTest:withEvent: to verify which view is hit, something like if you are in a clear or an opaque part of the button?
As pbush25 is mentionning however, it goes more or less against Apple's recommendation.
I have one UIScrollView inside another UIScrollView, both scrolling vertically. I’m having an issue where when I try to scroll the inner scroll view, the touches are also picked up just afterwards by the outer scroll view. I need touches in the inner scroll view to be exclusively handled by it, and for scrollViewDidScroll to NOT be called on the parent scroll view.
I’ve tried all manner of things, subclassing the scroll view and overriding hitTest:withEvent, setting canCancelContentTouches, setting exclusiveTouch, nothing work at all. The scrollViewDidScroll methods are fired first on the inner one, then on the outer one.
How can I effectively kill the touch after the first scroll view, and not pass it up the responder chain to the outer scroll view?
(FYI: The hierarchy is that there’s a child view controller inbetween, so the outer scroll view contains a child view controller, which in turn contains the inner scroll view).
Apple definitely DOES NOT discourage UIScrollView inside UIScrollView. It's actually in the doc:
your application does not need to do anything to support nesting scrolling. It is supported and provided by default.
https://developer.apple.com/library/content/documentation/WindowsViews/Conceptual/UIScrollView_pg/NestedScrollViews/NestedScrollViews.html
If you want to disable the parent scroll view from scrolling, you can probably send a notification from the child, and set isScrollEnabled in parent.
I'm not sure if this is possible, but I have a view that is able to be dragged around the screen via pan gestures. Once the view is selected, little grippers appear on the corners of the view that allow the user to resize the view. The problem is, those grippers go outside the bounds of the view (they still show up, because clipSubviews is off), but gesture recognizers on those grippers are not firing when selecting the part of them that is drawn outside of the view. Making the view bigger to actually hold the grippers would break a lot of already created logic that is based on the size of the view, so that is a last resort for me.
Is there any other way to get gesture recognizers to work on views that are drawn outside of their parent view?
You could try overriding hitTest:withEvent: in a UIView subclass, and return the gripper view.
I have a small view (View Frame Size : 100,0,20,30), i want to add two gesture recognizer one is UIPanGestureRecognizer and another one is my own custom GesuterRecognizer "CPPinGestureRecognizer".
UIPanGestureRecognizer is used for drag the view in horizontally.
Example: the dragging bounds are :(100,0 to 320, 0)
CPPinGestureRecgonizer is used for enlarge the view in vertically with the same width.
Example: (enlarge view height up to user drag the view)
Now the problem is both gesture are working together and i want to check if the view dragged horizontally means want to fail CPPinGestureRecognizer, if the user dragged vertically means want to fail UIPanGestureRecognizer.
how can i achieve this.
Thanks in advance.
Gesture recognizers can have a delegate (UIGestureRecognizerDelegate), and this protocol has 2 methods: gestureRecognizer:shouldRequireFailureOfGestureRecognizer: and gestureRecognizer:shouldBeRequiredToFailByGestureRecognizer. You can use those to not allow one to be recognized while the other one is currently being recognized.
I'm building an iOS layout which consists of a UITableView and a UIScrollView. The UIScrollView is inside a table cell of the UITableView and can be scrolled both horizontally and vertically. The diagram below shows this situation. If the user begins scrolling down/up on the UIScrollView the scrolling event should trigger setContentOffset of the table view, and not setContentOffset for the scroll view while the top of the scroll view will be on the dotted line (it's constant height). Then a scrolling touch event should trigger setContentOffset for the scroll view, not for the table view.
In another case: When the user starts scrolling on the table view, it should trigger setContentOffset for the table view, until the scroll view reaches the dotted line. Then the scroll view should handle setContentOffset.
My problem is how to transfer touch events between the table view and the scroll view during one sliding action.
This sounds like one of those cases where you want something quite specific and custom. So trying to do something clever with the gesture recognizers won't be enough.
The main problem is that the ways you can control gesture recognizers such as with gestureRecognizer:shouldReceiveTouch: and gestureRecognizerShouldBegin: only affect the start of the gesture (or for new touches, not ongoing ones), but you want a single ongoing gesture to transition between controlling each view. So for this reason I think you will need to place a large transparent view over your entire screen with a pan gesture recognizer on it and in your handlePan method decide which view you want to adjust and then call setContentOffset directly on that view. You can use the translation of the pan recognizer and the existing content offset to calculate the new one. I know this isn't very elegant, but I can't think of another way to achieve the effect you want.
I'm not sure if this is going to work, but you could try doing something like this:
Option
self.scrollView.panGestureRecognizer = self.tableView.panGestureRecognizer;
Option
[self.scrollView addGestureRecognizer:self.tableView.panGestureRecognizer];
Option
[self.tableView.panGestureRecognizer requireGestureRecognizerToFail:self.scrollView.panGestureRecognizer];