One More Day for FITC San Francisco Early Bird

It’s looking like FITC San Francisco is going to be awesome. The speaker lineup is bomber and the diversity of the sessions means that there’s going to be something for everyone. Plus the fact that we’re down in San Fran means you’ll get to see a lot of Adobeans in the halls. I’m going to be doing a talk on Geolocation and Mapping with the Flash Platform, a more in-depth version of what I did at Flash and the City.

The early bird tickets are available for one more day so definitely register soon and lock it in. You can spend the extra money on beer.

Testing Battery Life and Performance with Flash Player on the Nexus One

When I did my video of various bits of Flash content running on the Nexus One, the overwhelming theme that kept coming up was battery life. I know battery life is something that both users and Flash developers are curious about. Flash provides access to a wealth of rich content. Video, games, and animation are all things that are much more processor intensive than rendering static images and text. In general, Flash content’s impact on battery life is comparable to other similar multimedia technologies. Where Flash really shines though, is that it uses the same amount of battery as other technologies, while providing a much richer experience with significantly better performance.

With all of the questions I wanted to provide some numbers about battery life but didn’t think that my rudimentary tests would be very good so I asked Vinay Ramani, the group product manager for mobile runtimes if his team had any data. These are very early initial tests but I thought they were worth sharing. You’ll be seeing more in-depth stress tests from us soon but hopefully these early numbers give you an idea of the fairly small impact that Flash Player in the browser has on battery life.

These are pretty close to clean-room tests. The team hooked up the meters and performed each test under a strict set of conditions:

  • Wi-Fi – off
  • 3G – on
  • OTA Push – off
  • Volume – on, at one notch
  • Bluetooth – off
  • Only browser is loaded, nothing else
  • 3G, lying flat on a table

Also, keep in mind that this is ALL done in software. Hardware acceleration is coming down the road but we wanted to make sure that this thing ran lean and mean in software without hardware acceleration at first. We also have ways that developers can control how SWF content loads on their pages so they can give certain SWF files priority and the Flash Player will give those a higher percentage of the resources. This should result in a smoother browsing experience.

Video

Video is probably the thing I get asked the most about with respect to battery life and it’s a good thing to compare because since both Flash Player and the Nexus One’s native player support H.264 you can get a good feel for how the battery life stacks up between native H.264 and H.264 video played through Flash Player. The team used the same YouTube video, one encoded at H.264 baseline level 2.1 at 30 fps with a resolution of 480 x 270. They did two sets of tests, one was on full brightness and the other was on half brightness. Then they just kept playing the video over and over again.

On full brightness, the Nexus One without Flash Player got 3 hours and 45 minutes. Playing the video through Flash Player gave a battery life of 3 hours and 8 minutes. Not a big dropoff. At half brightness it was even better. The Nexus One without Flash got 3 hours 56 minutes and the Flash version got 3 hours and 31 minutes. Just a 10.5% change, which isn’t bad at all considering everything Flash Player does.

Gaming

As you can see from the Flash/non-Flash tests, video is pretty intensive no matter what. What was even better was the battery life around games. There wasn’t a good way to test non-Flash versus Flash, but the team took a couple of popular Flash games, Tic-Tac-Toe and Alchemist, and played them until the battery died.

Tic-Tac-Toe lasted 6 hours and 49 minutes while the device could play Alchemist on the Nexus One for 7 hours and 7 minutes. While they aren’t intense 3D games, that’s pretty spectacular battery life and this was on full screen brightness. If you’re a game developer you can be sure that people playing your Flash game are going to be able to play it for a loooong time.

Animation

Let’s also quickly talk about HTML5 and Flash Player on mobile devices both in terms of performance and battery life. The team used the exploding balls test from Cameron Adams and tested the Canvas versions and the Flash versions. This one is a little tricky because part of the impact on battery life is how many CPU cycles are being used. And the higher the frame rate, the more CPU content is going to use. So it’s tough to compare HTML5 and Flash content directly because right now HTML5 content just doesn’t run very well on devices. The canvas example runs at 6.7 frames per second while the Flash version runs at about 24 frames per second. The difference between those ends up being minimal even though Flash has so many more frames per second. With the canvas test you get about 3.1 hours of battery life and with Flash Player you get 2.9 hours of battery life. A difference of about 12 minutes. We’re going to be doing some more exact tests around this where we equalize frames per second, so you should see some dramatic improvements once the test can be normalized.

