There has been one jQTouch feature which I have spent far more time working on than any other. It’s not a cool new 3d animation, it’s not detecting a swipe event, and it has nothing to do with Ajax. It’s the ability to remove a roughly 300ms onClick delay when tapping a link. Currently, in revision 100, this feature comes stock, though user’s can disable it with useFastTouch: false in their initialization options. Background The problem lies with a default gesture built into Mobile Safari: The “double tap”. By default, a double tap tells the browser to zoom in on an element. In jQTouch, we explicitly set the viewport not to scale, so double tapping doesn’t have any effect — it does, however, still mean that when a user taps quickly, Safari will wait a few hundred ms to see if they tap again. There is currently no way to stop the propagation after a user does a “Quick Finger Up,” as shown in the documentation diagram above. I occasionally get messages on Twitter, like this one from Mel Gray: Developing with jqTouch kinda sucks :-\  Its nice getting a theme out of the box, but its kind of slow… Now, I work on jQTouch just about everyday. In regard to Javascript, I can promise you: It is not slow. The people making these comments (sorry to single you out, Mel!) may not fully understand why they feel the app is slow, but I know: The click delay. 300ms may not be a lot when clicking a link on a website, but when you’re trying to emulate native apps, it can mean the world. The Technical There is only one way around this delay, which is to fire our event (whether it’s custom or just a “click”) in the touchend event. Matteo Spinelli has done a great job of explaining this solution. Obviously, though, not all touchends are meant to be clicks or taps, so we first have to do a little check to make sure the user isn’t scrolling or anything. Once we know the user is trying to click, we fire away. But here’s the rub: We’ve just added our event to touchend, we haven’t disabled the delayed click that fires. Essentially, this means we’re firing two clicks: One immediate and one after the delay. But, you say, “Is there no way to prevent the delayed click from firing?” There is. It is to call preventDefault() on either the touchstart or touchmove event. Doing so, however, removes the native ability to scroll when starting on one of these elements. Imagine being in an app like Mail, and not being able to scroll on the edge to edge list of messages. Not a pretty picture. Ideally, we could call preventDefault() on the touchend event. Unfortunately, according to Apple’s documentation (and my millions of tests), this has no effect. The Current Solution The current solution in jQTouch, which is enabled with useFastTouch: true, uses a two pronged approach. First, I switch all of my related callback functions to use a custom event, “tap,” instead of the traditional “click.” Next, I proceed to take over and nullify all click events. While this works well in preventing links from being clicked and such, it has a variety of unwanted side effects — of which, I probably only know the half. All of this being said, I’m still not convinced there isn’t a better way. If you have any ideas or experience with this subject, please, please let me know on Twitter and let’s discuss. As I mentioned at the start of this post: This is, and has been, the most important feature to me.

There has been one jQTouch feature which I have spent far more time working on than any other. It’s not a cool new 3d animation, it’s not detecting a swipe event, and it has nothing to do with Ajax. It’s the ability to remove a roughly 300ms onClick delay when tapping a link. Currently, in revision 100, this feature comes stock, though user’s can disable it with useFastTouch: false in their initialization options.

Background

The problem lies with a default gesture built into Mobile Safari: The “double tap”. By default, a double tap tells the browser to zoom in on an element. In jQTouch, we explicitly set the viewport not to scale, so double tapping doesn’t have any effect — it does, however, still mean that when a user taps quickly, Safari will wait a few hundred ms to see if they tap again. There is currently no way to stop the propagation after a user does a “Quick Finger Up,” as shown in the documentation diagram above.

I occasionally get messages on Twitter, like this one from Mel Gray:

Developing with jqTouch kinda sucks :-\  Its nice getting a theme out of the box, but its kind of slow…

Now, I work on jQTouch just about everyday. In regard to Javascript, I can promise you: It is not slow. The people making these comments (sorry to single you out, Mel!) may not fully understand why they feel the app is slow, but I know: The click delay. 300ms may not be a lot when clicking a link on a website, but when you’re trying to emulate native apps, it can mean the world.

The Technical

There is only one way around this delay, which is to fire our event (whether it’s custom or just a “click”) in the touchend event. Matteo Spinelli has done a great job of explaining this solution. Obviously, though, not all touchends are meant to be clicks or taps, so we first have to do a little check to make sure the user isn’t scrolling or anything. Once we know the user is trying to click, we fire away. But here’s the rub: We’ve just added our event to touchend, we haven’t disabled the delayed click that fires. Essentially, this means we’re firing two clicks: One immediate and one after the delay.

But, you say, “Is there no way to prevent the delayed click from firing?” There is. It is to call preventDefault() on either the touchstart or touchmove event. Doing so, however, removes the native ability to scroll when starting on one of these elements. Imagine being in an app like Mail, and not being able to scroll on the edge to edge list of messages. Not a pretty picture.

Ideally, we could call preventDefault() on the touchend event. Unfortunately, according to Apple’s documentation (and my millions of tests), this has no effect.

The Current Solution

The current solution in jQTouch, which is enabled with useFastTouch: true, uses a two pronged approach. First, I switch all of my related callback functions to use a custom event, “tap,” instead of the traditional “click.” Next, I proceed to take over and nullify all click events. While this works well in preventing links from being clicked and such, it has a variety of unwanted side effects — of which, I probably only know the half.

All of this being said, I’m still not convinced there isn’t a better way. If you have any ideas or experience with this subject, please, please let me know on Twitter and let’s discuss. As I mentioned at the start of this post: This is, and has been, the most important feature to me.