Authoring Adobe Flash content for
DROID X and DROID 2 by Motorola

by Allen Ellison

Motorola recently announced two new DROIDS — the DROID X and the DROID 2 — both of which support Adobe Flash Player 10.1. Most notably, DROID 2 is the first smartphone to arrive out of the box with Flash Player 10.1 preinstalled and to benefit from Flash Player hardware decoding of H.264 video for all profiles (Base, Main, and High). The DROID X by Motorola will benefit from the same hardware decoding when Flash Player 10.1 is distributed over the air at the end of the summer.

In this article, I provide some practical design and development guidelines for creating content with Flash technology to deploy on the DROID family of devices by Motorola. These guidelines are also relevant for other devices that support Flash Player 10.1. But first, let's review a few notable features and specifications of the DROID X and DROID 2.

With a 1GHz processor, both the DROID X and DROID 2 offer more horsepower than the original DROID by Motorola (which also supports Flash Player 10.1). Both smartphones are incredibly fast and responsive, especially when viewing video and interactive content on the web. In my experience, the speed and responsiveness of these two smartphones are comparable to a desktop computer.

Both devices have the same pixel resolution as the original DROID, which is 480 × 854, but because the screen on the DROID X is so much larger, its pixel density is 227dpi compared to the 265dpi screen on the DROID and DROID 2. To put this in perspective, the average 17-inch laptop has a 110dpi screen.

Figure 1. Typical smartphone and tablet specifications.

Using Adobe tools, you have two ways to bring your existing or new Flash content to the mobile web — in-browser using Adobe Flash Player or as an installable application using Adobe AIR.

Determining what content users will see

Keep in mind that users might be following a link that a friend sent using a different device or desktop — and they might be viewing the content on Windows, Mac, Linux, a smartphone using Flash Player 10.1, a mobile phone using Flash Lite, a Flash capable television, or lower powered or legacy mobile devices that don't support Flash.

There are two ways to address this: You can introspect the UserAgent string, which is particularly useful if you need to know the phone's model or if you need to make a decision using JavaScript or PHP (or some other server-side script). Or you can use the Flash Capabilities object for a more holistic approach to making runtime decisions based on the device's screen size and capabilities. Using the Capabilities object also makes it easier to author a single SWF file that can be deployed across almost all of these devices instead of authoring and deploying multiple SWF files.

Should your content go full-screen?

One cool feature of Adobe Flash Player is that your content can be viewed without the browser chrome, which delivers a more immersive experience for your users. This capability makes it easier to provide better gesture support for your experience because it eliminates the ambiguity of whether a touch interaction is intended for the content or the web page as a whole.

Also, going full-screen makes it easier to maintain pixel-perfect control over how your content is presented and how the content responds to the phone's physical orientation, whether in landscape or portrait mode — but at the expense of not being able to use the device's keyboard while in full-screen mode. (This is a security feature of Flash Player in both mobile and desktop browsers.)

Even if you decide to go full-screen, this action must be user-initiated. You can explicitly invoke full-screen by associating ActionScript with a touch event or button, or you can set the Flash content's fullScreenOnInteraction parameter in HTML to True, which will cause the content to go full-screen once the user interacts with it.

For that reason alone, you should always consider the non-full-screen option, which we refer to as embedded mode. That means your Flash content displays in context with any other HTML content that is on the page.

If a web page contains only Flash content, the easiest solution is to set the width and height of the Flash content to 100% by 100%, and by default, Flash will use the showAll scale mode.

For embedded mode, there are other considerations to ensure that the browser respects your layout decisions. For more information on how to ensure a consistent appearance of your content across devices, platforms, and operating systems, refer to the Flash Sizing Zen guide on my blog.

Content layout

How your content is presented depends on:

Another way to think of this is that, in the end, your goal is for the content to be the same size physically regardless of device because the finger and eye are expecting to interact on the physical scale regardless of how sexy the screen is — and pixel density is the way you can easily translate pixels to inches (or centimeters).

When designing, it seems easiest to create wireframes and mock-ups that target each class of device (whether S, M, or L as indicated in Figure 1) using the smallest pixel dimensions but largest pixel density in each class. Developers can then use ActionScript (or Adobe Flex early next year) to make the appropriate accommodations.

Device detection in HTML

There are times when you will want to determine if the user is accessing your Flash content from a desktop or mobile device. While the DROID X by Motorola blurs the line somewhat between what qualifies as desktop or mobile and there are no steadfast rules about what qualifies as a mobile device, there are some simple generalizations that are useful in making that determination.

One way is to use JavaScript or a server-side script to determine the device's UserAgent. Although the following example doesn't reflect the other mobile platforms that will be supporting Flash, it is a simple test to determine if the user's device has Android 2.2 (Froyo) or greater:

afp = /android 2.2|2.3|2.4|2.5|2.6|2.7|2.8|2.9|3|4|5)/i;
if(>-1 ) isFlashMobile = true;

Some Android phones (such as the Motorola DROID X by Motorola), while defaulting to mobile view, will allow you to easily switch between these different views by going to the browser's menu | settings | mobile view. In mobile view, the phone uses a User Agent that is recognizably an Android phone and will result in isFlashMobile being true.

However, if the user turns off mobile view, opting instead for a desktop view – then the user agent string becomes indistinguishable from a desktop Mac and this will mistakenly result in isFlashMobile being false.

Device detection in Flash

If you need a more reliable way to make that determination (which might be required for example if your content is only licensed for either desktop or mobile), you might consider using the Actionscript properties: System.capabilities.version or System.capabilities.manufacturer. On a Mac, as an example, they return MAC 10,1,53,64 and Adobe Macintosh, respectively. On an Android phone they return AND 10,1,72,7 and Android Linux, respectively. In short, if either property starts with something other than mac, win, or lin then chances are high that it's a mobile device.

You can also use the screenResolutionWidth, screenResolutionHeight and screenDPI properties to determine if the screen size is more indicative of a mobile device or desktop.

Learn more

To learn more about web content for mobile delivery, visit the Adobe Developer Connection, which includes Fabio Sonnati's excellent recommendations for encoding H.264 video for Flash Player 10.1 on mobile devices. If you'd like to see inspiring examples of Flash content running on devices that support Flash Player 10.1, visit the Adobe Flash showcase for mobile.

‹ Back

Allen Ellison is a solutions architect on the Adobe Lighthouse team, helping Adobe's customers create engaging multiscreen experiences.