jQuery, Touch, and Hammer
Recently, I found myself confronted with the task of programming a large touch screen and developing a program to display interactive images. The original concept was for the
system to display a number of images on a tabbed-page HTML layout. Each tab/page of images needed centered and allow a user to touch a thumbnail to bring up a larger rendering of that image. Then the system would allow the user to move the image around and re-size it using finger gestures. The next criteria was that the user could also slide the image off screen resulting in the tab/page of image thumbnails to be accessible again to allow further interaction with other images.
Does programming have a GPS?
I had done some mobile programming for smart phones, etc. and decided to follow the same programming model in this effort. I use an Agile approach to projects so I tackled some of the obvious CSS and JS routines I thought I would need. I had several parts of the the puzzle built before the touch equipment arrived. After receiving the actual equipment I was to program on I soon learned that programming for a small display device is a little different then a large screen one. Another lesson was that if the code depended on a mouse action it was not readily adaptable to finger gestures. Some of this had to do with OS, some with the browser, and some with the device itself.
The tap on a large screen device seemed to work OK except in the y=0 x=0 axis, without any code changes but the drag and re-size had some difficulty in translating over. The re-size/transform needed complete re-working and to do so required a major change to how I was handling events in my jQuery and JS. Thankfully, some folks had been down this road before and I was able to learn from them. I ended up turning most my of code over to jQuery events for touchscreen gestures. Note to self: event and original event are not the same.
This wasn't a canned solution. It required some coding of event handlers or some 'what to do if this event takes place'. In the case of both re-size/transform and drag it meant having to do some x and y coordinate calculations and a good amount of event determination as far as start and stop, how many fingers, and false starts. It wasn't long before I had to ask myself 'This has to have been done before?'.
Too much of a good thing
I ended up doing a detect on the dragged object distance from screen edge to add the action of reloading the tab/page when the container was dragged off the screen. Just hiding the container wouldn't work because the next thumbnail image tap popped up the enhanced image where the last one exited. Trying to re-position with CSS on the event caused the programming to lose track of the x and y coordinates so this was a clean option. When the container hit a screen edge, or slightly beyond, it triggered a page reload which blended well with the background coming back into focus with the thumbnails. I was going to tackle a fling action so the image would simulate being thrown off but I got mired in a time consuming loop and settled for just a slide off screen action.
One other note here on CSS. In some cases too much information is a bad thing. I was floating my thumbnail images in dynamically to form a row. When the images went to the next row on the screen they would left align. I needed them to center and I spent way too much time troubleshooting why they were not. Briefly, let me say that my issue turned out to be I was adding too much code in my CSS instead of letting the browser take a part in the show. The fix ended up being taken out code not putting more in- lesson learned- again, I'll forget this tidbit next month.
Thanks and Kudos to the group over at EightMedia for blazing a trail in muti-touch coding.
Bedankt en ga zo door grote werk!
by Jim Atkins 'thedosmann'