Adobe’s Mobile Strategy: Responses to Aral Balkan

Aral, a well respected member of the Flash community recently posted an interesting article to discuss our mobile and devices strategy.  It’s really great to see community members thinking about our approach, and yes, even criticism is welcome.  So here I’ll try and address Aral’s points and demonstrate why we have the right approach in the immediate term.

Hopefully we can put a few minds at rest :-)

Adobe’s current mobile strategy is very similar today to what it always was: get the Flash Player on as many handsets as possible. Let’s qualify that statement, however, with some all-important details, starting with differentiating the two types of Flash support that Adobe wants to implement on devices:

  • In-browser Flash support (plugin)
  • Standalone Flash application support

Markd: It is absolutely true that our intention, working with our Open Screen Project partners, is to enable the Flash Platform to extend from the desktop and web to devices.  This includes everything from desktop PCs, netbooks/Mids, smartphones and ultimately to the Digital Home.  We believe that by ensuring the availability of a highly optimized and consistent platform that we can enable the creation, and continuation of innovation across all screens.

Some time ago we agreed with our partners that the browser and standalone use-cases were key in this strategy.  Our partners see demand for these, in part because of competition from the iPhone OS and of course to help with their applications strategy.  The Flash community is one of the largest, and obviously most creative group of professionals creating rich user experiences.

For those reasons, among others, we believe that this will result in an uplift for the community and ultimately more business for all of us (we sell tools and services remember).

In-browser Flash support is good*

Getting in-browser Flash support on devices is a logical and understandable goal and Adobe is right to devote as much effort as possible into making that happen. In-browser Flash support on mobile devices means that your mobile phone can render today’s web (which, like it or not, contains heaps of Flash content) faithfully and thus provide a similar experience to what is possible on the desktop.

* That said, given that Flash content is notorious for its high CPU (and thus power) usage, and given that a lot of Flash content on the web today is undesirable from the perspective of the end user (ads, intros, etc.), it would make sense for such in-browser implementations of Flash to voluntarily default to a Flash Block behavior (i.e., have Flash disabled by default with the option to activate Flash content if and when the user wants to.)

Markd: We definitely see a huge value in ensuring that web experiences are made available on devices.  With Flash Lite we spent a huge amount of time and effort in optimization, battery performance and developer workflow (Device Central).  By integrating our engineering teams we added all of that experience to the new Flash Player 10.1 and then some, the proof will land early next year.  That said, you will still have to understand how the Flash renderer works and create experiences that are suitable for devices.  That is true of all development platforms without exception.

I don’t think that blocking Flash as a default option is very important for the vast majority of users.  Many simply want a complete web experience, and while in theory browsing could slow down we have invested alot of energy into startup/shutdown/instance management performance.  Feel free to pass judgement when you’ve actually seen it in action.

The remainder of this post will deal with Adobe’s attempts to get Standalone Flash application support in mobile devices.

Flash Lite: stillborn

Adobe’s initial mobile strategy, dating back to 2005, revolved around getting a cut-down version of the Flash player called Flash Lite on as many handsets as possible.

According to Adobe the number of Flash Lite devices shipped should have reached 1 billion in 2009. While that seems like a huge number, it’s rather irrelevant. For one thing, there is more than one version of Flash Lite so that 1 billion number includes outdated players. Also, that number hides further segmentation in that it includes both devices that support only in-browser Flash content as well as those that support standalone Flash applications. Finally, and most importantly, Adobe failed at making it possible for developers to monetize Flash content and failed to provide compelling reasons for developers to create Flash content for Flash Lite.

Why did Flash Lite fail? Because it went for a lowest-common-denominator approach, trying to support as many devices as possible, instead of focussing on creating a great user experience on one device and expanding from there. In other words, it failed because the focus was on features (in this case: wide-range of device support) instead of user experience.

Markd: Today we have shipped over 1.2Bn devices with optimized Flash Players, but do not ignore that ~700m of these were shipped in the last year.  To call them outdated negates the fact that regional segmentation, and in some cases carrier control, has enabled highly consistent distribution in key markets.

