Wow! The last few days have been pretty amazing and I’d just like to thank everybody for the overwhelming positive response to my X-wing Targeting Computer app.

I’ve had desperate Star Wars geeks begging me to release it on the Android Market. Others have even resorted to threatening me with physical violence if I don’t

My original teaser post was a little vague – I honestly wasn’t expecting such a reaction – so I thought I’d take a little time to answer some of the questions that have been put to me via email or posted on the various sites out there:

Is it real or fake?

It’s real, although still in development.

Will you be releasing it on the Android Market?

Yes.

What version of Android will I need to run it?

Initially it will run on Android 2.2.

When will it be available?

It’s written using Adobe AIR for Android. I’m aiming to release the Targeting Computer app to coincide with the public release of AIR, which is itself still in development. Adobe has yet to announce a date but I’m hopeful that it won’t be that far off.

What about older versions of Android?

My priority is the Android 2.2 version but support for older versions of Android is a possibility.

What about an iPhone version?

What! You mean turn to the dark side? Actually I’m looking into it – wouldn’t want all you iPhone fans feeling left out.

Symbian, Blackberry, Windows Mobile?

Depends on time, resources and demand. If you want to see it on any of these platforms then please let me know. Come to think of it, it would probably look really good on the upcoming Nokia N8.

So are you a super nerd/geek yourself?

A girl I used to work with once said I reminded her of the Rain Man. I mistakenly took it as a compliment. Does that answer your question?

How much do you like Star Wars?

I paid to see the Phantom Menace nine times when it was originally released. I tried for a tenth viewing but unfortunately they stopped showing it at my local cinema before I had the chance. So yeah, I like Star Wars a lot. I prefer the original trilogy though.

I hope that has helped clarify things.

I’m sure a lot of you can now sleep more easily knowing that you’ll finally get the opportunity to know how it feels to be an X-wing pilot hurtling towards the Death Star’s exhaust port.

Until you do though, take it from me, it feels pretty damn awesome!

I’ve always wanted to be an X-wing pilot, helping the Rebel Alliance in their desperate struggle against the Galactic Empire. Unfortunately we haven’t yet acquired the technology in this galaxy to build reliable and safe X-wing fighters. However I wasn’t gonna let that put me off and embarked on a mission to bring my childhood fantasy one step closer to reality.

Thanks to Adobe AIR for Android and some guidance from the force I’ve constructed a GPS-enabled version of the Targeting Computer found within Luke Skywalker’s X-wing Fighter. So now you can at least pretend to be an X-wing pilot while you’re driving your car.

It’s really simple to use. Just lock in your target location and start driving until you eventually reach the exhaust port, er, I mean destination. Your distance to the target will be continuously updated as you drive and you can even hear radio chatter from your fellow pilots!

When you’re not driving why not take your Targeting Computer to the office and use it as a clock. Yup, the Rebel Alliance thought of everything. Just switch it to Clock mode and mount it on your desk to impress the hell out of your friends. You can even set an alarm and watch as your Android phone closes in on the target time.

Now all I need is for George Lucas to spot this post and snap my idea up. George, we could both make a lot of money from this one. What do you say? 20-80 split? 80 percent for me and 20 for yourself. I think that sounds fair

Many Bothans died to bring you this post.

You’ve probably noticed my posts haven’t been as frequent of late. We’ll it’s all Adobe’s fault! You see I’ve been spending way too much time coding cool stuff for my Google Nexus One rather than blogging. Hold on, actually maybe that’s a good thing.

Anyway, I have managed to finish an AIR for Android app that I’ve been working on and will hopefully be able to post some videos of it in a day or so. In the meantime I thought I’d share some resources I’ve found extremely useful over the last few weeks.

• Setting up your development environment
• Accessing the camera on your Android device
• ActionScript 3.0 API support for mobile devices
• Debugging with AIR for Android
• Flash Android Components
• Developing Flash and Flex applications for Android
• Android, AIR and the Camera
• Authoring mobile Flash content for multiple screen sizes
• AIR2.5 StageWebView

