There has been a lot of buzz in the mobile space lately, and I suspect there will be even more around Windows Phone 7 at next week’s Microsoft Mix conference. One thing I wanted to clarify as it may have been lost in some of the other news is that Adobe and Microsoft are working together to bring Flash Player 10.1 to Internet Explorer Mobile on Windows Phone 7 Series.

I dont have an eta or other specifics right now, but it is something that both Adobe and Microsoft are working closely together on.

So, the Interwebs is all a buzz again around the latest article that “proves” that Flash will not be useful on mobile devices (much less the iPad). From the 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.

Basically, the writer is arguing that because some Flash content uses Mouse over / hover events (MouseEvent.MOUSE_OVER), and because there is no such event as a hover on a touch devices, then apparently, most Flash content just flat out wont work on touch devices.

I wanted to make a quick post that corrects some of the false assumptions and conclusions presented in the article, which include:

1. Hover events do not work in Flash content on devices with touch screens. That is false, they do work.
2. Any issue with hover or any other mouse events on a touch screen device, are specific to Flash. They are not. They affect HTML and any other web content as much as Flash.
3. Most Flash content relies on hover events. Wrong. I dont have a scientific breakdown on how much Flash content RELIES on hover events, but at least in my experience with the Nexus one, almost all content I have come across has worked well with touch screen input, including those that use hover events.

First, lets look at all of the Mouse events that Flash developers normally have access to.

• MouseEvent.CLICK
• MouseEvent.DOUBLE_CLICK
• MouseEvent.MIDDLE_CLICK
• MouseEvent.MIDDLE_MOUSE_DOWN
• MouseEvent.MIDDLE_MOUSE_UP
• MouseEvent.MOUSE_DOWN
• MouseEvent.MOUSE_MOVE
• MouseEvent.MOUSE_OUT
• MouseEvent.MOUSE_OVER
• MouseEvent.MOUSE_UP
• MouseEvent.MOUSE_WHEEL
• MouseEvent.RIGHT_CLICK
• MouseEvent.RIGHT_CLICK_DOWN
• MouseEvent.RIGHT_MOUSE_UP
• MouseEvent.ROLL_OUT
• MouseEvent.ROLL_OVER

Now, lets look at a list of events that will not work on a device whose primary input is a touch screen:

• MouseEvent.MIDDLE_CLICK
• MouseEvent.MIDDLE_MOUSE_DOWN
• MouseEvent.MIDDLE_MOUSE_UP
• MouseEvent.MOUSE_WHEEL
• MouseEvent.RIGHT_CLICK
• MouseEvent.RIGHT_CLICK_DOWN
• MouseEvent.RIGHT_MOUSE_UP

As you can see that list doesn’t include the MOUSE_OVER and ROLL_OVER events. It only includes middle and right mouse button events, as well as mouse wheel events, which in general, are used as a secondary means of user input / interaction.

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.

I put together a very simple Flash example for the iphone, that shows all of the MouseEvents being generated. You can view the video here:

View Video on YouTube

Here is a list of the events which were generated in the video:

• doubleClick
• mouseUp
• mouseDown
• click
• mouseUp
• mouseOver
• rollOver
• mouseDown
• rollOut
• mouseOver
• rollOver
• rollOut
• mouseOut
• click
• mouseUp
• mouseOver
• rollOver

So, to summarize:

1. Hover events do work in Flash content on touch devices.
2. Any issues with mouse input on a touch device are not specific to Flash, but affect all content, including HTML based content.
3. If your content RELIES on MIDDLE, RIGHT and / or SCROLL_WHEEL mouse events, then you will need to update your content IF you want users on touch devices to be able to use it. This applies just as much to HTML content as it does to Flash content.

Now, this doesn’t mean that all Flash content designed and developed for mouse input on a desktop computer will run well on a mobile device with touch input. Indeed, some content will not run well due to differences in input (such as keyboard input), user interface, or performance. However, again, those are all issues that affect HTML content as much as they affect Flash content.

Again, any potential input issues apply as much to HTML as they do to Flash, and as browsing the web on the iPhone has demonstrated, these have not been a major barrier to consuming content on a touch device.

As a content creator, you should focus on creating content that provides a good user experience across all platforms that you are targeting. However, even though most Flash content on the web today is not designed with mobile viewing and touch input in mind, my experience has been that existing content works surprisingly well when viewed on a mobile device with touch input.

Here are some links to videos of existing Flash content running on mobile devices. A lot of this content is content never designed to be run on a device with touch input.

• Demos of Flash Player 10.1 on various mobile devices (iPhone, Palm Pre, Nexus One, Droid, and more…)
• Flash Player content on Nexus One
• Unofficial Nexus One Flash Demos

