Tag Archives: android

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

Posted on by
7

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.

Examples of Flash Content Running on Android

Posted on by
47

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.

Hands-On Review of Android Multi-touch Tablet

Posted on by
7

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.

PhysicalFoursquare – A Flash Player 10.1 Demo App Using the Foursquare API

Posted on by
2

As you’ve seen, we’re getting close to having a version of Flash Player 10.1 that will be available to the broader public. And a lot of the evangelists have been creating some cool demos of how Flash Player 10.1 behaves on the Nexus One.

I wanted to do something slightly different and build more of a functional application.

I come from a Flex background and so I haven’t spent a lot of time creating ActionScript only projects. And while Flex performs pretty well on Flash Player 10.1, doing an AS3 only project gives it a better shot at running, especially as the application gets more complex. So I went with ActionScript only and created an application that uses the foursquare API as well as the Geonames database to find and let me check into physical features like mountains, streams, and lakes when I’m out hiking and want to still be able to check into foursquare.

Thoughts on Building for Mobile Flash

As you’ve seen, a lot of Flash content will just work. And because of the AIR for Android packager, a lot of people will just end up building applications and not worry about creating in-browser Flash apps for mobile devices. But I wanted to try it. A few thoughts:

One, the Flex mobile framework can’t come soon enough. I have so much more respect for the old-school Flashers because rolling everything by hand is a pain. And I had it easy because I was dealing with a fixed resolution since I was specifically targeting the Nexus One.

Two, while I didn’t do much in the way of performance tuning, that’s going to be important. These are pretty beefy devices and we’ve done some great optimizations, but for complex Flash content, tuning your code will be central to a good experience.

Three, as Mike Chambers showed, hover content works, but I found it kind of annoying. The way it’s currently set up, the hover event fires after the down event fires. So using SimpleButton the way I normally use it didn’t quite work because the effect was off. I ended up just making the hover state the same as the down state.

Lastly, I was surprised how much just worked. I pulled a LOT of third party content into this application. Keith Peter’s Minimalcomps, the foursquare AS3 API by Tim Walling, my own AS3 library for Geonames, the Google Maps API, TweenLite, Shannon Hicks’ OAuthAS3 library – and it all worked just fine. Part of what I wanted to test was how much I could throw at the device and I was pleasantly surprised by how well it all worked even on the beta bits of Flash Player 10.1. So when you target these devices, you’ll be able to use a very similar workflow, which I think is important.

To see the application in action, you can check out the video above or test the application in your browser here. You’ll need to have a browser like Firefox 3.6 that supports geolocation and if you check in you’ll be checking in this poor guy. All of the code is available on GitHub and you’re free to do with it what you will. Unfortunately my OAuth implementation was half-assed, so the foursquare checkin didn’t work, but it works in the browser.

The Flash Mobile Advantage

Posted on by
4

A post up about Jeff Smith from Smule and why he won’t ever target Android.

Smith is part of a small but vocal chorus of app developers who say they don’t want to move to Android, even though it is growing quickly. His complaints: He doesn’t like the way the store merchandises its wares, and he doesn’t want to have to create different apps for each handset Android supports.

To me, that helps show the value proposition of Flash on mobile devices. You’re going to have to create custom Flash mobile content for each device. It’s not going to be write once, run everywhere. But you’re not going to have to rewrite an app from scratch and you’ll be able to use the same technologies and tools across multiple platforms which means you can crank out applications faster and make sure they’re higher quality.

As developers get more sophisticated, just like agencies have their own frameworks to give them a head start on the apps they build, you’ll see frameworks that decrease the time to market of mobile applications for different sized screens and different functionality. But the key is being able to use the same tools, the same language, and the same platform so that you can easily tweak and write those applications for multiple platforms.

AIR and Flash Player coming for Android and Mobile Devices

Posted on by
4

If you’ve been a member of the Adobe/Macromedia community you’ve heard a lot about Flash on mobile devices over the years. After seeing what’s coming, I think this is what you’ve been waiting for. We talked a bit about Flash Player 10.1 for mobile devices at MAX, and having played with a working version on the Nexus One, I think it’s going to be great for people that want to consume bits of Flash content here and there, especially games and video. But what we haven’t talked much about is AIR for mobile devices.

Cross-device Applications

AIR has been a big success on the desktop partly because being able to create an application with native hooks and having it run cross-platform is a big benefit to developers and to end-users who jump around different operating systems. But the mobile landscape is an even bigger minefield. Apple’s phone gets all of the attention, but you’ve got Android out there, RIM’s BlackBerry, Palm Pre, Windows 7, and others. If you come up with a great idea for an application, you have to write it for all of those platforms. Or watch as someone takes your idea and copies it on one of those platforms after you invest all of your time building it for a single platform. AIR for mobile is going to let you use the language and the tools you know to create applications across all of those mobile devices much more easily. We’re starting with AIR mobile for Android and BlackBerry and Kevin Hoyt has a demo video up that shows it in action on the Motorola Droid. And with AIR for mobile you’ll get access to multi-touch, accelerometer, GPS, creating your own gestures, screen orientation, and other device-specific APIs.