I’m really enjoying AIR 2.5 for Android. Performance is good and the workflow makes coding and deployment easy.

If you haven’t already signed-up for the prerelease program then I’d recommend you do so by clicking this link.

This wasn’t an easy decision. After all I’m supposed to be a Nokia fan boy. However, after much deliberation my trusty wee Nokia 5800 has been put aside and I’m now using the Google Nexus One as my primary mobile.

Anyone who knows me will be well aware that I’m quite enthusiastic when it comes to the Symbian S60 operating system. It’s something I’ve grown comfortable with over the years and has always dictated what phone I get next.

I’ve been tinkering with Flash on mobile since Flash Lite appeared on the scene and Nokia have always done an excellent job of supporting Flash Lite on their mobile platforms. Flash is actually the reason I got my first Series 60 handset and it’s the reason why I’ve stuck with Nokia devices for so long.

However things are changing and Nokia don’t seem to be keeping up. Flash Player 10.1 and Adobe AIR 2.5 have now arrived on mobile and I’ve been desperate to explore both. Unfortunately there’s no sign of Flash Player 10.1 on any upcoming Nokia devices and they seem to be going with Flash Lite 4 in the short term rather than AIR.

So for the time being I’m moving over to Android, where I can get a much more complete web experience and also create cool Flash apps until my heart’s content.

This doesn’t mean I’ve become an overnight Nokia hater or anything. I will be keeping an eye out to see how things develop. The Nokia N8 looks like it could be quite interesting – It’s just a shame its doesn’t support Adobe AIR.

Flash competitions are like buses. You wait ages for one then three come along at the same time. But hey I’m not complaining and neither should you because three separate competitions simply means three more chances of winning something!

Adobe are really starting to push the Flash platform on mobile and along with its partners is looking for exciting game content that runs on either Adobe AIR for Android or Flash Player 10.1 for mobile. There are generous prizes on offer for each of the contests ranging from cash to software bundles.

Kongregate are offering almost $30,000 in prizes including Adobe CS5: Web Premium for the top 5 entries. Made for Mobile are offering over $20,000 in prize money spread across 105 (yes 105) winners plus Adobe CS5: Master Suite for the best 3 entries. And lastly (but certainly not least) is Cell Your Flash Game’s contest where the top 3 will win Adobe CS5: Master Collection and take a split from a cash pot of $4310. The next 147 (this isn’t a typo either) people will receive $100 each and a few will also receive Adobe Flash Professional CS5.

So what are you waiting for? Get coding and see what you can come up with. Oh and try not to bite off more than you can chew. The submission dates are actually quite tight.

Right all I need now is a great idea! Err,….. Damn! Oh well maybe next time

Good luck!

The Challenge

There’s much talk of creating content once with Adobe Flash and running it just about anywhere. Now anyone who’s had experience writing Flash content for mobile will know that it’s not that simple (all devices aren’t equal after all) but hey, I’m always up for a challenge and thought I’d try and port some web-based content to a wide range of handsets.

So what to port? Well I recently posted about the WeeWorld Fame Game, which we released a few weeks back, and thought that it would be an ideal candidate. Now I appreciated the sensible thing would be to plan with mobile in mind from the outset but I was genuinely interested to see how difficult it would be to take content that was designed primarily for the web.

Now if you can’t be bothered reading on – it’s quite a long post – or don’t have the time then why not just watch the video above where you can see the results of my little experiment. If you want to know more then read on.

The Devices

The first step was to decide on some phones. I could just have picked a bundle of devices that supported the same Flash runtime but that would have been cheating so I went with the following handsets and flavours of Flash:

• iPhone & iPod touch – Adobe AIR / ActionScript 3
• Google Nexus One – Adobe AIR / ActionScript 3
• Nokia 5800 XpressMusic – Flash Lite 3.1 / ActionScript 2
• Nokia N95 – Flash Lite 2.0 / ActionScript 2
• Nokia 5310 XpressMusic – Flash Lite 2.1 / ActionScript 2

