Mobile and Devices Developer Center

Authoring Content for Flash Lite—The Ynot Approach

Creating Content for the NTT DoCoMo 505i, 505is, 506i Phones

Flash Lite is designed for consumer mobile devices with limited memory, processor speed, and display area. Content created for Flash Lite is comparable to content created for Flash Player 4. For this reason, we initially wanted to create Flash Lite content from scratch, to maximize the power of Flash 4 ActionScript commands. On second thought, however, we decided to make our existing Internet-based Flash content available to the fast-growing market of mobile phone users instead.

Flash Lite and the NTT DoCoMo 505i, 505is, 506i series phones

Although we were very excited about the Flash Lite features, we had to go through a small learning curve when authoring content for Flash Lite, because the current version of Flash Lite does not support the dot syntax, which we had just mastered, but uses the tellTarget action instead to apply instructions to a particular Timeline or movie clip.

Still, Flash Lite supports all the necessary features developers need to create attractive, rich content for the NTT DoCoMo i-mode phones and other handsets and small form factor devices.

The following list provides an overview of the benefits and limitations we experienced when authoring Flash Lite content for the DoCoMo 505i phones. (For more information on Flash Lite and the 505i, 505is, 506i phones, see "Flash Lite Authoring Guidelines for the i-mode Service by NTT DoCoMo" and the "Flash Lite Users Guide," which are linked from the Macromedia Flash Documentation page.

• Compatibility with Flash Player 4 content: If your Flash content is Flash Player 4 compatible, you can easily publish it for i-mode handsets by exporting it to the Flash Lite format in Flash MX Professional 2004. Note, however, that there are some ActionScript limitations with regard to external movie access (loadMovie) and mouse-driven events (for obvious reasons—mobile phones do not support mouse input).
• Device-dependent performance: The runtime memory available to Flash Lite movies running on i-mode phones is not only limited, but also varies from model to model. For this reason, you should test your content on actual i-mode series phones, and not just with the emulators that come with Flash MX Professional 2004.
• Support for full-screen, high resolution QVGA (240 x 320 pixels) display: Previously we were not able to display our i-mode content in full-screen mode.
• Support for i-mode content of up to 20KB in size: This limit refers to the combined size of an i-mode page's CHTML and SWF content. Web pages larger than this limit cannot be downloaded. However, you can run your movie directly in the i-mode browser, in which case the size of your SWF file can be up to 20KB.
• No support for interactive content in i-mode browser pages: If you want users to interact with your movie, you have to load the SWF file directly in the i-mode browser instead of embedding it in an i-mode compatible HTML page. Note that you can add a warning screen to alert users of this limitation when embedding your content in an i-mode compatible HTML page.

• Sound playback only with a button click: Flash Lite does not support streaming sound, sound mixing, or sound looping. Only event sound is supported and only one sound can be played at a time. Flash Lite for 505i, 505is, 506i phones, however, does not support the standard Flash Player audio formats; it only supports the Melody Format for i-mode (MFi) audio format.

  Note: For more details on Flash Lite for 505i, 505is, 506i phones and sound, see the Device Sound support section of Bill Perry's article, "New Features for Mobile and Device Developers in Macromedia Flash MX 2004."

• Device-dependent playback frame rate: A playback frame rate of 6 to 8 frames per second is appropriate, depending on the type of content and the CPU power of the target device.

Porting Flash Content to Mobile phones

For our first experiment in authoring Flash Lite-compatible content, we wanted to convert one of our most popular animated e-cards, Ariga-tou (Ants-Ten, shown below), to the Flash Lite format without changing its overall look and feel. (Click inside the yellow circle of the gift box to play the content.)

This content requires Flash

To view this content, JavaScript must be enabled, and you need the latest version of the Macromedia Flash Player.

Download the free Flash Player now!

The card is Flash Player 4 compatible and was created by our in-house designer, which is one of the reasons we picked this card—if any changes needed to be made to the design, our designer would be able to take care of it. The other reason for picking this card is the relatively small size of the original SWF file—only 44KB.

The experiment was a success, as the following SWF file demonstrates.

This content requires Flash

To view this content, JavaScript must be enabled, and you need the latest version of the Macromedia Flash Player.

Download the free Flash Player now!

We only had to make two adjustments to the original content in order to accommodate the display size and limitations of the target device:

• We changed the position of the greeting.
• We eliminated the button action (the animation starts automatically).

Contrary to our expectations, however, this e-card did not play on our target phone. Instead of an animated greeting, we got a warning message (see Figure 1).

Figure 1: Despite its small file size, our movie did not play on the target device.

The problem we were facing had to do with the complexity of our content and the limited runtime memory of our target device. For our original content, we manipulated quite a few vectors on the stage. What we overlooked in our experiment is the correlation between the number of vectors manipulated on the stage and the target system's CPU power—the more vectors we use, the more CPU power is required (which is also true for desktop computers). In our case, our movie contained too many complex shapes that proved too taxing for the phone's CPU, and instead of rendering the content, the phone simply terminated the playback.

Figure 2 shows the outline display of the frame that resulted in the termination of the delivery. Even if the same symbol is displayed, the target device is unable to render the number of vectors that define the content.

Figure 2: This is the outline display of the frame that terminated the rendering of our movie.

Replacing Vectors with Bitmaps

In order to solve this problem, we reduced the number of vectors on the stage. To that end, we replaced the vectors that defined the shapes of the ants with bitmaps, in this case small GIF files (see Figure 3).

Figure 3: We replaced complex vector shapes with bitmaps.

Figure 4 shows the same frame as Figure 2; the key difference is that the vectors we used to define the ants on the stage have been replaced with bitmaps. This simple change resulted in a significant reduction of the number of vectors that had to be rendered on the target phone. In the end, our content contained only four vectors, and when tested on the target device, it played seamlessly.

Figure 4: After replacing vector shapes with bitmaps our movie played flawlessly on the target phone.

Note: Using bitmaps produces larger file sizes, which apparently provide fewer problems for Flash Lite-enabled phones than complex shapes. Still, for best performance, you should make sure that you find the right balance between file size and runtime performance. For tips on using image compression, see the section "Bitmaps versus vectors" in "Flash Lite Authoring Guidelines for the i-mode Service by NTT DoCoMo" on the Macromedia Flash Documentation page.

Page 2 of 4

Previous Page

Next Page