Please keep comments constructive and on topic. Off topic comments will be moderated.

The news from Adobe MAX 2009 that probably generated the most buzz and discussion online was the announcement that Flash CS5 will have support for outputting applications for the iPhone. While I am really excited about the news, and the work we are doing around the iPhone, I am here to tell you that you should not care about it.

Let me repeat that:

You should NOT care about using Flash to build applications for the iPhone.

Hear me out on this. One of the major advantages of using Flash has always been that you can create your content, and then be confident that it will run consistently across different platforms and browsers. However, in the past, if you wanted to deploy to mobile platforms or devices, you would have to target a different player (most likely based on Flash Lite), which lagged behind the capabilities of the desktop player. However, the fragmentation between desktop and mobile players is about to change.

I think the biggest news out of Max last week was not the Flash applications for iPhone announcements, but rather the unveiling of Flash Player 10.1. Not only will Flash Player 10.1 run across desktop operating systems and browsers, but it will also be available on the newest generation of smart phones. This includes Palm Pre, as well as Android and RIM based devices. Furthermore, the iPhone work, as well as Adobe AIR 2.0 are both also based on Flash Player 10.1.

Thus, not only will you be able to create content and target multiple browsers and operating systems, but you will also be able to target mobile devices, as well as desktops.

Now, it is important to remember that devices, such as the Palm Pre and iPhone have significantly slower processors and less memory, as well as smaller screens than desktop machines. However, if you design and develop with these limitations in mind, then you will be able to leverage you content anywhere that Flash Player 10.1 is available.

Furthermore, if you are leveraging functionality that is only available on a subset of devices, then of course, your content can only leverage that functionality on devices where it is supported. This is the same as on the desktop when using APIs to access the user’s microphone and webcam. If the target platform supports the functionality then you can use the APIs to access that functionality. (The Flash Player includes APIs to check at runtime if specific functionality is supported on any particular target platform).

The important thing is that the Flash Player exposes the APIs across platforms in a consistent manner. So, for example, if you want to use multitouch functionality in Flash Player 10.1, then you will use the same APIs regardless of whether your content is running on the desktop, in a browser, on the iPhone, the Palm Pre, etc…

For the past couple of months, I have been working on a gamed called “Pew Pew”. I originally developed it by targeting the browser, but knowing that I wanted to deploy it to the iPhone, payed attention to performance, and sized the content, and designed the user interactions appropriately. Once the iPhone work was at a point internally that I could deploy content to it, I was able to run my content on the device with no changes at all. Now, I did have to do some additional code optimizations to bring the frame-rate up (something which benefitted the game on the desktop as well), but once I did these, the SWF for my game was able to run on both in the browser on my desktop and as a standalone iPhone application. Indeed, the team working on Flash Player 10.1 for Android asked if I could send them the SWF, and it ran on that device as well with no modifications. This was possible because Flash Player 10.1 allowed me to target the capabilities that my game needed, as opposed to targeting a particular device.

So, to summarize, when developing content targeted at Flash Player 10.1, you should think in terms of the capabilities of the platform, and not get hung up on a particular device or browser.

Creating applications for the iPhone is great. But creating content for the iPhone, and having the option to deploy it on an Android, RIM or Palm Pre device, in a browser on Mac, Windows, Linux and Solaris, and being able to deploy to the Mac, Windows and Linux desktops via Adobe AIR 2.0 is even better.

I have been learning some game development lately, and building my first game (well, at least my first game since Flash 4). I think game development and deployment are some of the real strengths of the Flash player, but ones which we haven’t specifically focused on in a while.

While working on my game, there were a couple of things I needed to do where additional player APIs could have made the development easier (as well as likely speeding up execution). This got me to thinking about other APIs that would be useful for game development. So, what new Flash Player APIs would you like to see that would make game development easier?

Here are a couple from me:

Hit test that tests visible bounds of Sprites. Something like:

sprite.hitTestVisible(anotherSprite):Boolean

Basically, something similar the API Grant Skinner created, but native to the player.

The next API I would like is one that would check for hits against multiple sprites, and return a vector of sprites that we colliding.

sprite.hitTestMultiple(sprites:Vector.<Sprite>):Vector.<Sprite>;

This would make it easy to do collision detection for multiple items, and perhaps lead to a performance boost.

So, what APIs would you like to see that would make game development easier. Please be as specific as possible (i.e. don’t just say “Physics engine” or 3D support). Leave you suggestions in the comments.

We have just released the shipping version of Flash Player 10 (Mac, Windows and Linux). You can find more information on all of the new features on the Flash Player product page.

You can download the player for Mac, Windows and Linux players from here.

You can grab debug and standalone players from here.

You can grab the release notes from here.