Now that the handsets had been selected it was time to actually do some work.

ActionScript 3 to ActionScript 2

From the device list above there’s an obvious problem. In order to work on the Flash Lite handsets the Fame Game needed to be ported from AS3 to AS2. This was by far the biggest obstacle and took a few days to re-write. Maintaining two code bases for a project is hardly ideal but considering the extra device coverage it would give it was worth the effort.

Sure, Flash Lite 4 supports ActionScript 3. However until Flash Lite 4 devices start to gain some penetration most developers will probably have to fall-back to lower versions of Flash Lite, which unfortunately means using ActionScript 2 for the time being.

We’re clearly in a transitional phase for Flash and mobile. Flash Lite was a very good toe in the water for Adobe but considering the pace at which people upgrade their handsets, it’s clear that ActionScript 2′s days are numbered. From this point onwards devices are going to support either Adobe AIR (high-end devices) or Flash Lite 4 (lower-end devices) both of which support ActionScript 3.

However for the time being you’ll probably have to stick with AS2 to capture as wide an audience as possible.

Layout

One major headache for any mobile developer, no matter what language they’re using, is the fact that screen dimensions vary wildly across devices. Ensuring your application fits all these different screens is difficult enough when considering mobile from the outset, but I had the added problem of working with something that had originally been designed for the web where one size fits all.

Thankfully the Fame Game’s original layout was such that it could quite easily be tailored for different dimensions. The big question was whether to write code to dynamically alter the layout on-the-fly or to simply code for each screen. I opted to code for and create separate builds for each screen. I felt this would give me more control over the layout and with minimal effort.

This also allowed me to create multiple FLAs – one for each target device. Although the original code base performed much of the layout, where appropriate, layout was taken care of on the Stage. The visual assets themselves were all pre-sized and stored in the library. By creating multiple FLAs I was able to re-purpose the original artwork for each of the target screens, without resorting to bundling multiple versions of the same artwork into the one FLA.

Now you might think that coding for multiple screen layouts would bloat the final build size. After all, if you target five difference screen sizes then surely you’d have to include in the final SWF code to perform the layout for all five screens? Well I managed to avoid that by creating separate layout classes for each screen and ensuring that each build pointed to only the layout class that was required.

Here’s roughly how the folder structure looked for this code:

src/platform/android/Layout.as
src/platform/iphone/Layout.as
src/platform/web/Layout.as

The important thing to note from the folder structure above is that although each class is in a different folder, they all have identical fully-qualified class paths. Essentially it is the same class but in three different locations. Each class holds static data that is used to define layout information related to a particular device’s screen dimensions.

Now to target the Google Nexus One I simply added a class path to its FLA’s publish profile that pointed to src/platform/android. For the iPhone FLA I added a class path that pointed to src/platform/iphone, and for the standard web version’s FLA I added a class path to src/platform/web.

The final step was to work my way through the existing Fame Game code and replace any layout-specific code with calls to the Layout class. So whereas before there might have been screen-specific code that looked like this:

// Position the WeeMee just off-screen.
weemee.x = -340;
weemee.y = -30;

We now have the following screen-independent code, where the Layout class used is determined by the class path set in the publish profile:

// Position the WeeMee just off-screen.
weemee.x = Layout.weemee.x;
weemee.y = Layout.weemee.y;

With this implementation, any new screen sizes can be implemented without bulking up the final SWF size. It also provides tighter control over the layout compared to a dynamic layout implementation.

The WeeMees

Central to the WeeWorld site is the WeeMee avatar and it’s these little cute characters you get to vote for in the Fame Game. WeeMees are dynamically generated on our server using Blue Pacific’s Turbine and served as Flash 7 SWFs with a smattering of ActionScript 2 used to perform certain animations and effects.

Although this approach works a treat on our live site things were a little different for my mobile versions. Only the Nokia 5800, which supports Flash Lite 3, was able to actually load the WeeMee SWFs.

