Gauging resource consumption when creating content for Docomo mobile phones

One of my regular activities at the office is creating Flash content for the Docomo 505i/505is and 900i series of mobile phones. I am rather lucky (or cursed) to have access to all (17) of the handsets for testing. While the Flash players for the various phones are all basically the same, the hardware specifications are not, so, what works on one phone may crash the browser of another. Sounds similar to developing for any platform I guess, however the phones are far pickier than their Pocket PC/PDA mobile cousins.

When creating Flash Lite content for the Docomo phones there are a lot of restrictions and idiosyncrasies that you have to learn to work within, or better yet, exploit. While it is fairly easy to stay below the file size limitations (20k for the 505i/is, 100k for 900i), tolerate the 8-10fps and avoid unsupported Actionscript (think flash 4 with limitations), the biggest issue is system resources. As you all know, Flash does not have a monitor for system resources and the various FP players will pretty much take whatever they can get their code on. While not generally an issue on desktops and notebooks, it is a huge problem for mobile devices, especially in phones that lack the processing power of Pocket PCs and PDAs. This is one reason that the phone simulator should only be used for the most basic testing and otherwise be avoided. While it provides a way to test screensize and basic interaction, the simulator has the full resources of the computer at its disposal, so does not realistically portray how a movie will play. To be perfectly honest, I NEVER use it, but I understand that many designers/developers have no other choice, so it is better than nothing.

Another issue that serves to complicate matters is the lack of details given by the phones during error reporting. It consists of basically three message (I know I am simplifying things here).
1. The file is unsupported
2. The file is too big.
3. The file (image) is not functioning correctly

While number 1 and 2 are easy to solve (export as flash 4/lite, make the movie smaller), number 3 is the BIG ONE. This can be anything from misbehaving Actionscript to the phone hanging on processing the number of vectors present. I have found that more often than not, it is an issue of resource availability. Through extensive testing (coupled with a good share of cursing in English and Japanese), I have found a good way to pinpoint if it is an issue of resources and how to detect potential problem areas during development.

The Bandwidth Profiler is your friend.
When testing Flash Lite movies, I set the bandwidth profiler to show the Frame by Frame Graph and to mimic a connection of 2.4kbs. (This is not to portray how the file actually loads when online, because the phones download raters are much faster.) While running a movie, look for spikes in the bandwidth usage above 7 kbs, especially in a movie that has any animation, much Actionscript or is entirely vector. A single bitmap that causes a spike is not as big an issue, as the phone is not having to process vectors, although there is a whole other area of problems associated with bitmap graphics (something I will try and write on later). These are areas that will make the slower phones crash due to a lack of resources. Generally 6-7kbs is fine, but over that and you are asking for trouble. A way to double check if it is resources is see where the animation encounters an error on the phone. If is corresponds to a frame with a bandwidth spike, you most likely need to stagger the graphics over a few frames. Below is a “real world” example of a project I am doing right now.

The project is a Flash “machiuke”. Basically this is an animated desktop/standby screen for the phones. The piece in question is fairly simple, with only a small amount of animation and no scripting beyond a stop().When our testers ran it through all the phones, it encountered problems on almost all of the 505i/is handsets (I do direct testing on my 900i during dev, which tells me they actually increased the phone specs in the 900i series and not just the file size of SWF supported). It weighs in at 13 KB, so file size is not the issue.

I opened up the file to see what might be causing the problems and it seems I was a bad little designer and have it all in one frame, causing 13kbs to be processed all at one time, in an entirely vector design. I got sloppy due to a tight deadline and multitasking on projects and only focused on file size. Bad me! Bad Designer! No cookie! (Sorry, lack of sleep and all).

So, what I did was spread the three main elements out over three frames. Background and border load in the first frame, one animated element in frame 2 and the second animated element (a character) in the third. This dropped the bandwidth consumption to just over 4k per frame and it runs with no problems on all the phones.

Hope this helps someone out. I will try and post more on the topic of Flash Lite design and development in the future, but until that time, feel free to contact me with any questions.

Kris

Posted by Kris at April 28, 2004 12:51 PM