Also, to get the full benefits of this you will want to test on a mobile device (that handles touch events and puts a delay on onClick).
On a desktop browser, you should notice no difference since onClick is fired immediately and there are no touch events. To really see the benefit, rapidly click the "fast" buttons (using fast-press) and then try the same with the "slow" buttons (using regular clickHandler) - Ashton On Sunday, December 16, 2012 5:36:17 PM UTC-5, Ashton Thomas wrote: > > I wanted to take a shot at this implementation using the previous answer > and Ed's comments: > > > http://stackoverflow.com/questions/9596807/converting-gwt-click-events-to-touch-events/13906134#13906134 > > Example with code: > http://gwt-fast-touch-press.appspot.com/ > > Not sure if I hit all the edge cases so if someone notices anything wrong, > please let me know > > > - Ashton > > > On Monday, November 5, 2012 2:18:11 PM UTC-5, emurmur wrote: >> >> Anyplace I wrote event.preventDefault I really >> meant event.stopPropagation. >> >> Ed >> >> On Monday, November 5, 2012 10:57:44 AM UTC-8, emurmur wrote: >>> >>> I took a quick look at the code you linked to in stackoverflow. I think >>> the code as written has a few problems. >>> >>> (NOTE: I'm looking at code I wrote using the Elemental library as >>> reference, so some of the calls might be different in the user library). >>> >>> a) The code is not filtering touches aimed at the button; it calls >>> TouchEvent.getTouches(). You want to call TouchEvent.getTargetTouches() on >>> touchstart and touchmove to get the the touches just for your button. You >>> want to call TouchEvent.getChangedTouches() on touchend to get the end >>> touch. >>> b) The code does not take into account multitouch. On touchstart, you >>> can check that a single touch is available and bail out if there is more >>> than one. Also, on touchstart, stash away the id of touch, then use this >>> in touchmove and touchend to find your touch id in the array that is >>> returned (in case the user has touched another finger later on). You can >>> also simplify and check for multiple touches on touchmove and touchend and >>> bail again there. >>> c) I believe you need to call stopPropagation on touchstart, since you >>> are handling the event. I don't see where they call event.preventDefault on >>> the touchstart event You can see that this happens in the click handlers, >>> but not the touchstart. >>> >>> There is also a simpler way. If you don't care about dragging starting >>> on a button, then you can simply call your click logic in the touchstart >>> event (and make sure you call event.preventDefault, >>> TouchEvent.getTargetTouches() and check for single touch) and ignore >>> touchmove and touchend. All the touchmove and touchend stuff is to handle >>> the case of allowing dragging to start on the button. >>> >>> Ed >>> >>> On Monday, November 5, 2012 5:29:53 AM UTC-8, markww wrote: >>>> >>>> Hi, >>>> >>>> I've got some buttons on a page which will primarily be used from >>>> mobile devices. The click handlers fire only after a 300ms delay >>>> (intentional on mobile devices as detailed here [ >>>> https://developers.google.com/mobile/articles/fast_buttons]). >>>> >>>> Looks like someone has tried to implement the above for GWT: >>>> >>>> http://stackoverflow.com/questions/9596807/converting-gwt-click-events-to-touch-events >>>> >>>> but I'm getting strange behavior from that FastButton implementation. >>>> Is there something baked into GWT 2.5 that does this for us? >>>> >>>> Thanks >>>> >>> -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/y2H4Yk7xV5MJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