Both the N95 and the Nokia 5310 were restricted to Flash Lite 2.x, which had some rendering issues with the WeeMees. AIR for iPhone does not support the loading of external SWFs that contain ActionScript so SWFs were out of the question for that. And although AIR for Android can load external SWFs it only supports SWFs with ActionScript 3, so WeeMee SWFs were a no-no there too.

Thankfully at WeeWorld we can fall-back to using PNGs of our WeeMees, which turned out to be quite handy for this challenge. So for the iPhone and Google Nexus One versions I changed the config settings for each to request PNG WeeMees from the server.

Unfortunately the Flash Lite runtimes on both the Nokia N95 and 5310 didn’t support PNGs so a few additional changes had to be made. Instead of serving PNGs to these devices some code was written on the server to convert the PNGs to JPEG. This had one side-effect – any transparency behind the WeeMee was lost, which in turn blocked-out the nice gradient background within the app and generally looked quite ugly.

It wasn’t a big deal though. For these two devices I removed the gradient background and replaced it with a solid colour. I then ensured that the same colour was rendered behind the WeeMee JPGs that were now coming from the server. It worked quite well and most people wouldn’t have been aware of the changes when using it.

You might think that this all sounds like a huge amount of ActionScript changes were required for each target device. However, the reality was that the work was really all done on the server, and the ActionScript itself actually remained relatively unchanged.

Keypad Support

The final hurdle was to add keypad support for the Nokia N95 and Nokia 5310. The other devices supported touch-screen meaning that no code changes were required from the original web version – both AIR and Flash Lite 3 can handle the touch events as if they are mouse events, which in my case was a major time saver.

Keypad support was required to allow the user to move between the three voting icons and make a selection. The voting icons were all managed by a VoteIcons class, and adding keypad support wasn’t that difficult. These changes were only made to the ActionScript 2 code base since all the ActionScript 3 builds were for touch screen phones.

The first step was to move VoteIcons into the root of the platforms folder that was first created to help with layout. The class was then renamed to VoteIconsBase and a new method named onKeyDown was added. The top-level application class was then made to listen for key events and pass them to the VoteIconsBase class.

Within each of the platform specific folders a new class was created called VoteIcons that extended VoteIconsBase. The folder structure looked like this:

src/platform/
             VoteIconsBase.as
             n5310/
                    VoteIcons.as
             n95/
                    VoteIcons.as
             n5800/
                    VoteIcons.as

The implementation for onKeyDown within VoteIconsBase does nothing. Instead it relies on the sub-classes overriding it. Since the Nokia 5800 is a touch-screen device, it's sub class does nothing with the onKeyDown method. Both the Nokia 5310 and Nokia N95 versions of VoteIcons however do have implementations for this method, ensuring that the key events are handled and the correct icon is highlighted and selected.

As with the layout handling, certain class paths had to be added to each FLA's publish profile depending on the target device.

Every FLA required the VoteIconsBase class, so the following was added to each FLA's class path: /src/platform.

Then one additional class path was added depending on the target device. So the Nokia 5800's publish profile was pointed towards /src/platform/n5800; the Nokia 5300 FLA looked for the VoteIcons class in /src/platform/n5300; and the Nokia N95 build got its code from /src/platform/n95.

Optimisation

While porting to the various mobile devices I attempted not to optimise the code - I felt it went against the spirit of the challenge. However I did allow myself to make some tweaks to each of the FLAs where I felt it might help device performance.

With the exception of the Google Nexus One I reduced the frame rates to suit each device:

• Google Nexus One - 30fps
• iPhone - 16fps
• Nokia 5800 XpressMusic - 16fps
• Nokia N95 - 12fps
• Nokia 5310 XpressMusic - 12fps

When repurposing the graphics for each FLA I was careful to ensure that all library clips were already scaled to fit the device's screen - Resizing instances on the stage is a very bad idea and can seriously hurt performance on mobile.

