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!

I asked in my last post if Adobe’s focus on mobile would limit the features we’d see in future versions of Flash. Well looks like I have an answer via Thibault Imbert’s blog where he teases us all with talk of Flash’s next generation 3D API.

For those wanting to know more, Flash Player engineer Sebastian Marketsmueller will be holding a session at Adobe MAX 2010 where he’ll delve deep into Flash 3D. So just how sophisticated is Flash’s 3D support going to be? Well I guess we’ll need to wait and see but without giving much away Thibault promises that some serious stuff is coming for 3D developers.

You can find a schedule for this years MAX sessions here.

Okay this is a slightly controversial post but it’s something that’s been nagging at me for a good few months now so I thought I’d put it out there and see what people think.

Will Adobe’s mobile vision for Flash restrict future features?

“Why would it?” you might ask. Well the whole point of Flash Player 10.1 for mobile is to deliver the exact same desktop web experience to our mobile devices. Considering the performance gap between desktop and mobile it surely wouldn’t make sense for Adobe to add any new features to Flash that were CPU intensive or memory hungry. Such a strategy would risk producing content that performs poorly on mobile and gives Flash a bad name. Unfortunately the really cool features are often the ones that require fast CPUs and bags of RAM.

Adobe has committed considerable time and effort educating developers about mobile and encouraging them to optimise their existing Flash content – Take a look at the Ads Optimizations and Optimizing Performance for the Flash Platform white papers. It’s clear they’re desperate to ensure that web-based Flash content runs well on mobile and shows Flash in a good light, so I seriously doubt they’ll want to introduce any new features to the player that might cause problems on mobile.

You could argue that Adobe should just keep adding great new features regardless of how well they might run on mobile and leave developers to decide whether or not to use them. The problem with this approach however is that they risk fragmenting the web with great content that runs brilliantly on desktop but poorly on mobile, which is exactly what they’re trying to prevent at the moment.

Sure, as time goes on, mobile devices will get faster and faster but there is always going to be a gulf between the power of mobile handsets and desktops. My guess, and my hope is that Adobe let their mobile strategy dictate, to a certain extent, the future of Flash and the features that we’ll see in upcoming releases.

In the short term I think it’s very important we start to see some performance parity between mobile and desktop Flash content. Much of it is down to the developers producing the content but I think Adobe can help by ensuring that any new features aren’t likely to melt our mobile phones.

There’s a really interesting post over on the YouTube API Blog from Google’s YouTube team explaining their reasons for using the Flash Platform to deliver video.

The article discusses the advantages Flash currently has over the HTML5 <video> tag including:

• A Standardised Video Format
• Robust Video Streaming
• Content Protection
• Encapsulation & Embedding of Video
• Fullscreen Support
• Camera and Microphone access

It’s definitely worth your while reading through the article and I’ll leave you with this quote, which I think sums things up nicely.

Today, Adobe Flash provides the best platform for YouTube’s video distribution requirements, which is why our primary video player is built with it.

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.

I keep hearing from friends and colleagues that Flash is notoriously slow and the content it produces is hopelessly bloated. Of course this simply isn’t true but recently I’ve been finding out the hard way that it’s not easy to convince many of them otherwise.

Now I’m not attempting to turn this into a Flash v HTML5 debate but I do believe that some of these misconceptions have been borne out from the war that has erupted between those who support Flash and those who want it gone. However I feel most of the blame lies with those who use Flash and I do confess to being as guilty as the next man when it comes to writing large SWFs that use poor loading strategies.

It is all too easy to create unnecessarily large SWFs by producing hopelessly large vector images, packing your SWF with high-quality bitmaps, and forcing all your code and resources to load up-front. Ignore everything that’s great about Flash and you’ll soon have users yawning as they wait for the entire SWF to download before they’re able to try out your latest masterpiece.

So in an attempt to re-educate many of the non-Flash developers at WeeWorld I set myself the task of ensuring that any Flash content produced for our latest project would be as small as possible without a loss of perceived quality.

