5

Think of a UIScrollView with embedded (subview) UIViews, arranged in a column. In iOS6 and previously, the scroll view could be configured so that when you flick it with your finger, the embedded views do not receive touch events even if the initial touch is on one of the subviews; but if you touch a subview without flicking, the scroll view decides this is not a scroll action and forwards the touch events to the embedded views. This was very convenient behavior if you wanted to be able to drag/drop the embedded UIViews within the UIScrollView.

In iOS 7 the documentation indicates that setting the UIScrollView property delaysContentTouches will cause touch-down events to be delayed until the UIScrollView decides whether it's being scrolled. But in fact, this simply does not appear to work. The subview immediately receives touch events and responds to them if the scrolling touch-down event is on one of the subviews. Thus if the subview is programmed for drag/drop it starts dragging while the scroll view also scrolls.

It appears that the model for this behavior has been changed, since iOS 5/6 both did suppress touch events while deciding whether this is a scroll action. Some new methods are now available to cancel the touch-down events after the UIScrollView decides it is scrolling. But obviously this is not useful if the drag/drop code has also started moving the subview.

My question: Is there any way to prevent iOS 7 UIScrollViews from invoking low-level touch-down events on its subviews, when you initiate a scrolling action by stroking a subview? When I say "low-level", I mean actual touch events as opposed to using gesture recognizers. I am convinced that simply setting the delaysContentTouches property to YES does not work.

This problem has totally busted some quite complex code that worked smoothly and beautifully in iOS 5 and 6; and, so far I have discovered no way to tell the UIScrollView to suppress events to its subviews until it determines whether or not it is being scrolled. The events go through, then a cancellation touch event is triggered later, after the scroll view determines it is scrolling. It looks like the underlying model has been redefined for the worse, or this is a bug. Any insights will be greatly appreciated.

chappjc
  • 30,359
  • 6
  • 75
  • 132
user2856648
  • 51
  • 3

2 Answers2

0

Are you sure it was working on iOS5/6? Based on my experience and posts like UIScrollview delaysContentTouches issue it doesn't work.

Maybe a sample code which shows it working on iOS5/6 but not on iOS7 will help to answer your question.

Community
  • 1
  • 1
Szabi Tolnai
  • 434
  • 5
  • 5
0

This works for me:

[scrollView setCanCancelContentTouches:YES];
[scrollView setDelaysContentTouches:YES];
Ilya
  • 66
  • 1
  • 4