August 19, 2010

Developing Flash and Flex applications for Android

Posted by Derrick Grigg

Since Apple kiboshed Adobe's hopes of iPhones running Flash content, Android (Google) has stepped up and offered Flash and Flex developers a mobile platform to development and deliver content on. This has come as great news to Flash platform developers who want the opportunity to dive into the mobile environment. Many Flash (and Flex) developers I have spoken to about mobile development are still unsure about what it will take to deliver Flash player based content and applications to mobile devices.

The good news is the development and delivery process is almost identical to the current process. Use Flash or Flash Builder to create a swf file and then either deploy that to a website, to be served up via an HTML page or wrap it with the AIR runtime and packge it for installation on an Android phone as an native Android installer. Really the only difference in developing for the Android platform is the extra step required to create an '.apk' file if you want to create a stand alone application.

The bad news is the environment that the content and applications are running in is quite different from anything the vast majority of Flash platform developers have worked in. The screen is small, the bulk of user interactions are touch based, the screen can easily be rotated and tilted, the user is often quickly looking at the screen while interacting with the environment around them (ie texting and walking at the same time) and the processor doesn't have the juice most modern desktops and laptops have. This means that while the swf delivery and development process is quite familar the UI and UX development is anything but. Add in the processing constraints and most Flash platform developers will quickly realize there is a significant learning curve to developing Flash and Flex content for Android (and mobile in general) devices.

So what are the key areas developers need to be aware of?

  1. Screen size
  2. User interaction
  3. Device capabilities
  4. Performance

1. Size, it really does matter

Below are two screen shots of the same Flash application running on a Google Nexus One and a normal desktop computer. The application is 480 x 800. The first image shows the screen as seen on a normal desktop computer with the screen resolution set at 1280 x 1024 (fairly standard desktop resolution). The second image shows the same screen scaled to the physical size as seen on the Nexus screen. It might seem obvious that the mobile screen will be smaller than the desktop screen but watch how screen resolution affects something that is the "same" size.

Desktop screen shot

Flex Android app on desktop

Android (Nexus One) screen shot

As you can see there is a huge difference in the physical size of the two screens even though the application is viewed at 480 x 800 pixels on both devices. Mobile devices have much higher screen resolutions than normal computers, 240dpi vs 72dpi. As you can see from the images above this makes a huge difference.

For mobile applications this has two very big implications.

First a smaller screen with a much higher resolution means you have much less physical real estate to work with when laying out the user interface. Designers need to be acutely aware of this when creating screens and views. Add in the fact the users are often quickly glancing at the screen which means screens can not afford any clutter and designers have a difficult task in packing a lot of meaningful content into a very small area.

Second, since everything appears much smaller on mobile screens things like text and UI controls (button, checkboxes, etc) need to made larger for readability and clickability (if a beer company can use drinkability I can use clickability). On a mobile device the main pointer is the finger tip which is a lot larger and less precise than a mouse pointer. In a desktop application the typical button size is around 25 pixels in height, on a mobile device 60 pixels is the norm, anything smaller than that and it becomes very challenging to click the button you want.

I couldn't help but be reminded of this Simpson's clip after my first experiments building a Flash application for the Android.

This leads to my second point.

2. User interaction, it's all about the finger

Apple and the iPhone ushered in a whole new era of computer interaction. Sure 'touch' has been around for a long time, but it was Apple who made it mainstream. Point and click are things of the past, now it's point, flip, swipe, pinch, wipe. Sounds more like a heated game of rock-paper-scissors. The great news for Flash platform developers is that AS3 has full gesture support built in and ready to be used. Events are dispatched for a multitude of user gestures including tapping, swiping and rotating. AS3 also supports multi touch for instances where multiple touch points need to be tracked.

This is a whole new territory for Flash and Flex developers, we generally just interact with the mouse and keyboard, a few of us (myself included) have developed for larger touch screens, but not small mobile screens. Fortunately there is some good information to be found on designing for human interaction. Google has provided some guidelines for user interface design and Apple has some really good (and thorough) documentation on Human Interface design.

This is an area that will make or break an application. It won't matter how great the apps processes information or what information it displays or what it allows users to do, if the control is non-intutive and confusing users will drop it faster than a hot potato (and they may just throw their phone).

3. Device Capabilities, the swiss army knives of personal computing

Most mobile devices have as many sensors and media inputs as swiss army knives have blades. There are GPS sensors, accelerometers, touch screens, cameras, microphones, video cameras, scroll balls, the list goes on. The trick for developers is figuring out how to leverage the various sensor inputs (and outputs) to create unique and pleasant user experiences.

For the Flash and Flex developer most (if not all) of these sensors will be available to AIR based applications and most of them will be available to browser based swfs. This an area where Flash applications will really be able to shine. Flash has supported camera and video input for a long time, working with these types of media inputs should be second nature to many Flash platform developers. Some of the other sensor inputs are new (ie accelerometer, microphone and gps) but Flash has the advantage of being able to access and use them, sorry HTML5 and javascript.

Personally I think Flash is uniquely positioned to offer mobile users amazing experiences based on the capabilities of the devices. Flash has been used for years to create amazing, immersive, media rich user experiences. With increased ways to receive and provide feedback between the user and device who knows what applications will start to look like and how they will function.

4. Performance, where the rubber meets the road

Performance, performance, performance. This is "allegedly" why Apple doesn't offer Flash on the iPhone/iPad. I don't buy it. I have seen Flash running on Android devices first hand, both in the browser and as stand alone applications and trust me it runs perfectly. Adobe has worked very closely with mobile manufacturers to provide hardware acceleration, reduce battery usage and deliver maximum performance with the upcoming Flash 10.1 release.

The critical issue for developers is to remember they are developing for devices that don't have the same processing resources of typical desktop and laptop computers. Special attention needs to be paid to optimizing performance as much as possible. Grant Skinner has a great presentation on Flash performance, where gains can be found and where trouble lurks. Garbage collection, green threading, blitting and generics are all areas that AS3 developers should understand in order to optimize and maximize the performance Flash can deliver.

The old computer mantra is "garbage in ...garbage out". If your application runs slow, freezes or crashes, don't blame the device, virtual machine, Adobe, Google, Android or your mother, first look at your code. This is where the majority of backlash against Flash performance should really be pointed. It's not the Flash plugin and runtime, it's the fact that anyone can "develop" a Flash application and many people that do, don't understand the performance and memory implications of what they are doing. With the ability to release Flash applications and content to mobile devices, Flash will be under increased scrutiny, do the community a favor and write clean, efficient code.

Where to next?

Who knows? The mobile environment is like the internet was 10-15 years ago, the wild wild west. A lot of really cool things will get made and a lot of dogs will come and go. The only thing I am sure of is that the Flash platform will have a large place in how applications and content get developed, deployed and used. It's an exciting time for Flash platform developers, especially after all the HTML5/Apple rhetoric. Get a mobile device, get some neat ideas or find someone who has them and build something amazing, I know I will be.

Derrick Grigg is a freelance web contractor who specializes in developing Flex and Flash applications. He can be found at or followed on Twitter


Unknown said...


i am also a flex developer and working flex from last two years. I have a very basic question about the Android and flex , i develop a contact book app for android in flex when i make package .apk for emulator i am very much disappoint for making that with third party tool.

my question is that why adobe not provide a direct export/ release functionality from flash builder for android?

Thanks for info.

flex development india said...

Article is awesome. How do i need to start Android development. Is there any SDK for developing Android application?