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.

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!

Last week saw a series of free live webinars presented by Adobe technology experts showing users how to create RIAs using the Flash platform. If you missed out or simply want to cover the material again then fear not as you can find links to each session below.

• Rapidly build, deploy, and maintain Internet apps with ColdFusion
• Bringing web applications to the desktop with AIR 2
• Code once and run on multiple mobile devices
• Going multiuser with P2P in Flash Player 10.1
• Developing multiuser applications with LiveCycle services
• Connecting a web application to a J2EE back end using Flash Builder 4
• Working with Flash CS5 components in your Flash Builder 4 project
• Erasing the designer-to-developer gap: Adding interactions to your design
• Connecting your design to PHP services

If you found the links above useful then you might want to head over to Adobe Developer Connection where you can find recordings from many other events including Flash Camps to the recently held Adobe Developer Week.

With all the recent hype surrounding HTML5 it’s easy to forget how innovative the Flash platform continues to be. Flash video in particular has taken a bashing of late from the Apple camp and with Adobe so eager to defend video in Flash many seem to have forgotten that Flash can do so much more. If you don’t believe me then take a look at the excellent video below that highlights just a fraction of the great content made possible thanks to the Flash platform.

If that has whetted your appetite then pop over to Michaël Chaize’s blog where you can find links to many of the applications shown above. Some of my favourites include an excellent demonstration of face recognition, an AS3 voice recognition library and a fantastic World Construction Kit that utilises the C++ Box2D physics library, running via Adobe Alchemy.

Flash has been driving innovation on the web for years and will continue to do so.

Just thought I’d share a video of an iPhone app that I considered developing using Flash Professional CS5′s iPhone Packager. Of course I won’t be able to publish it to the App Store due to changes in Apple’s developer agreement but I still thought it would be interested to throw together a very rough prototype and see how it performed.

Well as you can see, even on my trusty old 1st gen iPod touch, I managed to achieve a more than acceptable frame rate using Flash. You can swipe horizontally to swap between a set of vehicles, or scroll vertically to change the skin of the current vehicle.

Okay, it’s hardly rocket science but there have been a lot of rumours going around of late that it’s almost impossible to get a decent frame rate on iPhone using Flash. That’s simply not true, but you do have to remember that you’re developing for a mobile device, which nearly always requires you to make special design and coding considerations.

Good news folks! If you use Flash and live in an alternate reality where Apple and Adobe get along just fine then you’ll probably find this tutorial quite useful. It details how to get the best performance when writing apps with Flash CS5 Professional’s Packager for iPhone.

I suppose for everybody else there’s nothing stopping you using Flash to quickly prototype your apps before committing to Objective C. What’s written in my tutorial will also benefit those wishing to target the Android platform and shows how to take advantage of a device’s GPU to increase animation performance.

Sure glad I only spent 5 minutes putting the tutorial together. It would have been quite irritating if I’d spent a few weeks on it only to find out Steve Jobs had changed the developers license agreement rendering all my hard work useless.

So anyway, here it is:

• Packager for iPhone: Animation Render Performance

So Apple has just changed its developer agreement for those wishing to access the iPhone Developer Program and it could spell the end for Adobe’s iPhone Packager before it has even been released. Here’s the worrying snippet:

3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

With Apple and Adobe not exactly being the best of friends at the moment it is very possible that this is another blatant attempt by Apple to make Flash irrelevant. Unfortunately these new terms and conditions would also have serious implications for the excellent Unity development platform too.

Fingers crossed it’s just a big misunderstanding.

Yup, it’s hard to believe but Adobe AIR is now two years old and it’s incredible just how far it has come in that short space of time. Given the growing debate over Flash’s future within the browser it’s often easy to forget that the Flash platform allows developers to create rich Internet applications that can be deployed to the desktop across multiple operating systems.

AIR now powers a variety of applications used by enterprises and everyday consumers in applications for social networking, gaming, eLearning, subscription-based services, video, productivity tools, collaboration services, and so much more. And thanks to its support for iPhone, which is due to be delivered as part of the Flash Professional CS5 release, 2010 will be a very exciting year indeed for AIR.

If you are in any doubt at all regarding the power of Adobe AIR, take a look at the video above, which demonstrates a collaboration between Adobe and Wired magazine to produce a new digital magazine concept running on an Android-based tablet. It’s quite stunning.

Good news folk! Adobe have announced at Mobile World Congress their plans to bring Adobe AIR to mobile devices, starting with Android and Blackberry handsets. So what does this mean for us Flash developers? Well basically it means we’ll be able to write kick-ass mobile apps and sell them on the Android and Blackberry app stores. Check out the video below to see some content running on the Motorola Droid.

Performance looks really good and should excite Flash developers eager to generate revenue from the mobile ecosystem. Unlike Flash Lite, which is somewhat stunted, AIR apps will run the full Flash 10.1 experience, store data locally on the phone and also allow access to other data including photos. This is another significant step for the Flash platform with developers, in theory, being able to write apps that will run consistently across both web and mobile. Plus with Flash Professional CS5 on the horizon, iPhone apps will also be a possibility.

AIR on Android will be available in the second half of 2010.