The iPhone's FLA also got some extra attention. I replaced some of the vector graphics with bitmap versions (I really should have done this for all devices) and also set many of the movie clip instances to 'Cache as bitmap' ensuring that they got stored on the iPhone's GPU for faster rendering.

I could have spent more time on the iPhone version to bring its frame rate up to 30fps, but it would have required code changes and considering Apple's ban on Flash content anyway I felt it wasn't worth the effort, and as I had stated before it went against the spirit of the challenge.

Coverage

So I ended up with the Fame Game running on five different devices. I was also planning on creating a version for my Sony Ericsson W705 but unfortunately it recently died and is now looking down on us from Silicon Heaven.

Now given the sheer number of devices out there, five doesn't seem like that many so let's spend a little time explaining why I selected these devices - it wasn't random you know.

Both the Nokia N95 and Nokia 5800 use the Symbian S60 operating system. For those who don't know, Symbian phones are everywhere and the OS currently holds the lions share of the smartphone market. In the first quarter of this year over 25 million Symbian S60 smartphones were sold. That's 44% of all smartphones sold worldwide in that quarter!

I performed a quick check in Adobe Device Central CS5 and counted 72 Nokia handsets alone that would run the exact same builds of the Fame Game that I deployed to the N95 and 5800. I'm not entirely sure just how many different handsets Nokia has but I'm pretty sure those 72 listed in Device Central would cover a significant number of them. So by targeting Flash Lite 2 and Symbian S60 you're effectively targeting millions of devices.

The Nokia 5310 XpressMusic isn't a smartphone, it's a fairly inexpensive mass market handset that runs the S40 operating system. Device Central listed 35 S40 phones that would run the same build of the Fame Game that was deployed to the Nokia 5310. Again that seems like a fairly good result to me and shows the value in continuing to target Flash Lite in the short term.

Now onto the iPhone/iPod touch. Okay I know Apple has banned any content written in Flash from the App Store but I had my iPod touch lying around and thought it would be a shame not to include it in the challenge. But if Apple were to have a change of heart then the Fame Game would run on the 51 million iPhones and 20 million iPod touches that have been sold over the last 3 years or so.

Finally there's the Google Nexus One, which runs the Android operating system. With 5 million handsets being sold in the first quarter of this year alone Android is gathering some significant momentum and going forward could be the mobile platform of choice for Flash developers.

So you see by carefully targeting a few key handsets I've managed to capture quite a large slice of the mobile space for the Fame Game app.

Conclusion

Okay, so it's clear Adobe isn't quite there yet with its "Write Once, Run Anywhere" vision but I honestly don't think they're that far off - In my case it was "Write Twice, Run on Lots of Devices".

In the short term it's probably still beneficial to target some of the older handsets that only support ActionScript 2, but as Adobe AIR and Flash Lite 4 roll out across more smartphones AS2 will quickly become irrelevant.

The Flash Platform is an excellent development platform and it's comforting to know that you can use the same tools and language to develop across a wide range of devices. Sure there will always be a need for native apps where performance is critical, but for a vast number of projects out there Flash will be an ideal choice.

So exactly how long did it take me to get the Fame Game running on these devices? After all this has turned into a monster blog entry and that might give the misconception that it took quite some time. Here's a breakdown for you:

As a side-note, I've always been happy with Nokia's commitment to Flash, and I'm looking forward to getting my hands on a Flash Lite 4 device at some point. It's relatively easy to write Flash content, test it in Device Central then deploy it onto one of their handsets.

It's also comforting to know that this also holds true for Flash development on the Google Nexus One (and hopefully other Android devices). From the relatively short amount of time I've had to play with it I can honestly say it's the easiest device yet to get Flash content installed and running on. The performance of Flash on the Nexus One is also seriously impressive.

So there you have it. Approximately four days effort has produced Flash content that can run on millions of handsets. Impressive stuff if you ask me.

And if you made it all the way to the end then thanks for persevering!

