Reader Question: Do you have a PSD file?

I’d like to mock sites up for my clients to see potential implementations of JQT and was wondering if you had a psd file so we can easily show mocks without actually having to do any coding.

We don’t have any sort of jQTouch-based PSD file, but if you haven’t already checked it out, I highly recommend the one from Teehan+Lax.

"jQTouch helped me to pull together a fully-functional mobile web app in less than 3 days. People viewing the demo thought it was a native iPhone app!"

Andrew Hedges

Running jQTouch in PhoneGap

Jesse Macfadyen has discovered a way to improve the sluggish performance issue in jQTouch apps running in PhoneGap. For those who don’t know, PhoneGap is a great way to embed your web app into a native one and put it on the iTunes Store.

While organizing my laptop files on a flight this week, I stumbled across the original design for jQTouch’s site and thought I’d share. I love seeing how far it’s come in under a year.

While organizing my laptop files on a flight this week, I stumbled across the original design for jQTouch’s site and thought I’d share. I love seeing how far it’s come in under a year.

jQTouch Beta 2

The new beta of jQTouch is ready for download with a ton of enhancements and fixes. For those who don’t know, jQTouch is a jQuery plugin which helps create immersive experiences on the iPhone and iPod Touch. New in beta 2:

Check out the new preview on your iPhone and download a copy to play with today!

Mobile WebKit and jQTouch — Slides from 360iDev on Vimeo (via David Kaneda). Shows off some of the new features in beta 2, being released any moment now. Sorry, no audio for now.

Reader Question: Toolbars and Tabbars

Do you have any plan for adding Toolbar and Tabbar UI elements in near future?

I do not. This is a great question, as it’s one of the most requested features. The problem with toolbars and tabbars is that Mobile Safari doesn’t support position: fixed. Additionally, it also doesn’t fire an onscroll event continuously, like desktop Safari does. No, there’s only one way to hack fixed position items — taking over the touch events and simulating a user’s scroll or flick with CSS3 animations. The technique was pioneered by Cubiq and Doctyper. While I commend their efforts, the result doesn’t feel entirely native and requires a fair amount of code. So, for now, I’m avoiding the subject and instead focussing on cool effects and making jQTouch extensible. That in mind, I would welcome someone developing an extension for this sorta thing.

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.

A preview of the “Floaty” extension, added in revision 92. Disclaimer: I made this screencast on a plane last night, with a good deal of turbulence…

Hippo is a new jQTouch app by Johan Brook which lets users search IMDB. This looks incredibly feature-packed — an excellent implementation of jQTouch.