Question

I’m trying to override the default behavior in a UITableView (which is in fact a UIScrollView subclass). Basically, my table takes up a third of the screen, and I’d like to be able to drag items from the table to the rest of the screen — both by holding and then dragging, and also by dragging perpendicular to the table. I was able to implement the first technique with a bit of effort using the default UIScrollView touchesShouldBegin/touchesShouldCancel and touchesBegan/Moved/Ended-Cancelled, but the second technique is giving me some serious trouble.

My problem is this: I’d like to be able to detect a drag, but I also want to be able to scroll when not dragging. In order to do this, I have to perform my dragging detection up to and including the point when touchesShouldCancel is called. (This is because touchesShouldCancel is the branching point in which the UIScrollView decides whether to continue passing on touches to its subviews or to scroll.) Unfortunately, UIScrollView’s cancellation radius is pretty tiny, and if the user touches a cell and then moves their finger really quickly, only touchesBegan is called. (If the user moves slowly, we usually get a few touchesMoved before touchesShouldCancel is called.) As a result, I have no way of calculating the touch direction, since I only have the one point from touchesBegan.

If I could query a touch at any given instant rather than having to rely on the touch callbacks, I could fix this pretty easily, but as far as I know I can’t do that. The problem could also be fixed if I could make the scroll view cancel (and subsequently call touchesShouldCancel) at my discretion, or at least delay the call to touchesShouldCancel, but I can’t do that either.

Instead, I’ve been trying to capture a couple of touchesBegan/Moved calls (2 or 3 at most) in a separate overlay view over the UITableView and then forwarding my touches to the table. That way, my table is guaranteed to already know the dragging direction when touchesShouldCancel is called. You can read about variations on this method here:

• http://theexciter.com/articles/touches-and-uiscrollview-inside-a-uitableview.html
• http://forums.macrumors.com/showthread.php?t=640508

(Yes, they do things a bit differently, but I think the crux is forwarding touches to the UITableView after pre-processing is done.)

Unfortunately, this doesn’t seem to work. Calling my table view with touchesBegan/Moved/Ended-Cancelled doesn’t move the table, nor does forwarding them to the table’s hitTest view (which by my testing is either the table itself or a table cell). What’s more, I checked what the cells’ nextResponder is, and it turns out to be the table, so that wouldn’t work either. By my understanding, this is because UIScrollView, at some point in the near past, switched over to using gesture recognizers to perform its vital dragging/scrolling detection, and to my knowledge, you can’t forward touches as you would normally when gesture recognizers are involved.

Here’s another thing: even though gesture recognizers were officially released in 3.2, they’re still around in 3.1.3, though you can’t use the API. I think UIScrollView is already using them in 3.1.3.

Whew! So here are my questions:

1. The nextResponder method described in the two links above seems pretty recent. Am I doing something wrong, or has the implementation of UIScrollView really fundamentally changed since then?
2. Is there any way to forward touches to a class with UIGestureRecognizers, ensuring that the recognizers have a chance to handle the touches?
3. I can solve the problem by adding my own UIGestureRecognizer that detects the dragging angle to my table view, and then making sure that every gesture recognizer added before that in table.gestureRecognizers depends on mine finishing. (There are 3 default UIScrollView gesture recognizers, I think. A few are private API classes, but all are UIGestureRecognizer subclasses, obviously.) I’m not handling any of the private gesture recognizers by name, but I’m still manipulating them and also using my knowledge of UIScrollView’s internals, which aren’t documented by Apple. Could my app get rejected for this?
4. What do I do for 3.1.3? The UIScrollView is apparently already using gesture recognizers, but I can’t actually access them because the API is only available in 3.2.

Thank you!

Answer 1

Okay, I finally figured out an answer to my problem. Two answers, actually.

Convoluted solution: subclass UIWindow and override sendEvent to store the last touch’s location. (Overriding sendEvent is one of the examples given in the Event Handling Guide.) Then, the Scroll View can query the window for the last touch when touchesShouldCancel is called.

Easier solution: shortly after, I noticed that Facebook’s Three20 library was storing UITouches without retaining them. I always thought that you shouldn’t keep UITouch objects around beyond local scope, but Apple’s docs only explicitly prohibit retention. (“A UITouch object is persistent throughout a multi-touch sequence. You should never retain an UITouch object when handling an event. If you need to keep information about a touch from one phase to another, you should copy that information from the UITouch object.”) Therefore, it might be legal to simply store the initial UITouch in the table and query its new position when touchesShouldCancel is called.

Unfortunately, in the worst case scenario, both of these techniques only give me 2 sample points, which isn’t a very accurate measurement of direction. It would be much better if I could simply delay the table’s touch processing or call touchesShouldCancel manually, but as far as I can tell it’s either very hacky or outright impossible/illegal to do that.