Recommended way for one gesture to have priority over another about gestouch HOT 7 CLOSED

Please take a look on this issue thread #18 and try out that hotfix branch and confirm that it works as expected so I can finally merge it to master and release swc (kinda sorry for that it's not done yet).

Yes, canBePreventedByGesture and canPreventGesture should be fully functioning... why do you think they don't do anything?

from gestouch.

I was requireGestureToFail incorrectly. I expected to be able to say pan.requireGestureToFail(swipe) and instead needed to swap it, swipe.requireGestureToFail(pan). Grammatically, it's the reverse of what I'd expect, but I'll get used to it. ;)

I tried swipe.canBePreventedByGesture(pan), and it didn't seem to do anything. Same for the opposite pan.canBePreventGesture(swipe). But... when I dropped in your hotfix, it does seem to work as expected.

Thanks for the quick response. Seems like you can push that out to master at this point.

from gestouch.

Oh, one last thing. Is there a reason to use requireGestureToFail over canBePreventedByGesture?

from gestouch.

Looks like you haven't watched Apple's videos from WWDC conferences.
requireGestureToFail is totally their API, and it does exactly what it says. A.requireGestureToFail(B) means A should delay own recognition until B fails.

Regarding canBePreventedByGesture and canPreventGesture... Again, in those videos they explain this kind of relationship. These methods get called by the system once some gesture is recognized, so depending on their return values other gestures might be aborted (failed) once one is recognized. So you don't call these methods, but you override them in subclasses if you need to customize your gesture subclass on the class level (instead of using delegates).
To understand it better see the source code of TapGesture and check out how these methods are used in GesturesManager... and watch the videos.

from gestouch.

It's true, I have yet to watch the Apple videos. The suggested ones clock in at around 3 hours and it seemed like it might take a lot to hunt down the answers to my issues when I'm able to use the rest of the API pretty easily. But yes, I will watch them at some point.

Thanks for the explanation re: canBePreventedByGesture and canPreventGesture. The delegation pattern that is so prominent in iOS is still somewhat new to me, but I think I get the gist of what those function do. I would say perhaps, that from an AS3 perspective, that those functions aren't particularly intuitive. In other words, semantically, it seems like one should be able to say "I want gesture A to prevent gesture B", call that method, and be done. Because it is a public method, and comes up in autocomplete, it seemed like the logical road to go down, and hence how I ended up in this confused state... ;)

from gestouch.

Good point btw, thank you! I should consider putting it under gestouch_internal namespace...
But I don't really want to make developers override custom namespace methods (because so far all you need to override is public/protected ones)... So maybe

gestouch_internal function canPreventGesture(gesture:Gesture):Boolean
{
    return this.canPreventGesture(gesture);//protected
}

m?

from gestouch.

Yes, it would definitely help to distinguish between the internal functions and the "regular" public ones. I can tell you as an end-user for libraries such as Gestouch, I learn quite a bit about using it from the autocompletes in my IDE, and supplement with looking it up in the docs...

I actually don't know much about different namespaces, so can't comment there.

from gestouch.