This is just a sample of some of the early numbers that we’re getting. As I said, we’ll have some more detailed tests soon, but this should show that the hit for running richer content isn’t as big as one would think. The teams have done an absolutely phenomenal job of creating a runtime that performs on par with the desktop player and doesn’t sacrifice much at all in the way of battery life. If you’re a Flash developer, the exact same things that got you excited about Flash Player on the desktop now apply to mobile devices. The mobile world is your oyster Flashers.

Now Flash on.

Slides and Demo from Mapping/Geolocation talk at Flash and the City

I gave a presentation on Mapping and Geolocation with the Flash Platform today at Flash and the City. Below I’ve embedded the slides and you can download the PDF here. When I get some downtime today I’ll be uploading my demos as well.

Flash Builder for Dreamweaver CS5 Users

Thanks to everyone who stuck out the preso on Flash Builder for Dreamweaver CS5 users. Clearly this isn’t my month for demos. I’ve uploaded the slides as well as the (working) source code. There are two directories: the Flex directory, which includes the source code for the Flex projects, and the html directory, which includes the HTML code.

It’s got examples for using ExternalInterface, the Flex/AJAX Bridge, and FlashVars. You can grab it here.

Examples of Flash Content Running on Android

On Friday I gave the Keynote at Flash Camp Seattle and as part of that keynote I tried to show off Flash Player 10.1 running on Nexus One. Unfortunately the demo didn’t go well and it got some attention around the web. I’ve had a great experience with Flash on my Nexus One but in this case I was running an interim Flash Player build, one I probably should not have installed, and one that I definitely should not have used for any public demos

After I saw Jeff’s blog post, I sat down, upgraded my Flash Player, and went through and tested some of the sites I use on a regular basis. The experience was fantastic. Everything from the Eco Zoo to the NHL video site runs almost flawlessly. While it won’t make up for my mistake at Flash Camp, I recorded a video so people could see an experience that will be much closer to the final experience with Flash Player on Android.

It’s been cool to see so many Flash sites work on mobile devices. However because there is such a variety of Flash content out on the web, it’s important to understand that not all of it is going to run on devices like the Nexus One, both because of lower hardware capabilities of devices and because of user interface design.

A lot of people are clearly interested in Flash Player on mobile devices. It’s a big issue, and I feel terrible that my unpreparedness ended up being a strike against Flash on mobile devices. We’ll be releasing a public version of Flash Player 10.1 at Google I/O and would love to hear how your Flash sites perform. You can always submit issues by using the open Flash Player bug base.

“We’re Going to Try To Make the Best Tools in the World for HTML5″

Kevin Lynch had a Q&A With Brady Forest today at Web 2.0 Expo and addressed a lot of topics including HTML5. As an Adobe employee, I’m kind of excited about what we’ll be able to do with HTML5. Who knows more about drawing APIs and interactive web content than Adobe? Now that HTML5 has started to coalesce a little bit, I think you’ll see us bring a lot of that knowledge to bear as we do build tools that target HTML5. You’ll see some of the early thoughts around that on our Design and Web blog so if you’re interested in that, I encourage you to subscribe.

; ;

But just as HTML5 evolves, Flash is going to evolve as well and there are a lot of cool plans for the next generation of the Flash Platform. I think it’s a pretty exciting time to be a web developer no matter which technology you choose.

Hands-On Review of Android Multi-touch Tablet

At Web 2.0 Expo this year in the Adobe booth we’re showing off some devices and tablets running Android with full Flash Player and AIR on them.

It runs Adobe’s Flash and Air apps flawlessly. That was the first time I saw Adobe’s Air apps running on a tablet and totally impressed by how it ran. And now I can understand why Apple wants to ban Flash and other Adobe products completely from their iPhones and iPads, because it’s rather incredible technology.