Thought I’d share a video I stumbled upon today showing the latest beta build of Flash Player 10.1 running on an Android 2.2 handset. I’m pleased to say that the performance now looks significantly better than the first beta build I got to play with at the Adobe CS5 Road Show in Edinburgh. I guess from the performance gains I’d say that hardware acceleration has now been switched on, which was definitely missing when I tried it out.

From the video it also looks like many of the usability issues have also been ironed out – previously it was very difficulty to switch into full-screen mode but it does seem much more intuitive now. Some Flash heavy sites do still seem to be a problem though. The UFC site at the end of the video seemed quite sluggish and unresponsive as its content loaded, and there were also a few occasions where full-screen video looked a little choppy. Hopefully Adobe can fix these remaining issues.

For the most part however I was once again very impressed and looking forward to a final build of Flash Player 10.1 making it onto handsets.

Update: I’ve just been informed that Flash Player 10.1 for Android went live about a week ago. I’ll need to try and stay in the loop – it’s been a busy past two weeks for me though so at least I have an excuse Thanks to Dave for informing me.

Not content with giving us lucky people Flash Player 10.1, Adobe has also very generously announced the release of AIR 2.0 for Windows, Mac and Linux.

Billed as the most significant update of AIR since its original release, it consists of dozens of new features and hundreds of new APIs for developers to take advantage of. The AIR runtime itself has also been overhauled, which means your AIR apps (including existing ones) will use less CPU and consume 30% less memory.

Over the past two years AIR has evolved into one of the best platforms for giving developers the easiest and most powerful way to develop desktop applications across multiple platforms. Some of AIR 2.0′s new features include:

• Enhanced support for interacting with printers.
• Support for TLS/SSL socket communication.
• Support for the detection of mass storage devices.
• Advanced networking capabilities like secure sockets, UDP support, and the ability to listen on sockets.
• Support for native code integration.
• The ability to open a file with its default application.
• Multi-touch and gesture support.
• New APIs for access to raw microphone data.
• WebKit update with HTML5/CSS3 support.
• Global error handling.
• Improved cross-platform printing.
• Improved security and support for enterprise and government standards.

Those wondering about Adobe’s commitment to mobile will be pleased to know that AIR 2.0 for Android will also be released soon and should over the coming years help phase out Flash Lite, which has traditionally been used for Flash application development on mobile.

Download AIR 2.0 here and if you’re interested you can find a more comprehensive list of new features at the Adobe AIR Team Blog.

Flash Player 10.1 for Windows, Mac and Linux is finally available. It’s so packed full of new features and has had such a significant architectural change that’s it’s hard to believe Adobe hasn’t just labelled it Flash Player 11. And with Flash Player 10.1 for Android scheduled for release later this month it really is quite an exciting time for the Flash community.

So what’s new? Well performance and power management are two huge features that have forced the team to re-architect much of the code base. With the intention to create a single runtime that works across both desktop and mobile, much of the engineering focus was on improving execution speed and reducing resource consumption. The player’s garbage collector has also been tuned to run more efficiently.

With Flash video under the spotlight of late, huge investment has also gone into extending video features and improving performance. Flash Player 10.1 introduces hardware-based H.264 video decoding to deliver smooth, high quality video with minimal overhead across supported operating systems (including Mac). Video delivery options have also been expanded with the addition of HTTP Dynamic Streaming for high-quality full adaptive bit-rate streaming, allowing publishers to leverage the standard HTTP networking infrastructure.

Another huge feature is the inclusion of multi-touch. With Flash Player 10.1 coming to touch-screen mobiles and tablet devices, Adobe has provided ActionScript 3 APIs supporting multi-touch and native gesture events.

Although I have mentioned hardware accelerated video playback for Mac and talked about some of the gains coming to Flash Player 10.1 for Mac in a previous post, it is worth mentioning the extra effort that has gone into the Mac player for this release. First and foremost, Flash Player 10.1 is a fully-fledged Cocoa app, with Carbon legacy support being maintained for browsers that require it. Double-buffered OpenGL support was implemented for improved full screen playback along with rendering performance improvements by using Apple’s Core Animation drawing model. Flash Player 10.1 on Mac will be more CPU efficient and will result in greater battery life on laptops.

