View Single Post
Old 02-22-2010, 07:54 PM   #22
nikkie
Guru
nikkie is slicker than a case of WD-40nikkie is slicker than a case of WD-40nikkie is slicker than a case of WD-40nikkie is slicker than a case of WD-40nikkie is slicker than a case of WD-40nikkie is slicker than a case of WD-40nikkie is slicker than a case of WD-40nikkie is slicker than a case of WD-40nikkie is slicker than a case of WD-40nikkie is slicker than a case of WD-40nikkie is slicker than a case of WD-40
 
nikkie's Avatar
 
Posts: 614
Karma: 73700
Join Date: Oct 2009
Location: WA, USA
Device: Android, Kindle Paperwhite, lots of ancient readers
Quote:
Originally Posted by Jim Lester View Post
The original article was missing some details. Hover states (more correctly mouse over and mouse out events) are fully supported by flash even on touch devices. For more details set this blog post by Mike Chambers (with demonstration of Flash app on the iPhone)

The difference is in the interaction model of mouse vs. touch requires you to be careful in the design (am I really going to get a mouse over before I get a mouse down, maybe not), so yes it is quite possible to make a flash based app that won't work well on a touch device.

BTW this isn't a strictly flash based issue as there are any number of websites (eBay for instance - hover on the categories menu) that use Javascript to handle hover states on menus. It takes careful coding and consideration (regardless of platform and programming language) to handle the differences in touch vs mouse control.
This is interesting, but I feel like he missed a fundamental point. From the article:
Quote:
Basically, hover events do work in Flash content on touch screen devices. The main difference is that on a touch device, you will get also get a MouseEvent.MOUSE_DOWN event prior to the MouseEvent.MOUSE_OVER event, where as on a desktop machine, you MAY only get the MouseEvent.MOUSE_OVER event.
The problem with this statement is that in the browser, your mousedown event is only used for two things:
  • Clicking
  • Dragging

If you wanted to use the Mouse_over event, it would imply that a user would want to do something other than those two things. In Safari on the iPhone, if you attempt to move your finger (to get another mouseover) after you already have the mouse_down, you are, by default, invoking the "drag" gesture. It would not be currently possible to get a mouseover without a implying a mouse_down (which means drag) without breaking the ability change what portion of the screen you are looking at. So, while he is quite correct that you *can* get the mouseover event, you can't use it without breaking the browser.

Now you absolutely could use it in a separate application that was guaranteed to fit within the screen size (e.g., not require dragging), or that mapped drag to a different control.

Mike Chambers is quite right when he says that this issue isn't unique to flash. You definitely find this same thing in plain html. But I think he again misses the point on this issue. Most uses of the mouseover feature in plain html are not required for the functionality of the site. In Flash, they often are. One of the main reasons flash is used is that it makes it easy to do timeline-based animations. When timeline-based animations use mouse *position changes* and not the mouse *state changes* as an input, as they often do, this *will* be broken.

So no, you wouldn't be able to play Bloons as is, even if the iPad did support flash. It would require some modification to its input methods. As it is, it would fire the missile when you touched the screen.
nikkie is offline   Reply With Quote