Introducing the Mobile RIA

One of the things that’s going to become very important for developers is creating content specifically for the small screen. Tools like Flash CS5 are going to make it very easy to reuse assets and workflow to create both applications and in-browser mobile Flash content. With AIR for mobile you can take the same application and run it on Android, compile it as an application for the iPhone, or deploy it on Mac, Windows, and Linux on the desktop. Depending on the device, you may want to make some small modifications, but you’ll be able to reuse your assets and a bulk of the code to quickly create cross-platform mobile applications with AIR mobile.

Because of the screen size and the very different specifications of each device, it’s going to be critical to customize content as much for a single device as possible and make sure you’re following best practices. There is a good article on creating mobile RIAs over on the Developer Center and Thibault Imbert has put together a great beta paper on optimizing mobile content for mobile devices.

Flash Platform Tools and Workflow

There is always a lot of talk about the future of Flash and which devices it’s on. But the ecosystem of Flash has gone way beyond an animation engine that’s limited to the web browser. No matter what you’re doing, the tools and workflow of the Flash Platform are going to give you the ability to deploy the most creative applications across the most used devices. Some of those applications will be mobile RIAs in the browser and some will be AIR mobile applications that take advantage of native APIs across mobile operating systems. For developers it really is one web, any device, and any kind of application. So get ready to go nuts and show every other developer how mobile applications are supposed to look.

iPhone versus Android (HTC Hero edition)

Posted on by
12

htc_heroAfter MAX I went backpacking and fell in a river with my iPhone in my pocket. The iPhone is not a fan of water so it was totally dead. I have to get a new one through the Adobe system but this week everyone at Adobe has been on vacation so I wasn’t going to be able to pick up a replacement. That left me with the HTC Hero that I’ve got for demoing Flash mobile content. I swapped the sim card and I’ve been using it all vacation. I hadn’t used any phone but the iPhone for a prolonged period of time in a while so I figured I’d write up my thoughts on the iPhone versus Android now that I’ve actually had to learn the Android quirks.

Overall User Experience

I really, really want Android to succeed. But the iPhone is still the king when it comes to user experience. I find the HTC Hero with Android to be much, much less snappy than the iPhone. When I click something on the iPhone, I get an immediate reaction. On the HTC Hero, there’s a noticeable delay which becomes very annoying. However I like the UI for the Hero a lot better. Android has a nice, polished UI that is mostly intuitive and a bit more interesting than the iPhone’s boring button UI. The responsiveness is what got me though. On a faster phone, I could see Android being king here, but right now: Winner: iPhone

Battery Life

I found the battery life between the iPhone and the HTC Hero to be pretty equal, they both last me less than a day with heavy use. But one thing that I found extremely annoying is that the HTC Hero takes forever to charge via USB while the charging the iPhone over USB works really well. As a result: Winner: iPhone

Software

I love the Android software. I know Apple has the “There’s an App for That” crap, but out of the box, Android rules. Being able to install applications with a barcode scan is also really slick. I found the Android software to be more full featured, have many more hooks into the social networking services I’m a junkie for, and generally just more fun to use. If it wasn’t for the sluggishness, it would be perfect. The exception to this is the mapping. It’s abysmal. No gesture support for zooming, you can’t click on markers and interact with them in the same way you do on the iPhone. It’s just terrible to use. But in general, even with that and all of Apple’s apps, Winner: Android/HTC Hero

Typing

I type a lot on my mobile devices because I use them pretty heavily for email. I found it took a while to get used to the Hero’s keyboard. I like the fact that Android offers you a set of words based on what you’ve typed so you can auto-correct. That feature also makes it easy to add things to the dictionary because you can just click the word you typed and it will be added (no more ‘shot’ and ‘duck’). But even with that enhancement the iPhone’s keyboard is just better at detecting which letter I want to type next. Maybe I just need to spend more time with the Hero, but Winner: iPhone

Annoying Things About Android/HTC Hero

No sensor that detects when the phone isn’t near your face any more. This is just a limitation of the phone but it is annoying as hell. I also think the phone is too “buttony”. While I like the rollerball, it seems like any time I want to do something I have to click a button. With the iPhone they did a great job of making it as gesture-based as possible. The browser is a good example. On the iPhone, to type a URL, just move to the top of the page, and type it. With Android, you have to push the “menu” button. Takes some getting used to and the iPhone feels more natural.

Annoying Things About the iPhone

No Flash Player for one :) . But I also loved the GPS indicators on the Android. The little status icon at the top tells you whether you actually have GPS signal, and the camera lets you know when you’re locked on so it can geotag your photos accordingly. I really wish the iPhone had that.

Summary

In the end, the iPhone is just too damn good. I have high hopes for the Droid, but I’m on AT&T so I won’t be seeing it any time soon. But if the new processor is as good as people say it is, then hopefully we’ll get a snappy Android phone on AT&T soon. When that happens, I’ll ditch the iPhone in a heartbeat.