But first we had to decide if Flash was required at all. From the initial mock-ups it was clear that HTML, JavaScript and some server-side cleverness would take care of the majority. There was however one section right in the centre of the page that was screaming out to be done in Flash (or at least that’s what I believed).

Hey! I want to be Flash!!!

The centre panel in the mock-up above represents a little voting game where users get to vote for their favourite WeeMees during a fashion contest. Each time the user votes a new WeeMee is loaded from the server and slides into view. After voting, a panel is updated showing the current voting statistics for that WeeMee. To ensure the voting experience was as fluid as possible we decided to cache WeeMee SWFs up-front to reduce loading time between votes.

First I had to justify it. After all, some team members quite rightly stated that it could probably be done in JavaScript. In the end though we went with Flash for the following reasons.

• We’d need to load WeeMees, which are all dynamically generated on our server as SWFs.
• Flash would give us good cross-browser support without the need for any browser-specific code.
• The visuals could easily be reproduced using Flash’s vector drawing tools.
• The vector content would be a fraction of the size of bitmaps.
• ActionScript is compiled into a compact byte-code without sacrificing the legibility of the source.
• I moaned at my boss MacDog for two weeks straight until he relented.

So how did I get on? Well in the end I split the project into two SWFs – a preloader SWF and the main SWF. The preloader came in at 4K with the other being around 12K. The combined total was a minuscule 16K! To be honest given the tiny file size it was perhaps overkill having a preloader but heh, I’d rather the user had to wait for 4K to download before seeing something rather than 12K.

The point of the preloader wasn’t to actually feedback to the user how much of the content had loaded – after all everything loaded too quickly for there to be such a need. Instead it was created to force a visual onto the screen as quickly as possible therefore giving the user the perception that the content had loaded. I was eager to, as quickly as possible, plug the hole in the HTML page where the Flash content would be rendered, and the preloader gave me that opportunity.

High level breakdown of SWFs.

The diagram above shows roughly how each SWF looks and more importantly a high-level breakdown of sizes. The preloader’s (left hand-side) content is more-or-less split 50-50 by code and embedded fonts. The final size of the graphics within the preloader was perhaps the most pleasing, with the vector content only consuming 185 bytes!

It was a similar story with the main SWF (right hand-side). The ActionScript consumed the majority of the file size while the graphics consumed next to nothing. This time the vector artwork was a little larger but still comfortably under a kilobyte, coming in at 479 bytes. Unlike the preloader I was able to use device fonts for the main SWF, further helping to reduce the final SWF size.

I could quite easily reduce the total SWF size further by spending time shortening function and variable names. There are of course many other ways to squeeze the code down but I was eager to keep it as legible and maintainable as possible. The total size of the ActionScript source across both SWFs was 41K but was reduced to 13K after compilation.

I’m happy with the result along with everyone else at WeeWorld. Many were pleasantly surprised at the final SWF sizes and hopefully it has gone a long way towards making individuals realise that there’s absolutely nothing wrong with the Flash Player or the SWF format.

If you want to keep file sizes down I’d suggest you spend as much time and effort optimising your vector content – it’s certainly where the majority of savings were made on this project. Where possible re-use content by storing your artwork in movie clips and using instances of those clips. In fact take a look at the diagram below for a more in-depth breakdown of the vector graphics used within the SWFs.

Size breakdown across SWFs.

Also spend time thinking about your font usage. Only embed fonts if you really must. Where possible use device fonts, which will help reduce significantly the final size of your SWF. And although it wasn’t an issue with this project, if you find your byte-code size getting out of hand then you many want to split your code into separate libraries and load them at run-time when needed.

If you’re still in any doubt as to the compactness of the SWF format then perhaps this might give you some context. I examined the size of a single JPEG (260 x 274 pixels) loaded onto the front page of the WeeWorld site. It was a fairly compact 31K in size. Now compare that to the 16K total of our two SWF files (360 x 459 pixels). That’s right, our fully interactive Flash content with graphics, fonts and animation was half the size of a JPEG!

Anyone still want to argue that Flash can’t produce compact content?