It’s been a bit of a long haul, but we’re really close to putting the runtimes in your hands so you can see it for yourself.

Using Flash Builder 4 with your Flex 3 Projects

Flash Builder 4 has been out in public beta for a while and it’s been fun to see it progress. One of the things I noticed about the early betas was how some of the basic features like refactoring and event handler generation made a huge difference in my productivity regardless of whether I was using Flex 3 or Flex 4.

Now that Flash Builder 4 is out, it’s even more polished and you still get some of those benefits in your Flex 3 projects. If you’re currently in the middle of a Flex 3 application or you’re planning on targeting Flex 3 for a while, you can still get a lot out of Flash Builder 4. Andrew Shorten has a good rundown of how you can use Flash Builder 4 with Flex 3 projects. It’ll save you a lot of time and make your Flex experience that much better.

Using NativeProcess in AIR 2 with GPSBabel

GPSBabel is one of the coolest projects on the Internet. It takes basically any geolocation format and quickly lets you convert it into any other format. And the world of geodata is a wild west of various formats so it makes it super easy to bring all of that together in a handy command line tool.

Because it has a command line tool I figured it would make a pretty good (and easy) demo for AIR 2′s NativeProcess APIs. And it does! In fact, I started work on an ActionScript 3 wrapper that (should) make it easy to call GPSBabel from an AIR application and make it do your bidding. It’s in really, really rough shape, but here’s the beginning of it.

Getting Started

The first thing you need to do to use the NativeProcess API is to alter your app-xml file. After the initialWindow tag are a bunch of commented lines that talk about supportedProfiles. The NativeProcess API only works in the extendedDesktop profile so you need to enable it with this line.

<supportedProfiles>extendedDesktop</supportedProfiles>

With that, you can start testing the NativeProcess API.

Calling GPSBabel

Using the NativeProcess API is pretty simple. You first create a NativeProcessStartupInfo object, which is where you point to the executable binary as well as pass in any arguments. Then you set up event listeners on the NativeProcess object, and finally you call the start() method and pass in your startup object.

To convert one file type from another, GPSBabel takes a series of command line arguments. This is the command to convert a GPX file into a KML file.

gpsbabel -i gpx -f /tmp/myroute.gpx -o kml -F /tmp/myroute.kml

So to replicate this with the NativeProcess API, first create the startup object and pass in those arguments. The -i is the format of the original file, -f points to the original file, -o is the format to convert to, and -F is the converted file. All of those are pushed to the arguments property of the startup object.

var npsi:NativeProcessStartupInfo = new NativeProcessStartupInfo();
// The location of GPSBabel (a file object)
npsi.executable = _gpsBabelLocation;
var args:Vector.<String> = new Vector.<String>;
args.push("-i");
args.push("gpx");
args.push("-f");
args.push("/tmp/myroute.gpx");
args.push("-o");
args.push("kml");
args.push("-F");
args.push("/tmp/myroute.kml");
npsi.arguments = args;

The next step is to add event listeners to the NativeProcess object. Most of the time, GPSBabel just sends standard messages in UTF, so handling responses is easy. In the case of a conversion, the only event listener that really matters is the error listener.

_process = new NativeProcess();
_process.addEventListener(ProgressEvent.STANDARD_ERROR_DATA,onStandardErrorData);

Dealing with NativeProcess events was a little odd to me, but because GPSBabel just returns text, this is pretty easy. If it errors out, it dumps text to the screen. That text becomes part of the NativeProcess object. Depending on what the context is (if it’s an error, or just regular data output) it goes into a different variable. In this case, the event listener just reads the error data from the standardError property and traces it out

private function onStandardErrorData(event:ProgressEvent):void
{
trace(_process.standardError.readUTFBytes(_process.standardError.bytesAvailable));
}

The last thing to do is to go back up and start the process off by calling the start method and passing in the startup options that were created before.

_process.start(npStartupInfo);

And that’s it. I’ve got an example on GitHub as part of the GPSBabelOnAIR project. The mxml file in the examples folder uses the library, which has all of the NativeProcess code. The combination of those should provide a working basic example of using NativeProcess and GPSBabel.