In some cases platform restrictions have limited the availability of standalone or browser plugin support.  This opinion is quite real, sometimes unfortunate, but ultimately based on an out-dated principle that content must run on every device at all costs.  At times I’ve heard this same error crop up from those building iPhone applications, who mistakenly believe that everyone has an iPhone (even when there are 3 devices and 5 OS versions).

I have to disagree completely with the principle that it is Adobe’s role to create an entire ecosystem.  It is not the role of a tools vendor to build businesses to buy their tools, that is of course completely impossible.  In the two years that I have been working on this ecosystem we have seen applications distributed to millions of users, millions of dollars have been made during my time.

One simple game made $2m USD last year alone in one country, and it took 2 weeks to create.  Services have been created in Europe (eg Playyoo) with various successes in the US also, some developers reaching over the $1m USD mark in under a year.  Is that successful?  In fact “sometimes” it is, in reality it depends on your expectations.

The problem is not that we failed to provide monetization, that we don’t have an AppStore or that we reached too many devices.  Flash Lite provided an incredible foothold and allowed us to build a new opportunity in a highly complex ecosystem.  That ecosystem is global and while we didn’t see many signs of “success” here in Europe, in other parts of the world like USA and Japan we did.

I’m unsure how wide and global device support could have affected user experiences, although I’m sure that companies like LG, Samsung and Sony Ericsson would disagree entirely having sold hundreds of millions of devices using Flash as the user interface engine.

Open Screen Project: same old, same old

You would think that Adobe would learn from its failure with Flash Lite that getting your technology on a huge number of devices isn’t worth the effort if no one wants to use it. Unfortunately, their strategy hasn’t changed with the introduction of the Open Screen Project.

The Open Screen Project aims to remove the fragmentation created by Flash Lite and ultimately aims to have a single Flash Player (the latest one) run on every device on the planet (cue: hysterical world-domination laughter). It seems that Adobe has learned nothing from the recent failures plaguing another company with a similar strategy for its operating system: Microsoft.

Where Microsoft struggles to provide at least a mediocre user experience across the countless hardware combinations that it must support, Apple runs circles around it: Having limited itself to a handful of hardware configurations – all, furthermore, within its control – Apple can provide its users with an exemplary user experience. Apple can do this because it wisely chose to control both the hardware and the software, limit segmentation, and focus on the user experience instead of expanding effort in a fruitless quest to run on any given hardware configuration on the planet.

Adobe’s Open Screen Project is a Microsoft-style, Age of Features strategy that aims to get Flash running on every mobile handset on the planet, user experience be damned. The question is: who cares if you can run the same crappy experience on every handset?

Markd: If Aral had come to see my session at Flash on the Beach then he would have heard my talk on “Relevant Reach”.  The principle is quite simple, the world of devices is complex, but largely follows an 80/20 rule for distribution.  In the EMEA5 countries 80% of users can be reached targeting only 20% (285) of mobile devices.  So in reality the wide reach is to ensure that as a developer, or content provider, you can reach the mass audience for a given market.

The Open Screen Project is an initiative that includes the worlds leading OEMs, even the ones that you’ve never heard of.  The achievements made this year are simply unheard of in the ecosystem, and there are more announcements coming of course.  It is however a slow-burner when you look at it from the outside, but if you look at what’s changing, the consistency, updated runtimes, hardware optimizations, chipset alterations.  All of these things are indicative of a massive effort to realise the full potential of Flash on devices, they are not a fruitless effort to scale, but a global strategy from the key players in the devices industry.

The argument “same crappy experience” is a pretty bold opinion and one that assumes alot about the expectations (and capabilities) of many in the Flash community.  We could all argue the value in targeting a single platform, and internally we considered this of course.  Ultimately however, the world is bigger than the device in “your” pocket (whatever that may be), and while Adobe is US company we must consider a global audience and customer base, something that many forget.

Flawed to the core

Adobe’s Open Screen Project and its mobile efforts will fail for one simple reason: they are not competitive when it comes to user experience. A Flash application running on a device will never have the same performance or the range of hardware support as a native application. It will never be able to compete with a native app in terms of user experience. Whereas Adobe’s plugin strategy worked on the web, it has and will continue fail on mobile devices.

