CES 2010 in Las Vegas saw a very interesting device launch from UK based Light Blue Optics.  The great news is that they’ve received really positive press and comments from users that are eager to get their hands on the Light Touch.

So what is it?  Effectively it’s a projector for rich media, but it’s laser based which gives it the ability to project onto different surfaces while maintaining a sharp focus and bright colours.  LBO used the Flash Platform to provide a rich user interface engine for applications, games, photos and even H.264 video playback.  The device is also multi-touch enabled using infra-red, but employs an invisible grid projection onto the surface, which enables much more accurate and speedy response times.

As a user you can envisage a huge array of different use cases, maybe your calendar projected onto your desk, or video playing on your bedroom wall.  We saw a huge array of 3D TVs, ever larger, thinner and brighter televisions this year at CES.  Could the future require no screen at all?

Just think of the options for this kind of device in the auto-industry, gaming and entertainment.  The great news is that the device spec’s make it capable of running Flash Player 10.1 in the future, reaping the benefits of our consistent Open Screen Project runtime for all platforms.

Specs:

• Adobe Flash Lite 3.1 on WinCE 5
• ARM11 CPU @ 600Mhz
• 10-inch touchscreen with WVGA resolution
• Laser based pico projection
• Infrared multi-touch detection
• WiFi and Bluetooth radios
• 2GB of on-board storage (+ microSD)

Check it out in action:

Some great news on the mobile packager, we finally passed the 100,000 users mark yesterday as shown here on the magic “Dashboard”.  This is really good news and shows that we’ve managed to reach to more developers than ever with the tool.

Interestingly enough I’m also seeing recently spikes for the Flash Lite downloads too, which would indicate that applications are finally reaching users

Note:  The orange line shows the attempted downloads, a few of which may be failures totalling 170,623 (which includes the 100,000 successful downloads).  My take on it is that these are Mac users cancelling after they discover that the Mobile Packager is Windows XP only

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.

Now 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.

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

As 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:

The 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

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.

Instructions

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.

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.

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.

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 Provider – A 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.

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

2.  To launch the player Activity (com.htc.flash.SingleViewActivity) directly passing a SWF file to play.

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…

We’ve been hard at work enabling support for new countries with the Flash Lite 3.1 player, enabling you to use the most recent player with the Adobe Mobile Packager 1.1. I’m happy to announce that we’ve continued to accelerate the addition of new countries around the world adding 16 countries, and bringing the total to 29.

The countries are: Australia, Austria, Belgium, Brazil, Canada, China, Denmark, Finland, France, Germany, Greece, India, Indonesia, Ireland Italy, Japan, Netherlands, Philippines, Russia, Singapore, South Africa, South Korea, Spain, Sweden, Switzerland, Taiwan, Turkey, UK and the USA.

Right now we’re looking at how to enable support for new devices on a platform level, so rather than certifying each device we can certify whole platforms.  It’s not an easy task but we’re very confident that the player won’t start breaking.

Recently as you know Nokia updated to the latest Flash Lite player on their 5800 XPressMusic device. This proved very popular with the user base with many thousands of downloads per day (that’s a great stat).

Since this was the first OTA update, and a new runtime, there were a few reported issues. They were with the security model and older content, softkey FSCommand and the Flash version string. I’m glad to say that Nokia have come through and another update is now available via the App. Update. application.

So get updating!

[Edit]
Additionally, you may also notice that the browser will trigger the update of the Flash player just like it does on the desktop. Unfortunately I didn’t take a screenshot, but it reported something like “Application update available”.

Great job Nokia!

You’ll hear how the Distributable Player with Flash Lite 3.1, has enabled them to reach their customers with a consistent experience across devices.

Check them out.

Working on Fanbase among others is David Brown, an extremely talented Flash developer.  He’s been working with us for some time on the Distributable Player, and in fact his Bacardi application may well have been responsible for the new security model

I’ve asked him to come and present a session on his experiences and thankfully he’s accepted.

AgencyNet: Mobile for Flash Developers
Thursday, April 30, 2009 11:00 A.M. PST

In this session David Brown from AgencyNet will uncover the key factors to consider when developing and deploying content to multiple devices with Adobe’s distributable player solution. Topics include Multilingual content, multiple input types, and consistent user experiences across screens.

Spread the word and register here

Today we announced the Flash Platform for the Digital Home one of the most exciting products I think we’ve produced in the devices space.  We’ve been working on this flat out for many many months, and finally all this hard work has resulted in an incredible new product.

It should be no surprise that the Digital Home player is built on Flash Lite 3.1 (same as the Distributable Player).  Though of course the major challenge has been to create a player that can survive on a set-top box.  Think about it, an average set-top box or TV sits in the home for about 5-7 years, these devices are rarely turned off and they are expected to consume little power.  Although to be fair, many are very bad at saving power in the off state including my box.

I remember sitting in an engineering training session (a year ago) watching a Flash Lite game playing on a television.  The team informed us that the challenge ahread was similar to plugging an HD TV into a mobile phone and attempting to go on youtube.  Think about it, a 300mhz CPU playing 1080p H.264 video; it just shouldn’t be possible.. but with the magic of Flash Lite and very clever engineers, it is

The results have been incredible and it’s pretty clear now that there’s a real opportunity to bring the web to your TV.  As usual we haven’t done this alone, we’re working with partners across the industry including Broadcom, Intel, Comcast, Disney Interactive, Netflix, New York Times Company, NXP Semiconductors, Sigma Designs, STMicroelectronics, Atlantic Records.  Of course there are others, but that would be telling

But these days we’re all about “multi-screen” so let us consider that for a moment.  Just think of all those users sitting in front of their TVs every night, and every single one of them fiddling with their mobile phone.  You see, interactive TV may have been around for some time but this changes the market and opens up a huge opportunity.

To give you an idea of what has been considered here at Adobe, enjoy!

LGE have become a leading vendor of Touch devices over the past few years releasing several extremely popular devices.  Already we’ve seen the Prada, Viewty and Renoir devices and now the latest mass market device the KP500 “Cooky”.

The KP500 sports an incredible WXVGA 240×400 resolution screen with a beautiful user interface, and its more responsive than ever because under the hood LGE are using Adobe Mobile Client.  Wait, another mobile runtime?  That’s right, you see our customers ship lots of different devices and for the UI space we needed something half the size and twice as fast as Flash Lite 2.0.  It uses a mix of APIs from Flash 6 and AS1/AS2 with hardware acceleration, a suite of device APIs and very efficient memory management to achieve these goals.

The Flash components of the KP500 include:
- Idle screen with 5 Widgets (Clock, Dual Color, Memo, Calendar, Album)
- Menu
- Call screen
- Call history
- Phonebook
- Alarm
- Scheduler
- D-Day
- Memo
- Voice Memo
- DMB (Digital Multimedia Broadcast) Menu
- Photo Gallery/Album
- MP3 Player

Though as a developer you may never play with Mobile Client, it is for user interfaces only so you would have to be working for an OEM or targeting BREW MP.  However some of the features and learnings have crept into Flash Lite 3.1 and are in the market now with our Flash Lite 3.1 Distributable Player.  We gained some new hardware acceleration for bitmaps using open standards, as a new plugin model for device APIs in the future.

Check out the video below…