iDevelop : Building raps about quests on sand beaches

April 15th, 2010 Alex Moffat

Google automatic closed captioning is a great idea but still has a few problems.

Based on what it thought we were saying in our session proposal a better title than iDevelop : Building web apps for mobile devices is apparently iDevelop : Building raps about quests on sand beaches.

4-14-2010 11-31-42 PM

4-14-2010 11-34-11 PM

4-14-2010 11-34-59 PM

4-14-2010 11-36-24 PM

Posted in GWT, Web | No Comments »

Web 2.0 Expo New York 2010

April 14th, 2010 Alex Moffat

I know I said I’d quickly do a follow up post on my multi-touch work but I used up all my time working on a proposal for a presentation at Web 2.0 Expo in New York in October with Allison, who’s a user experience expert I work with. This year a video is required as part of your submission. I didn’t want to point to any of my Google I/O efforts and Allison didn’t have anything recent so we knocked up the following effort.

The submission guidelines said that the quality of the video wasn’t important and we sort of took them at their word.

The topic though, now that is interesting. Web apps on mobile devices are going to be important, for the same reasons they became important on desktops. The Apple App Store provides users with a way to find apps, and an easy way to install and get upgrades for apps. For developers it provides a distribution channel and, possibly more important, a way to get paid. If you have an existing product, or a product that’s going to have a web interface on the desktop then an App is less compelling in contrast to a web app on a mobile device. You’re already handling the finding and upgrading to support desktop browsers and you’re dealing with payments, if necessary, already. Unless there is some functionality you can’t deliver via the browser, which for the majority of Apps is pretty unlikely, a web app is a great choice. Especially when you consider it let’s you serve users with Android or Palm (as long as they are around) devices with no native code development work.

You can support multi-touch in Safari on iPhones, iPod touches and iPads and single touch on Android. You can remove the browser chrome. You can cache resources on the device. You can provide a custom image for the home screen on iDevices. Really, you can get very close to a native code experience, certainly close enough for a wide range of applications, and in lots of cases native code just isn’t needed.

Posted in Uncategorized | No Comments »

Multi-touch web apps on the iPad with GWT

April 4th, 2010 Alex Moffat

This post builds on my two previous ones about the right way to add support for a new browser to GWT and supporting multi-touch events with GWT on mobile Safari. I have created a very simple demonstration multi-touch app running on Google App Engine. It works on the iPod touch, iPhone and iPad, go to touchexample.appspot.com. You can also try it out using the iPhone/iPad simulator that comes with the iPhone SDK but simulating multi-touch is difficult on that device. When I said very simple I meant it, there are two squares you can drag around the screen at the same time. The video below, though poor, gives you an idea of the interaction involved.

As well as multi-touch this uses a canvas element to create the grid and some webkit CSS to fade it in and out as well as animate the final positioning of the dragged square when it is released.

I’ll explain in more detail how I converted the multi-touch events into drag actions tomorrow. For now I’ll just say that there was only one problem. Consider the following sequence of touches.

  • Finger one down
  • Finger one move
  • Finger two down
  • Finger two move
  • Finger two up
  • Finger one move
  • Finger one up

I expected to see the following sequence of touch events.

  • Touch start (Finger one)
  • Touch move (Finger one)
  • Touch start (Finger two)
  • Touch move (Finger two)
  • Touch end (Finger two)
  • Touch move (Finger one)
  • Touch end (Finger one)

However, when finger two was lifted touch end events were sent for finger two and finger one and then a touch start for finger one. The actual sequence of touch events was

  • Touch start (Finger one)
  • Touch move (Finger one)
  • Touch start (Finger two)
  • Touch move (Finger two)
  • Touch end (Finger two)
  • Touch end (Finger one)
  • Touch start (Finger one)
  • Touch move (Finger one)
  • Touch end (Finger one)

I resorted to a Timer with a 200ms delay so that in a multi-touch situation a touch end would only generate a drag end if it was not followed immediately by a touch start for the same element, and a touch start would not generate a drag start if it immediately followed a touch end for the same element.

Posted in GWT | 3 Comments »