(See this post for a more detailed discussion of Write Once, Run Anywhere and how it differs from Write Once, Compile Anywhere.)

Markd: This argument is totally subjective and based in principle on an understanding that Flash should be perfect at everything.  Flash Player 10.1 includes a new JIT technology to speed up the execution of Flash on devices, we use the power of new GPUs and hardware decoders for video and audio.  It is true, at times native code or feature access will be required, that has always been true on any platform.

Our goal is not to run desktop applications on mobile devices, and nor should it be yours.  The Flash Platform is designed to enable content production that *can* be optimized for any device or screen.  If you create an iPhone app then the same piece of content compiled with Flash Professional CS5 will also run on Android, Blackberry and Symbian.  That said, you will still need to invest time and effort to make the user experience compliant with the users expectations.

The user experience is reliant on the capabilities of the developer, the device, and the amount of money spent to achieve relevant reach.  Nothing in this business model is new, not even for the desktop developer.

So what should Adobe be doing instead?

In its scuffles with Apple to get Flash on the iPhone, Adobe has already stumbled onto the strategy that it should be following for mobile devices: focus on tooling and Just-In-Time (JIT) compilation to native applications.

In the upcoming CS5 Suite, you will be able to use Flash CS5 to create native iPhone applications. In other words, Flash developers will be able to reuse their existing skills to build native applications for the iPhone. Native applications that will be optimized for the iPhone and, hopefully, indistinguishable in terms of device-specific support and performance from native applications compiled using Apple’s own tools.

This should have been an a-ha moment for Adobe. And I did hope that it would usher in a new era of focus on Adobe’s core business (tooling). Unfortunately, that doesn’t seem to be case, if this short Twitter conversation with Ted is any indication:

I respect Ted greatly but what he (and Adobe) are missing here is that FPS (the frame rate an application can achieve) is just one tiny variable that affects the user experience of applications on mobile devices. How well are native features like location, multi-touch, local storage, etc., supported? A virtual machine is always going to be a couple of steps behind native applications in terms of device-specific support. It’s a losing game. The focus is wrong.

The majority of Adobe’s revenue comes from sales of its Creative Suite products. As such, it should be keeping its eye on the ball and adding value to the CS products as much as it can by making them the premiere toolset for creating mobile content. Getting Flash application support on handsets is not a requirement for this. Instead, Adobe should drop the huge amount of time, effort, and money that it is currently expanding on this and instead focus on enabling Flash developers to make native applications for the top mobile handsets.

Adobe’s next move should be to support native application creation on Android phones like the HTC Hero and Motorola Droid and maybe even adding support to Dreamweaver for building native Palm WebOS applications.

Markd: Aral’s point here is correct, FPS is not a deciding factor on the success of any platform.  When you put Ted’s comments back in context he is merely addressing a concern that iPhone applications packaged with Flash Pro CS5 will be slower than native applications.  This is absolutely true, even with huge efforts it will always be possible to create faster applications using native code.  Again, this is true of all platforms and you have to weigh up your skills and requirements.  Is it going to be easier to port your Obj-C game to Android than a highly optimized Flash game?  NO.

The core of Adobe’s business is indeed to sell tools, but those tools are successful because of the consistent and expressive platform that they support.  Creating a multitude of wildly varying toolchains and workflows for multiple platforms is not only expensive, but a red carpet for fragmentation.

We will not see another cross-compiler/Packager for other platforms, it simply isn’t required where Flash Player 10.1 and it’s nano-JIT are available.

As with most platforms the mobile space is changing all the time, for this reason we build frameworks and today that’s called FLEX.  In the future you can expect to see a more rational development workflow for mobile and devices, that not only uses Flex, but shapes it into a more optimized and expressive product in time.

What can you build with Flash on Mobile Devices?

Dale has done a stunning job of rounding up the possibilities for Flash applications and content on devices.  In summary he covers the Standalone, Browser and Personalization use cases providing examples of various applications.  Rather embarrassingly I think I’ve only seen about 30% of these, so hopefully you’ll be able to get inspired by some of this great work..

