I really like this Motorola Droid 2 ad that was printed in the Wall Street Journal the other day.

Considering most average users probably haven’t even heard of Flash it’s good to see the platform get a name check.

I found the dig at Apple quite amusing if not a little risky. Apple has such a loyal support that I won’t be surprised if it sparks a whole new round of Flash bashing.

Fingers crossed it doesn’t. Personally however I think the real battle Flash has to win is the tablet space rather than mobile. Many Flash sites just don’t work on such small screens. The larger screen real estate presented by tablets should help alleviate these issues somewhat.

Hopefully you’re all as lazy as me and haven’t actually booked travel and accommodation to Flash Camp Birmingham. Why? We’ll because it has been postponed that’s why.

Flash Camp won’t take place until 24th March 2011 now!!! That’s so far in the future we might all be living on the moon by then.

At least it gives me a bit more time to get organised enough to possibly attend.

If you think I’m making this up then hopefully this link to the Flash Midlands website will prove that I’m not.

A big congratulations to Adobe. Flash Player 10.1 is now available on the Android Market for Android 2.2 devices. Those planning to purchase new handsets such as the Motorola Droid 2 will be pleased to know that Flash Player 10.1 will come pre-installed allowing Flash content to work straight out of the box.

It’s a fairly modest list of devices at the moment with the Google Nexus One, HTC Evo 4G, HTC Desire, and Motorola Droid 2 initially receiving support. But as newer phones come to market and more existing handsets get upgraded to Android 2.2 we should start to see some significant Flash Player penetration.

I’ve had 10.1 installed on my Nexus One for a couple of months now and I’ve enjoyed having access to content that I wouldn’t normally be able to see on my phone.

I have noticed that the player’s performance has been criticised in some quarters and others have highlighted usability issues with existing content as reasons why everyone should ditch Flash/ActionScript for JavaScript.

Personally I believe these issues are mostly with the content rather than the Flash Player itself. I guess that’s always going to be the case when running content that was for the most part designed without mobile in mind and/or developed some time ago using obsolete versions of ActionScript.

The simple fact is there’s a lot of JavaScript heavy content out there that just doesn’t work well, or at all, on mobile either. I spent some time at the weekend trying out various JavaScript and HTML5 demos and found that most of them were completely unusable on my Nexus One (also tested on iPod touch and iPhone 4) due to either performance or usability issues (mostly both). That includes demos from popular HTML5 sites such as Canvas Demos and HTML5 Demos.

I’m certainly not trying to deride JavaScript or the excellent work that’s clearly going on in the community. I’m simply trying to add some perspective. It seems people are quick to criticise Flash when the exact same performance and usability issues on mobile have yet to be addressed by any other language.

I guess there’s so much Flash content out there that it makes it an easy target, but I for one am glad I now have a way of checking-out that content on mobile.

JavaScript and HTML5 will continue to march forward and replace many tasks that Flash was traditionally used for. My fear however is that developers will naively believe that using these technologies will somehow ensure their content will magically work on mobile. People need to realise that the user experience is very different on mobile and need to design with it in mind.

If we don’t then it won’t really matter what programming languages or virtual machines we eventually opt for.

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.

If you missed Flash Camp Manchester then don’t worry. The guys at Flash Midlands have just announced that Flash Camp Birmingham will be held on Tuesday 7th September at Birmingham Library Theatre.

It’s the same deal as before – entry is free and an excellent selection of speakers will be attending including Mark Doherty (Adobe), Seb Lee-Delisle (Plug-in Media), James Whittaker (TweetDeck) and Mike Jones (Adobe). Oh and there will be a prize draw at the end of the day with goodies up for grabs including O’Reilly Books, Flash on the Beach tickets, Adobe Software and SecureSWF Software.

So do yourself a favour and register via this link: http://flashcampbirmingham.eventbrite.com/

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.

Does it look familiar? Of course it does, it’s the HP Windows 7 slate. It was certainly one of the most promising looking tablets on the horizon and I for one was a little upset when it looked like HP had pulled the plug on the project. Thankfully HP has just announced that it will arrive this fall/autumn.

It’s a nice looking device and I’m hopeful that they’ve ironed out the usability and performance issues that we were hearing about from those who got their hands on early preview versions of the device. Best of all is that the HP Slate will support Adobe Flash within the browser. Not sure if it will have AIR support but fingers crossed.

Here’s some more info.

Now what about a WebOS version? Now that would be interesting.

UPDATE: Looks like the slate is no longer a consumer products. Thanks to mnem for sending this link.

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!

here’s an interesting video showcasing the Flash Platform being used to deliver a mobile version of the Photobucket site. Before Flash Player 10.1 for mobile’s arrival the conversion effort to support video on mobile would have taken the Photobucket team several months. However by sticking with the Flash Platform the Photobucket team were mobile ready in a matter of days.

Vice President of Engineering Luke Swanson cited cost savings as a major factor. Using Flash removed the need to transcode and store multiple copies of their existing videos in different formats. It was also interesting to hear Software Engineer, Chris Nguyen describe the process of porting their Flash content to the mobile site as “pretty much plug and play”.

I decided to see what all the fuss was about and took the mobile Photobucket site for a spin on my Google Nexus One using Flash Player 10.1 beta 3. The results were pretty impressive although I still think there are a few usability niggles that need ironed out – scrolling on a page that was mostly consumed by a video was a little tricky.

I’m sure the Photobucket team will be looking forward to Flash Player 10.1 rolling out across more mobile devices in the not so distant future.

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!