Anders Tornblad, web developer

I'm all about the web

Label archive for touch

Finally got around to fixing Sparky

Back in 2010, the iPad was all the rage. The first really usable tablet device, sporting lightning-fast multitouch capabilities, that were even exposed as (then non-standard) HTML5 Web APIs for JavaScript developers to play with.

It wasn't always easy to keep up with the latest trends, and trying out multitouch experiments then required an iPad. So I wrote a touch event simulation tool, called addTouch. The principle was to use the mouse to add, manipulate and remove multiple touch points, dispatching touch events to the browser.

This made it possible to develop multitouch experiences and test them using an average desktop browser. I supported both Apple's touch events and the (now extinct) Mozilla touch events.

Sparky : just a demo app

Sparky in actionTo demonstrate what addTouch could do, I put together a simple demonstration app called Sparky. Its principle is very simple — put your fingers on the screen to create sparking lines that you can move around. This was in the really early days of HTML5 support, and I hadn't learned Canvas drawing yet, so my implementation uses a few <div> elements and some CSS transform magic.

This has worked fine for almost six years now. I just had to fix a small issue when Apple released the iPhone 4, which had a high-dpi ("Retina") display. There were a few versions of the iOS Safari browser that had bugs when it came to handling device pixels vs logical pixels. I had to do a lot of experimenting with this, and wrote a StackOverflow answer that is currently my third most up-voted one.

What started out as just a demo app for addTouch, now has a life of its own. After my latest complete blog remake, I have been keeping a close look at the IIS logs that I get from Azure. It turns out that Sparky still gets a few hundred visits per week from different incoming, which is nice, but it prompted me to do some much-needed spring cleaning.

Update

The code was actually not too shabby, but some of it was really outdated. It still supported the old Mozilla touch events, and it used screen coordinates instead of local coordinates, which made it look pretty horrible in a non-fullscreen view, especially on the Android Chrome browser. That needed to change.

It was written in a certain style, specifically catered to my own old JavaScript minifier which I no longer use. Also, it polluted the global window object, which I never do anymore, unless I'm writing public APIs. That needed to change, too.

Other than that, it was just the small issue of estimating screen DPI, where I had used hard-coded values directly adapted for various iOS devices. That needed to be replaced with some more general-purpose code, and after a little head-scratching, I just decided to go with the same hard-coded value for all devices. At least for now.

The result is now live and kicking on spark.attrakt.se, and the complete code is available in the lbrtw/sparky GitHub repository.

Next step

I will try to fix some of the issues with addTouch as well, but I'll save that exercise for later. It is not very useful anymore, because the major browsers and development environments have really good touch emulation built in.

Try it out: spark.attrakt.se

Using addTouch to emulate webkit touch events in desktop browser

Testing multitouch code on the iPhone is a bit tedious. I don’t have a Mac, so I don’t have access to the iPhone emulator. I do have a tiny web server installed on my development machine, so I mostly open the project on my iPhone over Wi-Fi using a local IP address. That way I can test my new features instantly, and verify that some bug has been fixed.

This has been enough for simple experiments, but when the code is to be used in a production environment, I really need the debugging capabilities of a modern desktop browser. Mobile Safari does have a developer mode, but that only catches JavaScript exceptions and presents them in a list. I need to be able to set breakpoints, and step through my code in a debugger. I need FireBug, or the Developer Tools of Google Chrome or Internet Explorer 9.

That is why I wrote addTouch. AddTouch started out as a Google Chrome Extension to simulate touch events using the mouse in any web page. Unfortunately, the security model of Google Chrome doesn’t allow me to take over the mouse input completely using an Extension, so instead it is now a JavaScript file to be included before all other JavaScript in the page. It also comes with a CSS stylesheet.

When you visit a touch-enabled web page that includes addTouch.js on an iOS device, nothing out of the ordinary happens. The web page simply works as intended. But when you visit the same web page using any modern desktop browser, adding ?_addTouch=webkit to the URL, all mouse-based interaction is hijacked and turned into touch events that the JavaScript in your web page can handle.

Simply add addTouch.js to your head element before any other javascript is included. Also add the addTouch.css stylesheet.

<html> <head> <script type="text/javascript" src="addTouch.js"></script> <!– Your other scripts here –> <link rel="stylesheet" type="text/css" href="addTouch.css"> </head> <body> <!– Your markup here –> </body> </html>

Here is a demo app:
Without addTouch – visit with iPhone or iPad
With addTouch – visit with any modern desktop browser

This version of addTouch only emulates the raw touchstart, touchmove and touchend events. You will not get any gesture* events. I will probably add gesture emulation in later versions. Also on the “to do” list is support for Mozilla-style touch events like MozTouchDown.

The addTouch project is available on github: /lbrtw/addTouch

Let me know what you think, and if this helps you. NB: addTouch supports pretty much any version of Chrome and Safari. I have only tested it in Firefox 4, but I would be surprised if it didn’t work in Firefox 3.6. For Internet Explorer, you’ll need a recent Platform Preview of IE9.