Here are some samples.. and note the ridiculous hassle to build a video like this. You can see the video series here.

Screen shot 2009-09-30 at 18.51.13Screen shot 2009-09-30 at 18.51.39Screen shot 2009-09-30 at 18.52.13Screen shot 2009-09-30 at 18.52.58

Flash Development with Android SDK 1.5 Part 2

As we already know by now the HTC Hero supports Flash in the browser, and by double tapping on Flash content it will be played in full screen mode.  In fact I believe that’s also the reason why we cannot use the Flash Player directly with Intents.

Those of you familiar with Nokia’s WebRuntime or the iPhone UIWebView will recognize WebView, because it’s the same thing.  Really it’s an implementation of the browser framework made available as a UI component.  Some of these implementations come with hooks into the platform code through JScript, and enable the use of device APIs like Location.

So what can we do with the Android browser?  Let’s look at the pieces provided by Android:

  • WebView – Used to load and display web pages using the built-in device browser and chrome, embedded into your application.
  • WebViewClient – Enables the handling of various browser actions like page loading and error handling.  Overrides the Activity in the built in browser.
  • WebChromeClient – Enables the replacement of the browser chrome for events like progress, alerts and for window controls.  Can override the default Chrome.

Step 1: Launch the built-in browser using WebView

The code to do this couldn’t be simpler, but there are a few extra changes to make with the layout declarative XML and with the AndroidManifest.xml.  Android supports the ability to lay out the application using standard components, much like Flex.

To add a WebView to our layout we must add the WebView node to the main.xml (in project/assets/layout).  You can see the id property of the node looking rather special, and that’s because it’s indicating a binding.. again, just like Flex.  We can use this resource, and any others later in our code using the builtin R class.

Picture 10Now we’ve done that we have to add a new permission to the Android Manifest.xml.  You’ll notice that the XML includes a number of nodes pertaining to my application, most of it is easy to understand.  Note also that my application has it’s own Intent and an Activity called StubApp.

Picture 12With that we only need to add a tiny piece of code to use the webview component, check it out.

Picture 9As before we overload the onCreate method, call the parent for good measure and then get to business.  We call setContentView to build the WebView using our layout XML file above and then get a reference to this view, set JScript to enabled and load a URL.  It really couldn’t be simpler and as before this runs on the device, however there are issues.

Clicking links in WebView above causes the loss of client control over the page.  The result is that Flash works, but we cannot control the user experience.

The next step was to attempt to bring the control over loading new pages within the webview instance.  To do this we need to extend the WebViewClient class and override the shouldOverrideUrlLoading method, this gives us the opportunity to load the page ourselves; before the browser gets to it.

It looks like this and note that return true after view.loadUrl(url) means don’t bubble this event to other web views:

Picture 13The result of this is work is that we can simply replace the currently loaded page without launching a new activity, but it comes with a penalty.  As when I implemented the custom WebViewClient it became clear that the Flash plugin was not being loaded.  Worse still, there’s no way to load it (despite APIs to the contrary) and that’s by design at this time.

So there you have it, the investigation into creating a Flash Application that lives in the browser can only succeed when using the native browser.  The Android Platform allows for the creation of custom browser clients and chrome, but the penalty for this is that you loose access to plugins.

Hopefully this has been an informative post, and maybe inspired you to have a look at Android with Flash Player support.  Maybe you can extend my examples, or by all means provide some secret code that can help us start up the plugins :-)

Flash Development with Android SDK 1.5

Following on from my previous post below I have also been playing around with the Android SDK, and specifically with the Flash Player on the Hero.  It has been sometime since I did any programming, but some of you may know that I come from an engineering background.  So below I’m going to go over the different tools and technologies that I encountered during these two days.

Be warned, there’s code and geek talk below :-)

Step 1:  Get the SDK and tools

The Hero runs Android 1.5 with a custom UI from HTC called “Sense”.  With 1.5 comes a number of additional features like on-screen keyboards and Android Widgets.  All I needed to do was download the SDK for Eclipse, the same development environment we use for Flash Builder, or Carbide for Symbian C++.  The Android toolchain is a real dream and it runs across Mac, Windows and Linux with feature parity.

