Archive for category Palm
EU – Adobe Mobile Challenge
Posted by Mark Doherty in Android, Flash Player, iphone, Mobile Content, Palm, RIM on July 12, 2011

This summer we’re running an Adobe Mobile Challenge for developers, designers and agencies around the EU territory. What’s really exciting is that you’ll get the chance to win a trip, including flight and hotel, to Adobe MAX in LA this October. We even have a few copies of Creative Suite 5.5 and Flash Builder Premium 4.5.1 for runners up, so lots of you will have a chance to win big.
We’re looking for applications that reach across different mobile platforms and that are published widely, on the Apple AppStore, Android Market and of course the Blackberry AppWorld for the PlayBook.
You’re application can be a game or branded content, anything goes really as long as your application is available in each store by the deadline below. Here’s my colleague Michael Chaize to tell you more, with his cool French accent..
DEADLINE: September 1
Preview: Flash Player 10.1 on the Palm Pre
Posted by Mark Doherty in Flash Player, Industry News, Mobile Content, Palm on March 22, 2010
Yesterday I spotted a lady here in the UK showing off her Palm Pre to a friend. So today I recorded a video to take a look at Palm’s WebOS Browser with Flash Player 10.1. Please note that the engineering build on this device is not up-to-date, but you can certainly get an impression of how great the experience will be.
For the user experience professionals out there, check out the card metaphor for switching between applications; amazing.
Flash Player 10.1 – Camera support with PhoneGap
Posted by Mark Doherty in Android, Flash Player, iphone, Mobile Content, Palm on March 12, 2010
Some of you will remember my earlier blog posts in August 2009 on the HTC Hero, the first Android device to ship with Flash. The goal of the Android experiment was to learn about the Android SDK, the development process and discover how Flash was enabled in the context of the browser.
As we edge closer to the release of Flash Player 10.1 in the first half of this year, it seems appropriate to revisit these posts. In this post you’ll see that there are hidden benefits to using a common runtime across device platforms, some of which are not that obvious.
The result of my week long investigation is that (using the beta version) I can hook up Flash Player 10.1 to the camera; but that’s just the start. Let’s look at how it’s done…
WebView
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 made available as a UI component for native applications. So this means that you can create an application in HTML/JScript and manage the user experience through a native shell.
So why is WebView useful? Let’s look at the relevant classes:
- 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.
So using a standard WebView I can use the core browser, or if I choose, extend this and replace the chrome and user experience. If you were reading carefully, inside WebView you will have noticed a method called addJavascriptInterface, and that’s where it gets interesting because this allows you to create a JavaScript front end to a native class.
In effect you can then write anything you want using native APIs, and add that functionality to WebView in the form of JavaScript interfaces. Wait! Doesn’t Flash have the ability to speak to JavaScript?
Flash Player – ExternalInterface
This is a long standing ExternalInterface API in Flash Player that enables communication with JavaScript in the browser. It’s primary purpose is actually to help Flash live alongside HTML, enabling Flash to signal JavaScript and pass messages back and forth. So in principle, if Flash can communicate with JavaScript and JavaScript with Native code, then we can start adding functionality.
Sounds really simple right?
PhoneGap
The folks at Nitobi have already made a huge head start creating PhoneGap, an open source set of cross-platform Javascript APIs for HTML applications, just some of which are below. The PhoneGap framework also enables anyone to create their own extensions based on the same principle, and although it’s quirky, the process is relatively simple.
In the git repository the team are also hard at work on functionality like Text-to-speech, Camera and File access for Android. Remember that this is an open source project, it’s changing just about every day and they need helpers. What’s really exciting is that PhoneGap workshops, including in person and online events; so I suggest attending!
| iPhone | Android | Blackberry | |
|---|---|---|---|
| Geo Location | yes | yes | yes |
| Vibration | yes | yes | yes |
| Accelerometer | yes | yes | pending |
| Sound | yes | yes | yes |
| Contact Support | yes | pending | yes |
Porting PhoneGap
As you have read previously, we are working to bring Flash Player 10.1, which includes the ExternalInterface, to Android in the next few months. Now, my Nexus One is an Android 2.1 device, and that creates a slight problem because PhoneGap is only compatible with Android 1.6 APIs.
This means that I had to port code and complete some APIs, in fact I’ve completed the Contacts API, updated the Camera, Location and Accelerometer APIs and did a spot of bug fixing get things working. In total this took about five days, to get setup and familiar with the code, and then writing some code for a few hours here and there. Using Open Source kit often results in these sticky issues, hint, that’s why Adobe put so much effort into documentation
With the Android SDK it really couldn’t be simpler to perform tests once I got started, really it couldn’t be easier to do live debugging on Windows, Mac and Linux; a great SDK from Google. Once you get into the flow of debugging, coding and testing it’s all good.
My advice, as always, is to think about functionality that you’d like to add and go for it. There are lots of docs out there, and alot of helpful code available for hacking something together.
FlashCam
After playing with PhoneGap and testing out my changes/addition, I decided to put the framework to the test and build an application. The first API test was for the Android Camera, and I’m calling it FlashCam.
With FlashCam I have created a simple stub application that contains a WebView, much like the previous blog post. This WebView pulls down an HTML page that’s actually on my blog here, and instantiates the native code and applies the javascript interfaces. So you heard that right, I’m able to extend functionality to a live webpage and not just a static local page.
HTML Integration
Embedded in the example HTML file from PhoneGap is a JavaScript function called show_pic(). It simply wraps up another function inside the phonegap.js that is also referenced in the HTML file. If this function succeeds then dump_pic() is called, if not then the function fail() is called.
The code under getPicture() is really quite complex and beyond the scope of this post, but you can see it here. Essentially it calls a native function called takePicture() written in Java, and this launches a new Activity (like a Window) with the camera’s viewfinder surface.
function show_pic(){
//Note: This could be simplified, but it's abstracted for safety
navigator.camera.getPicture(dump_pic, fail, { quality: 50 });
}
When the photo is taken we call dump_pic() and it will contain the Base64 encoded JPEG image data from the camera. Then, all we need to do is return this to Flash in a callback and in this case “mySWF”, which is the name of the SWFObject embedded in the HTML file.
function dump_pic(data){
document.getElementById("mySWF").photoBytes(data);
}
In the running SWF file we have a SimpleButton that can call the show_pic() function, but first we need to add a callback which is analogous to an event listener. In Javascript we call photoBytes(image_data), and once the ExternalInterface receives this event it will call onReceivedPhoto(image_data):
public function fl_MouseClickHandler(event:MouseEvent):void{
ExternalInterface.addCallback("photoBytes", onReceivedPhoto);
ExternalInterface.call("show_pic");
}
Here in the onReceivedPhoto function we decode the Base64 encoded image_data, which is just a very large string containing the image. I’m using the Base64 classes provided here by Jean-Philippe Auclair, and merely getting the ByteArray. I can then use Loader to take these bytes and produce BitmapData and do a little scaling in the imageLoaded handler before adding it to the stage within the holder_mc.
public function onReceivedPhoto(image_data):void {
var bytes:ByteArray = Base64.decode(image_data);
imageLoader = new Loader();
imageLoader.contentLoaderInfo.addEventListener(Event.COMPLETE, imageLoaded);
imageLoader.loadBytes(bytes);
}
private function imageLoaded(e:Event):void {
var image:Bitmap = Bitmap(imageLoader.content);
var tmpdata = new BitmapData(320, 260);
var matrix = new Matrix();
matrix.scale( 320 / image.width, 260 / image.height );
tmpdata.draw( image.bitmapData, matrix, null, null, null, true ); // smoothing
image.bitmapData = tmpdata;
holder_mc.visible=true;
holder_mc.addChild(image);
}
Here is FlashCam in action…
So that’s it, it’s really that simple to hook up native code to Flash Player 10.1. I suspect that this will also be possible on Palm’s WebOS, Symbian and Windows Mobile in time. I’m also loosely aware of a better bridge to JavaScript in Flash Player 10.1, so this might be a source of further investigation to improve performance for large data sets.
Now it’s your turn, below are the sources that I’ve used from PhoneGap with my own additions. You can also find the Flash FLA and AS files below, note that you will need at least Flash Professional CS4 to open the FLA.
Downloads
- Download Eclipse, or use Flash Builder
- Download Android SDK
- Download PhoneGap for Android 2.1
- Download Flash Sources
- Flash Player 10.1 Beta 3
Notes:
- You cannot keep the SWF file within the stub package, they must be in the remote sandbox.
- Flash Player security does not allow for localWithTrusted access to local Javascript.
- Proportional scaling of images is a pain in the ass in Flash, I’d like to hear about any libraries for that.
- I found CameraForm useful for producing encoded image data for testing; impossible with HTML5
Flash Player 10.1 – Installations and updates
Posted by Mark Doherty in Android, Flash Player, Industry News, Mobile World Congress, Palm on March 2, 2010
Flash Player 10.1 will become available in the first half of 2010 for all supported platforms. In fact, the desktop beta 3 is already looking incredible and proving to be a huge hit with developers testing their content.
One of the most important parts of our work with our Open Screen Project OEM partners is to enable the seamless discovery, installation and update of Flash Player 10.1 on device platforms. I know that some have asked questions on this, and so I’m glad to bring you some responses, if a little late.
Extending the reach
In the “marketecture” diagram below you can see that Flash Player 10.1 is extending it’s platform reach, doubling it in fact. It’s worth noting that recent reports around minimum spec’s for Flash Player 10.1 are alluded to here also, because working with our partners, we are targeting the latest chipsets available.
To explain, smartphones have a typical lifespan that is less than half that of a desktop computer, and so hardware choices are made by planning for the future. Over the past few years we have shipped over 1.5Billion devices with Flash Lite using this simple rule.
Therefore the choice to target the ARM Cortex-A8 chipsets will result in greater efficiency, and most importantly a wider range of consistent experiences as uptake grows. To be clear, that uptake is already happening, and it will expand rapidly just like it does every other year.
It’s like a Moore’s Law of mobile phones
Yet some devices will not be able to support the full Flash Player 10.1 due to low hardware capabilities, and for many of those devices we have a new version of our optimized runtime, Flash Lite, to fill the gap. In fact the alpha version has already been spotted running Farmville on Android Eclair here.
Driving the Distribution
![]()
Working with our OEM partners we have enabled the Flash Player to be installed in a manner consistent with the desktop experience. When visiting websites that have Flash content, users can click on the “Flash Player required” images/links provided by content developers to begin the installation process.
As with the desktop, the browser then redirects to the Flash Player Download Center, and in the case of mobile phones we pass these requests to the requisite device application stores such as the Android Market. Today’s application stores have extended abilities to correctly identify devices, and to manage the update of applications and plugins like Flash Player. Users can of course visit their application store directly if they wish.
In addition, those users purchasing new devices from a retailer may already have Flash Player pre-installed, made available in over-the-air software updates or through the browser directly.
Delivering Enhancements
As with the desktop install process, with each version of the Flash Player various updates are applied throughout it’s lifetime to ensure a high level of quality. Users can expect these updates to be provided automatically on some platforms via their application store update process, as well as through over-the-air software updates.
In the example above you can see the update notifications that users are familiar with on Android devices, and it is expected that this will be used for Flash Player 10.1 during it’s lifetime. Though I should point out that Nokia have been providing their own update mechanism, directly in the browser for some time now with a huge user uptake.
During the past few days Palm have also begun to lay the ground for Flash Player 10.1 support by delivering their software update.
Player Detection
On the desktop today developers use a combination of methods to detect the Flash Player and version. Recognizing the need for a consistent approach, these same methods can be used on mobile phones in the future. Adobe recommends SWFObject2, an open source project that provides cross-browser support. It is also supported fully within our Creative Suite tools. SWFObject works across browsers and device platforms to detect the Flash Player and it’s version. Should an update been required, the tool can enable the ExpressInstall experience or provide fallbacks as required.
Historically I know some have invested considerable time and energy in device databases such as WURFL, which helped us to accurately distribute application installers to devices. With Flash Player 10.1 we need only be concerned about the browser use case, and so I would argue that we do not need to continue this effort long term.
I hope this information will help you build a picture of the huge efforts that our engineering and product teams have made. The mechanisms for discovery, install and update of the Flash Player 10.1 are a fantastic achievement, even though for some of you these may seem rather obvious.
With the Open Screen Project partners we are literally changing the ecosystem, enabling a more complete and consistent web experience on devices, and driving the industry forward with the Flash Platform in 2010.
Battery Performance with Flash Player 10.1 on Nexus One
Posted by Mark Doherty in Android, Flash Player, iphone, Palm on February 24, 2010
It appears that there has been some confusion from the community at large surrounding battery performance. This was caused by my colleague Michael Chaize publishing an amazing video of Flash Player 10.1 demos on Vimeo.
Bloggers from Daring Fireball and Macgasm have spent a little more time than expected studying the battery indicators, as opposed to the incredible advancements in web browsing for mobile phones, netbooks and tablets. To be clear, the battery indicator changes being discussed are a function of video editing and Android design.
Typically these indicators are 4 step graphics, so the indicator will drop by one step for every 25% battery used. If Michael shows his phone with 50% full then this could be 51% in reality, using ~2% would then appear like a 25% loss. It’s just a graphic, and below Michael has provided more concrete results from the phone management UI.
That said, let’s look at some mobile facts for fun.
Mobile phones are complicated mini-computers with extremely complex chip designs all working to produce a rich experience with maximum efficiency. It should be no surprise that using 3G, WIFI, Bluetooth, GPS or leaving a browser window open and showing even basic HTML can drain your battery. Additionally, distance from a cell tower is also a potential pitfall and some the travellers among you will note differing battery life in various cities, countries and networks.
For many years we have been working within these constraints, probably without many of you realizing it. Remember that our mobile optimized runtime Flash Lite (shipped on over a Billion phones) and has been used extensively for User Interfaces on mobile phones from Samsung, Sony Ericsson and LG, so this is something that we know quite a bit about.
During our testing of Flash Player 10.1 we have baseline tests against the following use cases (among others), and using a multi-meter to ensure that your content runs with acceptable battery consumption. We’re also testing against the web on sites like youtube, blip.tv and others with great performance reaching to hours of playback on the Nexus One.
Here are the actual combinations of test scenarios carried out at our offices, of course the real world result for you will be different:
- Idle – No 3G, Wifi, Bluetooth, IR
- Idle – No 3G, Wifi, Bluetooth, IR + backlight ON
- 3G enabled – Wifi, Bluetooth, IR off
- WIFI + vanilla HTML. ‘simple.html’
- 3G + vanilla HTML. ‘simple.html’
- 3G + vanilla HTML file + swf: ‘simple-swf.html’
To demonstrate battery performance on the Nexus One here is a recording of a large movie playing on Youtube. It lasts for some 17 minutes with little effect on the battery indicator, and just to ensure fairness I have included the battery usage chart data from the Android OS. Our own tests show that video can be played for well over 3Hours over WIFI from youtube in H.264 (Baseline 1.2).
Note – This data is for a single website, below you can see that tv.adobe.com achieves better performance in the real world.
The resulting battery usage is a mere 6% for the Browser which totalled 199Mb of data received:
Update:
My colleague Michael Chaize has also completed his own tests shown below. In addition to my own basic test he demonstrates the ability to play videos and gaming for over 4 hours and five hours respectively.
Content Optimization
Without optimizing your applications, Flash or otherwise, they can perform badly on any platform this is 101 for any software developer. Our investments with Flash Player 10.1 and AIR are designed to provide the best possible results for the majority of existing content for web enablement on devices.
However, all of us will have to consider the user experience for our new mobile users and test effectively. Those of you that have created native or Flash Lite applications will know some of the tricks of the trade already, but nothing beats practice and real-world testing.
Thibaut (from the video above) has in fact written a fantastic document to lead you through the first steps in optimizing your content. Most of this is applicable to any of the Flash Platform runtimes, and certainly the desktop/AIR/netbooks/tablets etc.
Mike Chambers has also completed a great study on the Touch and Mouse events, and in particular how you can begin to optimize your content for this huge array of new platforms; and ultimately customers.






