By: Tom Green , David Stiller ,
Page 1 of 6
It should not be news to discover that Flash has gone mobile. The sheer number of wireless handsets and other wireless devices is driving a demand for rich content that makes the text-based solutions for cell phones and PDAs that were all the rage a couple of years ago look like charcoal scrawls on a cave wall. The reason is the mobile market discovered what Flash developers have known for years: Flash content results in small, fast-loading files.
It isn't only corporations that are driving the demand for mobile content. Educational institutions ranging from K-12 to postsecondary across North America are seriously examining how these devices can be used to deliver educational content and are developing courses that teach their students how to produce applications for these devices. Whether it is a Flash developer friend of ours using his cell phone to track his progress along the Pacific Coast Highway in California or pedestrians hooking into the traffic cameras in New York City, it is difficult for most to understand this technology is still in its infancy. To get a real sense of what you can do, start with this chapter, and then point your browser to the Adobe Mobile & Devices Developer Center.
We would be remiss in not mentioning that one of the best Flash mobile books out there is Foundation Flash Applications for Mobile Devices by Richard Leggett et al. (friends of ED, 2006).
The first thing you need to know about developing Flash applications for mobile devices is not one thing you have learned about Flash CS3 and ActionScript 3.0 in this book applies to devices. Everything you have done to this point in the book has relied on Flash Player 9. Flash mobile uses Flash Lite 2.0, which is roughly equivalent to Flash Player 7. This means that every scrap of ActionScript 3.0 code and every component, filter, or blend effect added to a new ActionScript 3.0 document simply can't be used in a device. We tell you this not to scare you off but to make sure you enter this fascinating and emerging field with your eyes wide open. Other things you need to know include the following:
- The phone is not a computer: There is no mouse for user input. You are limited to the up, down, and select keys on a handset along with the number keys and * and # keys on the phone's keypad.
- Forget about fonts: You are dealing with a screen that could be around 170 pixels square. This means text must be both legible and readable. Though you can embed fonts, they add to file size.
- Small is a very good thing: If something has no purpose other than to add weight . . . throw it overboard. Flash content in devices is the only content you will deliver that people have to pay for. Data downloads are charged on the user's cell bill by having the user "pay by the K." For example, one of the authors has a plan that charges 3 cents per kilobyte downloaded. This can quickly add up. Keep the code to a minimum, and, if you must use bitmaps, use them at their final size and use compressed bitmaps. Avoid vectors if you can, and substitute them with JPG images. (Yes, this isn't what you would expect to hear while authoring Flash contentâ devices are different!)
- Be aware of the device: No two handsets are the same, and this includes screen real estate. Device Central will become your most important resource for this aspect of Flash development.
- Test, test, test, test, test . . . : Did we mention test everything? That includes testing both in the emulator in Device Central and on the actual handset.