If you have Eclipse/FlashBuilder or Carbide installed then you’re good to go.  Just install the ADT plugin using software update, unzip the SDK into a relevant folder and point to it like this.

Picture 2


Step 2: Create the HelloWorld app

It used to be that you had to actually type something to create your HelloWorld app, with Android there’s no need :-(   Using the File->New Project menu you create an Android Project, and setup the app name, package name and the name of your Activity; then click finish.

Picture 1

You’ll end up with a typical application created in the Package Explorer, and if you look in the source folder you find the generated .java files.  Remember that Android uses the Java language, but it’s own APIs, and so it’s familiar to look at.

Notice that my application extends Activity, part of the Android application package.  An Activity is generally considered an interactive component, like a screen or dialog.  For our purposes we can thinking of it like a MovieClip or UIComponent if your a Flex person.  In this auto-generated code we have simply overridden the onCreate method as this is the first function to be called.  There’s also an onStart method and that should be used if you want to be formal.

Picture 3Picture 4

From here I can simply run the emulator, but just for fun I decided to plugin my HTC Hero, go for bust I say!  The great news is that devices are auto-detected by the ADT plugin in Eclipse as shown above.  From here I can run or debug my application using the normal IDE buttons, and also with the SDK comes a nice tool to capture screenshots from the device while connected to the ADT plugin.

Picture 5

Step 3: Launch Flash Player Standalone

This is where things get more complex, simply because I don’t know exactly how the player was implemented for Android.  Android uses pretty standard methodology for application development, and so I can presume that the implementation followed the rules.  So what are the fundamental rules?

  • Activity – Is a UI component that presents itself to the user for interaction
  • Service – A background process that carries out a task for other components such as pulling emails and calendar synchronization.
  • Broadcast Receiver – A component that listens and does something in response to broadcasts.  Widgets are great examples of broadcast receivers.
  • Content ProviderA useful way of wrapping access to content, images, audio files or even data base access.

Activities, Services and Broadcast Receivers are all started by and registered to receive messages from the platform called Intents.  An Intent is a simple message object with a simple Action string and it’s also possible to send data, or call a specific component to handle the message.

So with a spot of “playing” around with a decompiler I was able to find two potential Intents.

1.  To launch the FilePicker with SWF/FLV files detected automatically.

Picture 6

This works pretty well, though seems restricted to landscape mode.

2.  To launch the player Activity ( directly passing a SWF file to play.

Picture 7

It’s possible to launch the Activity using this method but the file provided in “putExtra” doesn’t actually load.  So while this would be the best solution it appears like it’s designed not to work in this way.

So in summary, the only valid path for standalone apps (as far as I can tell) is to load the FilePicker.  This method is pretty good for on device testing, maybe you want to see what your mobile web site looks like and need to tailor the flash content to fit the screen.

Next we’ll look at the browser solution…

Flash Player to take over “Mobile” gaming?

I just saw an interesting post over on Twitter that talks about how Flash will take over the mobile gaming space.  Paolo Munoz suggests that with our current position for gaming on the web, that Flash on devices should become a natural progression for the platform.

There are some interesting points, some of which are good like the Facebook applications/games strategy.  Yet some points are assumptions and not well understood, and so that’s something that I’ll explain here.  This post is not meant as a criticism in any way of Paolo, but more an exploration of the fact/fiction.

Flash on Smartphones

While the delivery of Flash Player 10 to (high end) smartphones will undoubtedly be a great boon for those working with AS3, but it’s not a panacea for development.  You will absolutely have to purchase hardware for the last mile of development, you will have to deal with new interaction paradigms, and you will be working within performance limits.

Device support will initially be very limited, maybe two or three devices and running only in the browser.  Flash Lite 3 will continue to be the mainstay on shipping devices for around 1 year from my own projections.  The Open Screen Project however enables us to drive the adoption of the latest player, where possible, within a much shorter period of time.

We’ll see betas later in the year by leading OEMs, but it is unlikely that these will be for consumers, it’s a bit of an unknown.

Flash and GPUs

In this section Paolo picks out the fact that performance has always been a key concern for the community.  That’s exactly why Flash Lite has a different memory management model and rendering capabilities, it’s a demonstration of just how different things are on mobile and devices.

In the past year we’ve seen devices with extremely high resolution screens, high end processors to drive them, huge amounts of memory and OpenGL ES/OpenVG hardware.  They are very expensive and typically available in major markets in low/medium volume.  It’s not a huge issue in reality, but to reach users you’ll need to get smart on your targets and markets.

Ok so the use of hardware acceleration for Flash Player is first and foremost to gain “acceptable performance” in line with Flash Lite’s capabilities on these devices.  We’ll be doing our best to ensure that everything is available, but everyone must understand that some devices will just not be capable.

Filters and other high requirement features may not be supported in hardware, in fact the hardware may not be there :-)   In these situations there will be a fallback, but you’ll need to get smart on what they are, how they work, and what to do about it just in case.

We’ll be here to help obviously but to bang the drum again, get working with Flash Lite now to understand the complexities.

Adobe Wave on Labs

Picture 3

While this step in the release is for desktop computers using Adobe AIR, you can easily imagine this running on mobile devices or in the Digital Home. In fact the team behind Wave were responsible for the Flash Cast and Adobe® Mobile Server, and published the open Mobile Content Delivery Protocol from the latter product.

Wave is of course not Flash Cast, but it has really nice similarities such as the ability to automatically get content and notifications from your favourite sites and brands. You can register for notifications using the beautiful interface from our Experience Design team, then simply setup the application with what you’re interested in.

Picture 5

Once added you can configure the notifier application with your settings. This could be your myspace profile or simply that you’re only interested in technology news from digg.

Of course we intend to grow the number of Publishers, and in fact you too can become a publisher if you have a popular blog or website.  There’s a rather bizarre video here, sounds like the Star Trek computer and advertises Bruno :-)

