Top Flash Misperceptions : Flash cannot run on touch devices
Today I wanted to look at a more recent misperception around Flash. That is the idea that Flash cannot work on devices with touch screens. If you know your Flash history then you will probably find this a bit ironic, considering that Flash was originally created specifically for tablets with touch inputs. Regardless, lets take a closer look at this myth.
The myth began with the publishing of this article. I have already covered this topic in another post, but I wanted to address it again as it seems to have spread lately.
Basically, the myth is that because the concept of hover events can be different on a touch device (compared to a device with mouse input), Flash content cannot work well on touch devices. From the original article:
Current Flash sites could never be made work well on any touchscreen device, and this cannot be solved by Apple, Adobe, or magical new hardware.
That’s not because of slow mobile performance, battery drain or crashes. It’s because of the hover or mouseover problem.
The assumptions that the myth is based on are incorrect, and therefore its conclusions are also wrong. The vast majority of Flash content works fine on devices with touch screens. For any content that does not work well due to changes in the input interactions, the content can be easily updated to work.
There are two types of Flash content we need to look at in order to see whether Flash content can work well on touch devices. The first is Flash content created and / or updated specifically with mobile and touch devices in mind. The second is existing Flash content created for desktop computers with mouse inputs.
Flash content created or updated with mobile and touch devices in mind works fine. Single touch events can be captured within Flash content on a touch device as MouseEvents (as if the finger was a cursor). In addition, Flash Player 10.1 Adobe AIR 2.0 for mobile also includes a complete set of APIs specifically for working with multi-touch input and gestures. Here is a listing of some of the new touch specific APIs in Flash Player 10.1 Adobe AIR 2.0 for mobile:
- flash.events.GestureEvent
- flash.events.GesturePhase
- flash.events.MultitouchInputMode
- flash.events.PressAndTapGestureEvent
- flash.events.TouchEvent
- flash.events.TransformGestureEvent
- flash.ui.Multitouch
The Flash player can support as many touch points as the underlying operating system supports.
There is already hundreds of Flash based content online created for touch devices in the form of content created for the iPhone with Flash CS5, as well as an increasing number of Flash based content that runs on touch devices (via Flash Player and Adobe AIR). You can view videos (nearly 50) of Flash content created for touch devices on the following pages:
- Flash to AIR for Android in 10 minutes!
- Google Reinforces Commitment to Adobe and Flash
- Flash is Not Designed for Touch
It is pretty clear that there is no problem with creating new Flash content designed to work on touch devices.
Next, we need to look at existing Flash content created for the desktop in order to see if it can work on devices with touch input. Again, the assertion is that “Current Flash sites could never be made work well on any touchscreen device”. Lets get the absolutes (“never” and “any”) out of the way first.
Lets look at some examples. Ryan Stewart has a posted a video showing existing Flash content running in the browser on a Google Nexus One, and Lee Brimelow has posted a video showing existing content running on a touch based tablet. As you can see from the videos, the Flash content works just fine even though it was created with mouse input in mind.
The myth specifically mentions hover events as the reason that Flash content will not be able to work on touch devices. However, as shown in this video, hover events (MouseEvent.MOUSE_OVER and MouseEvent.MOUSE_OUT) are broadcast in Flash content on touch devices. This is discussed in more detail on my original blog post on this topic. Lee’s video also shows a number of sites with Flash content that rely on hover events (all of which work fine).
It is possible for a developer to write code that creates mouse based interactions that would not work well (or at all on a touch device). For example:
- MouseEvent.MOUSE_OVER then MouseEvent.CLICK without a MouseEvent.MOUSE_UP being broadcast first
- MouseEvent.MOUSE_OVER without first receiving a MouseEvent.CLICK event
However, these interactions are the exception, rather than the rule.
This is not suggesting that all Flash content created for the desktop will work great on mobile devices. Just as with HTML content, some content will need to be updated due to differences in performance, memory and UI Interactions. However, as discussed above, there is no fundamental issue that prevents Flash content (new or existing) from running well on touch based devices.
Resources:
- Flash Player content, Mouse Events, and Touch input
- Scrolling HTML with Flash Content on Touch Devices
- Flash Works On Touch-Based Devices (Video)
- Google Reinforces Commitment to Adobe and Flash
- Flash to AIR for Android in 10 minutes!
- Flash is Not Designed for Touch
- Examples of Flash Content Running on Android
- Flash Player Mouse Events on Touch Screen Devices
- Introduction to Multitouch in Flash Player 10.1. (Video)
- TETRIS, TOUCH API AND ANDROID
- Video of Flash multi-touch on Windows and Mac
- Simple Flash Player 10.1 Multitouch example
- The History of Flash
Please keep comments constructive and on topic. Off topic comments may be moderated / deleted.
I wholeheartedly agree. I was thinking exactly this when I read Steve’s post originally. There are 2 things that came to mind after reading his article. Either he doesn’t really know much about Flash and has barely done any research on it before making such statements (unlikely) or he’s trying to smear Flash and convince others who are unlikely to do the actual research about his statements and take them at face value (more probable). In any case I’m glad you mention this. Thanks!
liquidplastik
12 May 10 at 11:12 am
There should probably be a link to Lee’s video, for many seeing is believing.
http://theflashblog.com/?p=2027
leef
12 May 10 at 11:18 am
@liquidplastik
He’s smearing Flash, and inventing psuedo technical reasons for not supporting Flash. He has to slander Flash in ways that seem legitimate in order to influence publishers, and even other device manufacturers, to back away from Flash. It’s an old & devious trick that can fly in tech industry because there are so many variables, and most people (journalists, users, judges) are not informed enough to know any better.
leef
12 May 10 at 11:21 am
re: liquidplastik
He has to slander Flash in ways that sound legitimate to the uninformed listener, in order to influence publishers (NYTimes, CBS, etc), and even device manufacturers, to back away from using Flash. It’s an old & devious trick.
leef
12 May 10 at 11:23 am
Maybe I’m wrong but is the whole touch api only available since 10.1? And therefor our dear friend Steve made his misperception (he could make a remark about the a future release though)
Martijn van Beek
12 May 10 at 11:35 am
@Martijn van Beek
Touch and Gesture specific APIs were added in 10.1 (some of which are listed above).
However, prior to 10.1, single touch events were treated as mouse events in the Player.
mike chambers
mesh@adobe.com
mikechambers
12 May 10 at 11:44 am
Considering he made his remarks AFTER the announcement of 10.1 and the touch API, I would say his remarks are completely unjustified. Sure lots of the sites with Flash at the moment don’t utilize the touch API, but the same goes for regular HTML sites. They don’t make use of multi-touch or gestures either, yet. It just seems silly to me.
liquidplastik
12 May 10 at 12:31 pm
[...] See the article here: Top Flash Misperceptions : Flash cannot run on touch devices at … [...]
Top Flash Misperceptions : Flash cannot run on touch devices at … | Flash Designers
12 May 10 at 1:15 pm
Non-Flash sites can fail on touch devices if they rely on JavaScript rollovers for navigation. This is not a limitation of the browser, but of how the site was coded.
Apple keeping Flash off the iPhone because of poorly coded Flash apps is as ridiculous as taking Safari off the iPhone due to poorly coded JavaScript.
Dave C
12 May 10 at 1:49 pm
Flash is about multiplatform, BUT, their is a new , and in my perception really different platform out on the market. The tablet pcs. They work with a finger/gestures/no keyboard, no cursor, so you MUST know the platform you build your flash app for, before implementing your application.
I think the guy is right that most if not ALL of the flashes are made with keyboards and mouse in mind, and guess what. This causes an unpleasant experience for touch users when they want to interact with flashes which are made little pointery devices, keyboard input and no gestures. And guess what, apple don’t want their user to have an unpleasant experience.
Okay, now your point, okay it CAN be done, since 10.1, and thats already way too late. Thats the point apple said in their note, if we extend the api with new features, we have to wait for thirdparty API to adopt them, and three years is a loooooong time to wait.
I do see its possible in flash to write great iphone apps, and i was hopefull for the FlashCS5 solution, cause then you know which hardware your talking too, but sadly it will not be adopted by apple. I agree at a certain level with Steve Jobs, but one thing bothers me the most: The dutch TV channels will not be creating apps for phones anymore because it costs too much. Sure, creating an app for iphone AND android is double the cost. Its not easy to port one app to the other platform. This is where flash could be really convenient. Write once, run android and flash. But, this is also where the pain comes in, google and iphone create a great platform with great apis, but we just have to program against flash and its api. Thats not using the bleeding edge latest hardware. And from experience, it takes apple a while to adapt their api.
Multiplatform is in my opinion a crime with the totally different platforms these days. And the User Experience will suffer when running embedded flash meant for Keyboard and Mouse.The FlashCS5 package solution looked great, but sadly too late. Don’t quit making these great tools adobe, I love flash, i make a living coding in flash, but love flash the most for what is was made for, make drawing on the computer easier than drawing on paper” http://bit.ly/5cNzfP.
—————–
Mike Chambers :
—-
I think the guy is right that most if not ALL of the flashes are made with keyboards and mouse in mind, and guess what. This causes an unpleasant experience for touch users when they want to interact with flashes which are made little pointery devices, keyboard input and no gestures.
—-
Did you even read the post and watch the videos? Or did you just not understand it?
mike chambers
Patrick de Klein
12 May 10 at 1:52 pm
Hi Mike,
Great article! I am glad you and Lee are pounding this smears and baseless attacks on the Flash Platform.
I have been testing my projects (past and current) with 10.1 RC4 and may I say, it is bad ass!? Performance is absolutely amazing. I will be getting either a touch enabled tablet or Android smartphone soon to test and start developing for these new formats.
I just wish the advances made in 10.1 weren’t over shadowed by Apple’s protectionist anthem. Thank you and keep up the good work!
Jerome
12 May 10 at 2:33 pm
Wow Patrick… you really managed to do a phenomenal job of illustrating how uninformed readers just can’t quite comprehend that Steve Jobs is wrong. Trying to debate this with people that don’t take the time to actually do the research (in this case all it would take is for you to carefully read the original post) before making statements is really an act of futility.
Rob McKeown
12 May 10 at 2:39 pm
Hi Mike,
Sure I read it, and saw the movies, the flashes showed worked great.
But take Flex. The flex GUI, like for example the datepicker is not designed for touch. The datepicker from flex is ideal for use with a mouse, but too small for touch. Picking dates with the iphone(read touch) datepicker is not only easy, but also fun.
The flex interface widgets were not designed with touch or gestures in mind, and although will work on android it will degrade User Experience, and this will be frustrating for users which are used to gesture like interactions. And frustrated with a device is not what any mobile phone developer wants.
Patrick de Klein
12 May 10 at 2:46 pm
@patrick
–
But take Flex. The flex GUI, like for example the datepicker is not designed for touch.
–
From my article:
–
This is not suggesting that all Flash content created for the desktop will work great on mobile devices. Just as with HTML content, some content will need to be updated due to differences in performance, memory and UI Interactions. However, as discussed above, there is no fundamental issue that prevents Flash content (new or existing) from running well on touch based devices.
–
mike chambers
mesh@adobe.com
mikechambers
12 May 10 at 2:51 pm
@Patrick – your example of a Flex date picker not working well on a phone because it’s too small has nothing to do with managing touch input… it also wouldn’t work well on a normal non-touch phone running Flash… its due to the reduced screen size. Different issue all together.
Adam
12 May 10 at 5:27 pm
@Patrick: probably you don’t know it, but Flex has a great feature called “skinning”. A datepicker can be easily skinned to make i work great with mobile devices. You could even build up two different skins (one for larger devices and one for smaller ones) without even touching the application (i.e.: an external skin).
marco
marco
12 May 10 at 11:43 pm
@Adam, @marco, You are both right!
I just wanted to state that the pitfall with this article is that it is also proving to developers you can still do “write for mouse, run on phone”.
Patrick de Klein
13 May 10 at 2:14 am
Outstanding post, and you’ve got my agreement. One point that Jobs made in his open letter, which you refute well, is his idea that “since people have to rewrite their content anyway, do it in HTML5″. The assumption that every developer on the web is about to undertake a ground-up rewrite of their Flash web apps just to solve some mouseover interaction issues is just rediculous.
I.e. go tell the guys at Picnik to rewrite their whole app (pixelbender code and all) in HTML5. Seriously!
Tad
13 May 10 at 7:19 am
Isn’t the lack of hover/mouseover support a problem with touchscreen devices, not Flash? Last I checked, the a:hover pseudo-class doesn’t work on mobile Safari.
bhad
13 May 10 at 7:34 am
I do see its possible in flash to write great iphone apps, and i was hopefull for the FlashCS5 solution, cause then you know which hardware your talking too, but sadly it will not be adopted by apple. I agree at a certain level with Steve Jobs, but one thing bothers me the most: The dutch TV channels will not be creating apps for phones anymore because it costs too much. Sure, creating an app for iphone AND android is double the cost. Its not easy to port one app to the other platform. This is where flash could be really convenient. Write once, run android and flash. But, this is also where the pain comes in, google and iphone create a great platform with great apis, but we just have to program against flash and its api. Thats not using the bleeding edge latest hardware. And from experience, it takes apple a while to adapt their api.
+1
Bin
13 May 10 at 8:27 am
Great rebuttal, Adobe. This argument has already gone too far. As a full time Flash Developer (who had great instructors that once worked for Adobe) I was biased from the start. An Apple smear campaign forced me to rethink my options for a mobile platform. Going with Google. I love how you have begun to work with Chrome and make plug-ins a thing of the past (at least to the average user). Please continue to work with the mobile version of Chrome to enhance Flash support.
Please keep up the good work and you will continue to win over everyone else at the Mobile party and leave Apple standing alone in a corner somewhere.
Do I get a free upgrade to CS5 for the support? ;-)
jmd1513
13 May 10 at 2:13 pm
I have a good selection of oil paints and brushes – they’re great when I want to paint a portrait; but I get into a real mess when I try do some quick sketches.
My skills aren’t at fault, neither are the materials – it’s just that they don’t work well out of context – oils give me the ability to blend and layer colour and texture – but for a quick sketch I really ought to be working with water colours.
Same with Flash and touch vs a mouse – the mouse allows me to give a lot of feedback to the end user – touch gives them a great interactive interface.
I agree with you – it’s not the application or the technology that’s at fault here – it’s the developers who are causing the problems.
graeme
14 May 10 at 2:05 am
I just can’t believe people are spewing this ‘argument’ all over the interwebs. I mean, there are HTML/JS based sites that also rely on roll-over/roll-out events, but that doesn’t make HTML/JS touchscreen-unfriendly. That’s yet another example of blaming the technology for the faults of a developer using that technology, just like with FUD around battery drain, inaccessibility, bad performance etc.
Further, there is a *brilliant* workaround on Nokia N900′s MicroB browser which allows you to actually get a mouse cursor and drag it around the screen (to throw a mouse-down/mouse-up, tho, you need to use the keyboard in that mode) for those sites that are really dependent on roll-over/roll-out, and it works flawlessly for both, Flash and HTML/JS content.
This, IMHO, should be implemented on all touch-screen devices, or even implemented on a platform level, as there are still cases where a mouse cursor is irreplaceable.
Sx
18 May 10 at 2:11 am
Here is some flash based project http://www.flaemo.com/test (Keep in mind it’s Flash 9). Whole idea was to run it under Nokia N900 mobile touch device Flash 9 capable.
Here is prove of concept http://www.flaemo.com/gestures/ that using only 3 listeners you can achieve TouchEvent, DoubleTap, TapAndHold, HoldAndRollOver, HoldAndRollOut and many others gestures you can only invent.
Because as3 is flexible enough language to do so.
devu
1 Aug 10 at 4:38 am