Well it is if you believe what Aral Balkan had to say recently. His post sparked some intense and much welcomed debate within the community regarding Adobe’s mobile strategy. In particular both Scott Janousek and Mark Doherty posted excellent responses and I think all three posts are definitely worth a read.

Flash Lite in particular took a bit of a bashing from Aral and it’s something I’d like to talk about here. Firstly I’d like to point out that I agree with many of Aral’s points. I don’t personally know him but he’s highly respected and very influential within the Flash community, and his blog is something I make a point of checking out from time to time.

I’ve been writing Flash-based mobile apps before Macromedia released Flash Lite and although my Flash Lite work these days is restricted to personal projects I’ve been following its evolution since day one, so feel I’m well positioned to comment.

So was Flash Lite a failure? I’d say not. It certainly didn’t achieve what Macromedia and later Adobe had no doubt hoped for it but I feel many great things have and will come from Flash Lite. It demonstrated that Flash is a perfectly acceptable environment to use when developing mobile content reasonably quickly, and in the hands of the right developers/designers, some pretty amazing content can already be written.

The effort gone into optimizing Flash Lite won’t go to waste. Without the hard work from Adobe over the years the Flash 10 player for mobile just wouldn’t be possible. And although the upcoming Flash Lite 4 player will only work as a browser plug-in, I feel that AIR on mobile is essentially the next evolutionary step for standalone Flash Lite application support.

Over the years I’d say I’ve had a love-hate relationship with Flash Lite. There would be days when it would impresses the hell out of me, and then others when I’d be so hacked off by the whole ecosystem that I’d just want to give up with Flash and go native. One thing however is, that over time I’ve come to realise that my frustrations weren’t necessarily with Macromedia/Adobe but with the OEMs they were working with and their inability to strive towards consistency, not only between themselves, but even across their own range of handsets.

Fragmentation was for me the biggest frustration with Flash Lite and the main reason why it never took off in the way that many (myself included) expected and hoped. Again the handset manufacturers didn’t help themselves.

Take Nokia for example. I seriously applaud their efforts and if there was one manufacturer who came closest to getting it all working it was, in my opinion, them. They continually pushed to deploy Flash Lite across their range of handsets, but for all the hard work there was always one bad decision that would scupper things for the Flash Lite developers.

Upgrading the Flash Lite player from FL 2 to FL 3 within firmware updates was a really bad idea. Although it brought many benefits – streaming video within FL3 being one – it further compounded the compatibility issues, with fragmentation suddenly existing across the same device! There was just no guarantee that a large number of users would upgrade their firmware. Up until that point you knew exactly what version of Flash Lite to expect on individual devices. After that it just got harder, more frustrating and quite depressing.

The signing process for S60 devices was always a major issue and something that never really got addressed adequately. It was always too expensive, time consuming and cumbersome, preventing those wishing to release freeware apps (and working to a tight budget) from doing so. It just didn’t really encourage the community to produce great content and get it out there. And it was all the more annoying that you could wrap up Series 40 versions of your Flash Lite content in a nice little NFL file without the need for signing while the exact same content for S60 had to be signed.

I guess ultimately the problem was that the operating systems that were written for mobile devices were never developed with something like Flash in mind. Seamlessly updating the player on the device wasn’t something that could be done easily and unfortunately the distributable player solution came too late in the day.

This may make for depressing reading but I honestly believe there is light at the end of the tunnel. The introduction of the iPhone has been a wake-up call for the rest of the industry and Apple has shown the rest of the world what the mobile experience should be like. While there has been a lot of talk about in-browser Flash support for mobile devices, the success of the app store has shown that there is also a need for standalone applications with web connectivity.

For me standalone Flash application support is probably just as important as browser support for the very simple reason that it’s much easier to tailor the experience for individual handsets that way. A mobile phone is not a desktop PC and  considering the wide range of device configurations and means of interaction you’re never going to get the same experience consistently across all devices. Many existing web based games for example will never work properly on a Flash enabled mobile phone simply because certain devices won’t have a comfortable screen resolution or the game may not translate over to a particular handset’s input mode – A keyboard driven game just won’t work on a touch-only device.

But I don’t think total coverage across all mobile devices is really necessary, and to be honest is impossible. Developers have always targetted the most popular devices and the same will be true for mobile Flash. If Adobe can get it working on a reasonable percentage of popular devices then that should be enough. But one thing they desperately need to avoid this time round is the terrible fragmentation that existed with Flash Lite. When future upgrades to the Flash 10.1 player are ready, there needs to be a way to ensure handset owners can easily, seamlessly and quickly update.

A Flash-based app will never outperform a native app, but as mobile phone’s grow in power this will become less of an issue, and if Adobe can solve the fragmentation problems that have blighted their past attempts then Flash will become a very viable platform for developing content across a wide range of handsets.

Even in its current state, those developing with Flash Lite can target a significant number of handsets, with approximately 700 million having been shipped in 2009 alone. Targeting Flash Lite 2.0, there is nothing stopping a developer releasing games and applications of the highest quality and at the same time taking advantage of the strong development environment provided by Flash and Device Central. If you know what you’re doing you really can create something in Flash Lite in a matter of weeks that runs across millions of devices.

2010 is going to be the make or break year for Flash on mobile. Will Adobe be able to jump the chasm? I certainly hope so.