Developing with Flash Lite Tutorial Series

Picture 5

Dale Rankine is one of the foremost experts in Adobe Flash technology for devices and owner of a successful mobile development company, Moket Pty.  As a certified training partner and long standing community evangelist, I’ve asked him to help produce a video tutorial series on Flash Lite technology.  Our goal is to help new and existing developers to work with our optimized Flash player for mobile phones and devices.

From the series I expect that viewers will learn how to use Adobe Device Central, discover how to construct a mobile interface and to work with multimedia including FLV.  We’ve tried to build out a set of topics that we get most questions on, things like video optimization, performance and the ‘basics’ such as object orientated programming and memory management.  The focus will remain on Flash Lite 3.x, although many of the APIs and features work everywhere.Picture 1

The great news is that Dale has already begun publishing the videos over at our Vimeo channel, and soon we’ll push these up to Adobe TV too.  We might be able to take a couple of requests, so if you get asked the same question over and over again, then let’s hear about it!

Remember also to spread the word, embed the videos in your own blogs and drive the viewers to new content with the following banner…

  • URL:
  • RSS:
  • Twitter: flashmobile

Adobe MAX 2009 Awards


It’s almost that time again for the Adobe MAX Awards and we’re already taking submissions and your suggestions for the winners this year.  As always there will be a mobile category and you can click on the button above to make your suggestion.

Mobile service providers today are challenged to deliver easy-to-use applications that provide expressive and complex capabilities. Tapping into features such as location, touch and motion detection, high-speed networks and others, service providers are looking to appeal to increasingly sophisticated customers who rely on their devices to access and share information, participate in social networks, be entertained, and for work. Winning entries in this category will demonstrate how Adobe solutions are being used to raise the standard of interactivity and quality for mobile services, bringing indispensible new services that improve the daily lives of consumers.

Category- Specific Judging Criterion: Value delivered by mobile device application to corporations or individual users.

Distributable Player Expansion – 45 Countries

This application is created by interactive maps. You can also have your visited countries map on your site. If you see this message, you need to upgrade your flash player.

