Dale Rankine

moket.com

One of the main advantages of using Flash Lite for mobile content is the ability to rapidly design, develop, and deploy rich mobile experiences. Flash Professional 8, with its proven set of tools and the mobile emulator, provides an incredibly flexible authoring environment for creating Flash Lite content of all types.

Another advantage of Flash Lite is the ability to create a single piece of mobile content and have it play on various devices with minimal porting requirements. In the mobile world this is huge! However, as with anything on the fragmented mobile platform—especially among various global regions—some porting of content has to be done to suit the different handsets that can consume Flash mobile content.

This article explores issues I came across when porting content between mobile platforms (Nokia Series 60 and Series 40 handsets) and also between devices (mobile to iRiver U10 device). As you'll see, Flash really gives you a great platform for creating content once and deploying it across various devices with minimal effort.

Requirements

To follow this tutorial you will need to install the following software:

Flash Professional 8

• Try
• Buy

Flash Lite 1.1 player loaded on a mobile device (optional)

Prerequisite Knowledge

No previous knowledge of Flash required. This is for beginners to the Flash authoring environment.

Porting between mobile handsets

Repurposing content for multiple devices is often referred to as "porting." Typically with mobile content, such as Java games or applications, you need to port original content for different runtime engines. This adds a significant amount of time to your development cycle, and can add overall cost to creating the application in the end. One of the great aspects of Flash is the need to do less porting because the player is more ubiquitous and you really only end up concerned with device specs like screen sizes or UI considerations. Even then, you can sometimes make content stretch across more devices using some clever tricks.

When it comes to porting Flash content for different mobile handsets, there aren't that many factors you need to worry about. You might have more to think about if you were, say, going from content for the stand-alone player to making it run in the browser, but for this exercise you are taking content developed for Symbian S60 handsets and porting it to the Nokia Series 40 versions.

The main difference in this example, and in many cases of porting Flash to different handsets, is differences in screen size. Screen size varies mainly between manufacturers, but also between handset models: larger, smaller, wider—even portrait and landscape. Depending on the type of content you're creating, you can allow for these changes by creating your content on a Stage size that matches the minimum end-screen size, and then allow for the fact that content that appears off the Stage of that movie may be visible on other screen sizes (see Figure 1). Of course, your content will need to "bleed" off the Stage of the original movie to a large enough extent to be viewed by the largest screen size on which your content will be viewed.

Figure 1. Extending the content beyond the Stage dimensions of the smallest screen size to allow for when the content is viewed on larger screen sizes

In the case I'm describing, however, I took the opportunity to make some layout changes to the game screens to accommodate a larger screen size. With our game, we went from 176 x 208 pixels on the Nokia S60 to 240 x 320 pixels on the Nokia Series 40 (see Figure 2).

Figure 2. Making changes to the layout in order to make the look of your content fit the new size

Here's how you could attack the problem:

1. Make a copy of the original FLA file.
2. Change the Stage size of the new FLA to the larger size. Flash makes this change relative to the top-left corner, which makes things neat.

3. Resize and reposition backgrounds and game elements, and make changes to any ActionScript that was using absolute _x or _y values.

   It's best if you don't use absolute Stage positions, if possible, just for this reason. For example, if there's a tree positioned on the Stage and you need the _x value of it, don't reference it by something like treeX = 75. Instead, use treeX = _level0.tree._x so that if you move the tree, the value of your variable moves with it.

This task was pretty easy because both handsets are Nokia devices, so the user interface on the handsets were nearly identical. Both handsets have soft keys and a common user experience. Things can get more involved if you move between makes and models of handsets.

Porting between different device types

While the handsets proved pretty easy, we had a bit more fun going between a Nokia S60 and the iRiver U10 multifunction MP3 player. Here we had a non-phone device that uses a very different UI and experience for navigation: a four-way-only click system as opposed to four-way with "clickable select."

For this exercise, we first went back to the drawing board before starting any Flash development. We sketched out the screens as they appeared in natural progression, and looked at the logical directions that people would need to move through the application (see Figure 3). Storyboarding and flow-charting can really help when looking at existing content and how to implement a new UI scheme with it. Of course, this is a good thing to do anytime you're planning a new game or application!

Figure 3. Storyboarding and flow-charting an application

The iRiver U10 has a "horizontal menu" system like the Apple iPod, where you can do things like move up and down in a list of options. To select something, you have to click to the right. If you want to go back, or move out of a selection, you click back to the left.

We carried this through to the flow of the game—selecting options was always done by moving to the right, and quitting was done ultimately by clicking left. We could achieve this because the content didn't really require button clicking to do things like "fire a missile" in a game or anything, so the job was made that much easier. Figure 4 compares the S60 menu system, where you move up and down through a list the click to select, with the menu system for the U10, where moving up and down, and left and right are actually "clicking" the selections also.

Figure 4. Going from the S60 menu system to the U10 menu system

Where to go from here

Creating mobile content has been made a whole lot easier with Flash on a lot of levels. But the fragmented nature of the mobile and handheld device market means that you can't escape porting your content if you intend it to run on multiple handsets or devices. With some thought and logical planning, however, and with the flexibility of the Flash authoring environment, you shouldn't find this to be too much of a drain on resources.

For more examples of porting across mobile devices, check out these articles in the Mobile and Devices Developer Center:

• Best Practices for Porting Flash Animation to Mobile Phones with Flash Lite
• Launch Fighters – Part 3: Porting Launch Fighters to a Mobile Phone
• Developing a Cross-platform Flash Game for Dolce & Gabbana
• Developing and Adapting Flash Games for Flash Lite 1.1

About the author