TapGesture not always recognized

[tobiasnowen]

I'm currently developing a mobile app using FlashDevelop (project type is "AIR Mobile AS3 App"). The problem I'm having is that TapGestures (and others) are not always recognized across compilations. Sometimes it's almost impossible to have taps recognized, but with next compilation everything may work fine. My guess is some kind of race condition that occurs with the specific project type.

I'm not sure if this problem is related to Gestouch or the environment.

[fljot]

I can't imagine how/why it could be inconsistent between compilations... But let's try to narrow it down. Step1. When it's not recognized - does it actually fail? (Add state change handler and analyze whether it fails). It fails? Debug why (debugger + sources, not swc). It doesn't fail? Means it doesn't receive touch at all.

[tobiasnowen]

I might be totally wrong about the difference between different compilations, but at the symptom level there seems to be some difference.

I've narrowed the issue down by listening to state changes: when the tap fails it transitions through "POSSIBLE", "FAILED", "IDLE". If it succeeds the transition is "POSSIBLE", "RECOGNIZED", "IDLE".

In NativeInputAdapter::touchEndHandler there's a check of the native TouchEvent property "isTouchPointCanceled", which, if true, results in the tap failing.

Now that certainly does seem correct, but I've also registered a native TouchEvent.TOUCH_TAP handler, and that handler fires regardless if the TapGesture state fails or is recognized.

Bottom line is that the TapGesture fails frequently, and sometimes all the time. Since NativeInputAdapter internally listens to native TouchEvent.TOUCH_TAP events too, there must be a difference in the way the "isTouchPointCanceled" is utilized natively compared to Gestouch?

I use the source included in the zip.

[fljot]

Good, so investigate why it fails exactly (using debugger or just by getting new error stack trace in FAILED handler).

[tobiasnowen]

Ok, I've realized that this isn't really an issue.

In NativeInputAdapter::touchEndHandler there's a check whether the TouchEvent::isTouchPointCanceled is true or false. If it's true, then onTouchCancel is called on the _touchesManager instance. So that's why the TapGesture fails; isTouchPointCanceled reports true.

Even though the isTouchPointCanceled is true, the native TouchEvent.TOUCH_TAP listener still runs, making it a reliable way to handle taps.

To have the same reliability with the TapGesture, you would have to listen to the GestureEvent.GESTURE_POSSIBLE event. I guess that's ok, perhaps a little unintuitive though.

[fljot]

Looks like it's a runtime bug as it seems there's no reason for touch point to be cancelled. And I wouldn't talk about any "reliability" in this case =) Don't forget to submit bug to Adobe even though they don't really care much.

So Gestouch works correct given this system input.

[tobiasnowen]

I agree.