So what are you waiting for? Install it now. For a full list of new features pop over to Adobe’s site.

This year’s Google IO event was pretty exciting, especially for those interested in the future of Flash. It has certainly been a long time in the making but Flash Player 10.1 finally made its public appearance on Android 2.2 devices, promising to bring the ‘full web’ to mobile. If that wasn’t enough, Adobe also revealed the availability of the public beta of AIR 2.5, enabling developers to create apps for Android 2.1 devices and above.

But whereas official videos from Adobe (see video above) and Flash Platform evangelists show 10.1 running beautifully on devices such as the Google Nexus One, other sources on the web are quick to show their Android devices nearly chocking to death while playing Flash content. One article in particular from Mobile Crunch entitled ‘Flash kills browsing in Android 2.2 Froyo‘ (see video below) shows a particularly poor user experience while scrolling around pages that contain multiple Flash instances.

The video’s presenter went as far as stating that he felt that the current beta of Flash Player 10.1 wasn’t quite there yet and the sluggish performance was perhaps due to 10.1 still being quite buggy. In fact, he suggested that you uninstall Flash Player 10.1 since in his opinion ‘it’s just not ready yet’ and ‘really slows down page scrolling and page loading’.

So is Flash Player 10.1 for Android really buggy? Are Adobe’s Flash Player engineers just lazy? Is Flash just too slow to ever run well on mobile? Well I believe that the answer to all three questions is no, but I do feel that the issues we are seeing are mostly due to Flash’s phenomenal success over the past decade. It’s the Flash content that users are trying to run that’s more likely to be the problem rather than anything fundamentally wrong with Flash Player.

You see, as Flash developers we’ve had it too good over the years. Be honest, how many of you guys out there ever write Flash content with CPU or memory consumption in mind? Until now we haven’t had to. Desktops have been easily good enough to handle almost anything we’ve thrown at them over the years. Running low on memory just isn’t an issue on a desktop and Flash’s software renderer can run quite comfortably on even a modest PC.

Unfortunately this has led to increasingly bloated Flash content over the years that soaks up system resources without caring about the consequences. Banner ads are perhaps the worst for it. I’m convinced those who create Flash banners have some sort of competition going to see who can consume the most system resources. To make matters worse, sites that serve these banner ads tend to display several of them at once, requiring multiple Flash Player instances, which further impacts performance. If you need proof, just head over to any site that contains Flash banners ads and check the CPU usage. I bet your desktop’s CPU is close to melting.

In the face of the continuing HTML5 v Flash debate this post possibly makes for distressing reading. We’re constantly seeing great HTML5 experiences that run not only on desktop browsers but quite comfortably on mobile too. Does this mean that HTML5 and JavaScript perform better on mobile? To be honest that’s difficult to say for sure and really depends on whose performance metrics you look at.

For Flash to succeed on mobile we need a new mindset from Flash developers. We need to learn to optimise for mobile. To find as many ways as possible to write content that runs just as well on mobile as it does on desktop. Those with Flash Lite experience will already have a head start and I’m sure many Flash Lite developers will tell you that it’s not really that difficult. It just takes a little discipline and some common sense. Experiment and try to keep your display lists as flat as possible.

Trust me it will be worth the effort and your reward will be the additional traffic your site will receive from mobile visitors surfing on their Flash 10.1 enabled handsets. It doesn’t have to start with new content either. Spend time optimising your existing Flash content and if your site also serves Flash banner ads you might want to consider removing or replacing them with static images for mobile visitors. It’ll improve the user experience and ensure that the Flash content you really want the users to see runs without a hitch.

If you’re serious about your user experience and want to increase traffic to your site then get your hands on a few Android 2.2 devices and keep testing your content on them. Going forward there really is no excuse for writing Flash content that performs badly on mobile and continuing to do so would be a disservice to the platform we’ve all grown to love over the years.