Fix UIScrollView to pass events UP the chain rather than DOWN

Question

UIView's that don't handle their events pass them up the chain. By default, this passes them to their parent View, and if not handled (ultimately) to their parent UIViewController.

UIScrollView breaks this (there's lots of questions on SO, variations on the theme of "why does my app stop working once I add a UIScrollView?)

UISV decides whether the event is for itself, and if not, it passes it DOWN (into its subviews); if they don't handle the event, UISV just throws it away. That's the bug.

In that case, it's supposed to throw them back up to its own parent view - and ultimately parent UIVC. AFAICT, this is why so many people get confused: it's not working as documented (NB: as views are documented; UISV simply is "undocumented" on this matter - it doesn't declare what it aims to do in this situation).

So ... is there an easy fix for this bug? Is there a category I could write that would fix UISV in general and avoid me having to create "fake" UIView subclasses who exist purely to capture events and hand them where they're supposed to go? (which makes for bug-prone code)

In particular, from Apple's docs:

If the time fires without a significant change in position, the scroll view sends tracking events to the touched subview of the content view. If the user then drags their finger far enough before the timer elapses, the scroll view cancels any tracking in the subview and performs the scrolling itself.

...if I could override that "if the timer fires" method, and implement it correctly, I believe I could fix all my UISV instances.

But: - would apple consider this "using a private API" (their description of "private" is nonsensical in normal programming terms, and I can't understand what they do and don't mean by it) - does anyone know what this method is, or a good way to go about finding it? (debugging the compiled ObjC classes to find the symbol names, perhaps?)

Answer 1

I've found a partial answer, that's correct, but not 100% useable :(.

iPhone OS 4.0 lets you remotely add listeners to a given view, via the UIGestureRecognizer class. That's great, and works neatly.

Only problem is ... it won't work on any 3.x iPhones and iPod Touches.

(but if you're targetting 4.0 and above, it's an easy way forwards)

EDIT:

On OS 3.x, I created a custom UIView subclass that has extra properties:

NSObject *objectToDelegateToOnTouch;
id touchSourceIdentifier;

Whenever a touch comes in, the view sends the touch message directly to the objectToDelegateToOnTouch, but with the extra parameter of the touchSourceIdentifier.

This way, whenever you get a touch, you know where it came from (you can use an object, or a string, or anything you want as the "identifier").