// <![CDATA[
var so = new SWFObject("", "visitedcountries", 650, 400, "7", "#000000");
addLocation('ZA', '', '', ''); //South Africa
addLocation('CN', '', '', ''); //China
addLocation('IN', '', '', ''); //India
addLocation('ID', '', '', ''); //Indonesia
addLocation('JP', '', '', ''); //Japan
addLocation('PH', '', '', ''); //Philippines
addLocation('SG', '', '', ''); //Singapore
addLocation('KR', '', '', ''); //South Korea
addLocation('TW', '', '', ''); //Taiwan
addLocation('AU', '', '', ''); //Australia
addLocation('AT', '', '', ''); //Austria
addLocation('BE', '', '', ''); //Belgium
addLocation('DK', '', '', ''); //Denmark
addLocation('FI', '', '', ''); //Finland
addLocation('FR', '', '', ''); //France
addLocation('DE', '', '', ''); //Germany
addLocation('GR', '', '', ''); //Greece
addLocation('IE', '', '', ''); //Ireland
addLocation('IT', '', '', ''); //Italy
addLocation('NL', '', '', ''); //Netherlands
addLocation('PT', '', '', ''); //Portugal
addLocation('RU', '', '', ''); //Russia
addLocation('ES', '', '', ''); //Spain
addLocation('SE', '', '', ''); //Sweden
addLocation('CH', '', '', ''); //Switzerland
addLocation('UK', '', '', ''); //United Kingdom
addLocation('TR', '', '', ''); //Turkey
addLocation('CA', '', '', ''); //Canada
addLocation('US', '', '', ''); //United States
addLocation('BR', '', '', ''); //Brazil
addLocation('MY', '', '', ''); //Malaysia
addLocation('CR', '', '', ''); //Costa Rica
addLocation('PA', '', '', ''); //Panama
addLocation('CZ', '', '', ''); //Czech republic
addLocation('NO', '', '', ''); //Norway
addLocation('PL', '', '', ''); //Poland
addLocation('RO', '', '', ''); //Romania
addLocation('IL', '', '', ''); //Israel
addLocation('KW', '', '', ''); //Kuwait
addLocation('SA', '', '', ''); //Saudi Arabia
addLocation('AE', '', '', ''); //United Arab Emirates
addLocation('MX', '', '', ''); //Mexico
addLocation('AR', '', '', ''); //Argentina
addLocation('CO', '', '', ''); //Colombia
addLocation('PE', '', '', ''); //Peru
so.addVariable("stageWidth", 650);
so.addVariable("stageHeight", 450);
so.addVariable("infoOver", "enabled");
so.addVariable("zoomFunction", "checked");
so.addVariable("bgColor", "666666");
so.addVariable("visitedColor", "5EB7DE");
so.addVariable("notVisitedColor", "CDCDCD");
so.addVariable("countryBordersColor", "666666");
so.addVariable("helpTextColor", "000000");
so.addVariable("helpText", "");
so.addParam("scale", "noscale");
so.addParam("salign", "lt");
// ]]>

I’m happy to announce the further expansion of the Distributable Player to a further 15 countries bringing the total to 45 across the world. With the Distributable Player it’s possible to distribute your applications with the latest Flash player optimized for mobile devices, Flash Lite 3.1. This is the same player available on the HTC Hero and Nokia 5800 devices.

The countries are: Argentina, Australia, Austria, Belgium, Brazil, Canada, China, Columbia, Costa Rica, Czech Republic, Denmark, Finland, France, Germany, Greece, Hong Kong, India, Indonesia, Ireland, Israel, Italy, Japan, Kuwait, Malaysia, Mexico, Netherlands, Norway, Panama, Peru, Philippines, Poland, Portugal, Romania, Russia, Saudi Arabia, Singapore, South Africa, South Korea, Spain, Sweden, Switzerland, Taiwan, Turkey, UK, United Arab Emirates, USA.

Using the Adobe Mobile Packager 1.1 you can package your SWF files and assets in native installer packages, then distribute them freely from your website or that of your customer. We’ve made it extremely easy to get started and begin to work with mobile devices in advance of Flash Player 10 availability. If you’re interested in developing for Flash Player 10 when it arrives I recommend that you get your feet wet with Flash Lite to build up your knowledge of mobile and devices interaction and optimizations.

You can see some great examples of Flash applications running on mobile devices from the Flash Lite Developer Challenge below!