There is a cool workshop being given by Jamie Kosoy called No Flash? No Problem and he had a great quote in the description:

There’s a long list of common complaints about the use of Flash, but many of the criticisms just aren’t true. Detractors say that Flash isn’t search engine friendly; Screen readers can’t understand Flash content; You can’t deeplink to specific pages…

You know what? They’re wrong. These criticisms are symptoms of misunderstanding by developers on the ways different technologies work together.

I think this is one of the biggest problems that Adobe has. Technology and development choices tends to be borderline religious in nature. And technology in general loves to have good guys and bad guys. That means the communities are very siloed and there is some resistance to incorporating or looking at other technologies. It’s HTML5 versus Flash, Microsoft versus Google, .NET versus Java, etc.

It’s also become a lot harder to be a generalist. Developers get rewarded (at least in terms of attention) for becoming experts in their niche. They’re asked to speak at conferences, they get better gigs, so becoming an expert has direct financial and publicity benefits. Who has time to dive into other technologies when there are so many advantages to drilling down into your own?

Because of that, I don’t think we’re seeing technology at its best. And it’s not limited to Flash. PhoneGap has been very successful by combining the iPhone with HTML/JS. But Flash suffers more than most. There are a lot of great integration points between HTML and Flash. We’ve got the Flex/Ajax bridge for Flex that lets you expose Flash methods to JavaScript and vice versa. We’ve got deep-linking support with SWFAddress that uses JavaScript and Flash. There are a lot of integration points but they don’t seem well publicized or well used. And there are no shortage of areas where Flash can augment JS/HTML to solve problems. File uploading, Webcam/Mic support, and charting.

But I also think Adobe is at fault. I don’t think we’ve done a good enough job of making it easy to integrate Flash and HTML. Even now internally you hear things like “HTML strategy”, or “HTML versus Flash” and I haven’t heard a lot of talk about how we’re going to take what we know about RIAs and web apps and apply that to both Flash and HTML.

But I think that’s changing. So part of the post is to give heart. We recently had a big re-organization and most of the Creative Suite web tools and the Platform (Flash/AIR/Flex,etc) are together in one business unit. I think that means you’re going to see a lot of Flash-knowledge applied to our HTML tools and hopefully you’ll see a lot more about using Flash and JavaScript together so we don’t need sessions like Jamie’s a year from now.

With the web design tools and developer tools in one place, I’m looking forward to talking a lot more about rich web solutions that provide some innovative examples of technology working together and encouraging HTML/JS developers to look at Flash where appropriate and Flash developers to think about HTML/JS when it makes sense. The easier we can make that for developers the more success we’ll have and the better applications we’ll see.

This hits two of my favorite things; Flex applications and in-browser RIAs. Picnik, the Seattle-based startup that was purchased by Google a little while ago built one of the coolest photo editing applications on the web and were very early users of Flex. I always loved the customization work they did to Flex and stopped by their offices a few times to talk with the founders and meet the team. I was really happy when they were bought by Google (they also moved closer to the Adobe offices in Seattle).

So it’s really cool to see the announcement today that they’re integrating with Picasa to allow Picasa users to edit their photos using Picnik. Combine that with the blog post by YouTube about how they’re using Flash and I think there is a lot of momentum for Flash at the worlds biggest web company.

And hopefully that means a lot more great browser-based RIAs. Google loves the browser and is pushing it further with things like ChromeOS. I still think the browser is the best way to deliver applications and content. Picnik is a great example that you can take Flash and build something very powerful with a great user experience but with all of the freedom and flexibility of the browser. That’s clearly the model Google likes and they’re moving forward on that front with whatever technology works best for the problem.

It’s going to be a good future.

And for those who like history, John Cook pulled up the original email that started Picnik where they discuss Flash and compare it to other technologies. It’s a cool trip down memory lane.

The official Flex team blog reminded me that Effortless Flex 4 Development is now available. It’s the perfect book for Flex and PHP developers and I got an inside look at it as I did the tech-reviewing for it. Larry is an awesome author who usually does a lot with PHP but recently started getting into Flex and in talking to him it sounds like he really enjoys it. So definitely go out and grab a copy. I think we’re going to try and buy some to give away as I go out and talk to PHP and Flex developers alike.

This is a fairly straightforward topic but I did a quick DZone article on charting with Flex and PHP using the data-centric design wizards in Flash Builder. The wizards make it very easy to at least get the basics down and start using data in charts, and I covered some basic ways to add animations and interactivity.

I’m working on a more in-depth article with Zend that will cover grouping/sorting/etc on both the client and server side. It will provide some info on how to structure your data and make it more flexible for manipulating when it’s in the chart.

As an evangelist, obviously a lot of what we do is presenting. I always wish I could make my presentations more interesting and more of a show so I’m always watching how other people present. A great example is Cirque Du Soleil, which came through Seattle as part of their Kooza show. At a basic level, the Cirque Du Soleil presentation isn’t too different from any other presentation. A lot flashier, a lot more badass, but still a basic presentation. As I was watching I noticed a few things that I wanted to jot down and (hopefully) incorporate in my future presentations.

This one is pretty basic but the Cirque Du Soleil guys do a good job of it. At the beginning in most of the acts, the performers look a little tentative. There’s a bit of a dramatic flair, they look like they’re concentrating really hard (and they probably are) and setting a baseline for what’s coming later. By building up the suspense the audience is impressed right from the beginning. The stuff after that is just gravy. And when they break out the safety gear, you know stuff is going to get real.

I thought this was fascinating. In a couple of different performances, the performers screwed up the act. Once it was a high wire guy messing up a jump and another time it was during a giant spinning-dual hamster wheel act where one of the performers almost falls off. At first I wasn’t sure it was on purpose, but after asking around, they always mess up the same part of the show. Why? One, it adds dramatic flair. But most importantly, it adds to the perception that this is really hard stuff to do. Then when they go into the hard stuff and nail it, the crowd goes nuts. I’m not sure how to do this on the tech side, but I have a couple of ideas.

These guys (and girls) do these acts on a pretty consistent basis. They’re so good they can create a fairly convincing fake mess up. At the end, they let you know it. They do a great job of selling what they just did and getting people to cheer for them. Ultimately I think this is about confidence, but it’s also about taking yourself outside of the bubble and remembering that not everyone can do what you do. When you travel with Cirque du Soleil all you see around you are people just like you, but you’ve got to remember that the audience can’t do what you do. And make them love you for it.

One of the reasons I love Cirque du Soleil is that every act has a theme. The costumes, the props, the music and the choreography all revolve around a central theme. Kooza had a definite South Asian feel and some of the acts played up that more than others. But all of it together helped tell a story and engage the audience more and each act built on the theme a little bit. This is probably a bit tougher to do in a technical presentation but I can think of some things I’d like to do that would be more thematic in my presentations.

If you get a chance to see Kooza, it’s a great show. Just watch for the mistakes.

I love the web. I love web development, I love web applications, and most importantly I loved where we were going with web applications. I was obviously a huge proponent of rich Internet applications and capturing a better user experience inside of the browser. Combine a great user experience with all of the good things about running in the browser (deployment, ubiquity, cross-platform, free publishing) and I thought that was a winning combination.

Then the App Store came along. Now everything is about standalone mobile applications. It feels like the web has taken a backseat as developers plunge head first into building native applications and users download them in droves. What bugs me the most is that I’m the same way. Most of the applications I use on my phone have perfectly good browser equivalents but I use the native app.

So what the hell happened? I think it comes down to two things. One, the app store provided a much better economic model for developers. One problem with the web was the downward pressure it put on the economics of content. Actual dollars were replaced with eyeballs and people started giving away the content and making money on advertising. (Think about how this affects Google, the ultimate web company; With revenue driven by advertising, they get a cut. With revenue driven by the App Store, Apple gets a cut.) With the App Store, developers can go back to charging directly for stuff they create instead of giving it away. It’s also insanely easy. They don’t have to worry about taking a credit card, setting up payments, or anything else that developers don’t want to worry about. They just have to build software, set a price, and the checks come in. That’s incredibly compelling. Especially if you’re doing development in your free time as a hobby. Now you can easily get paid for it without having to do any of the business tasks that might bog you down if you tried to do it on your own. That frictionless entry has changed the game for a lot of developers and created a huge supply of native mobile applications.

But that doesn’t explain the consumer demand for applications. I think that lies in user experience of applications. Prior to the explosion in mobile apps, we were getting close to a native-like user experience with RIAs in the browser. The components were better, the user interactions like drag-and-drop were appearing, and we were tackling problems like offline access directly in the HTML5 spec. Even the browsers were one-upping each other to be faster so we could get closer to native performance. The gap between a desktop experience and an in-browser experience was closing quickly.

Then quality mobile devices came along and changed everything. Instead of a mouse pointer we were dealing with fingers. Instead of worrying about offline access we had a ton of new functions on the phone including built-in GPS, accelerometer, camera, and a compass. The fastest and best (and in some cases only) way to take advantage of these new features was with native applications. Furthermore, the web experience was very much stuck in the old “pointer” mode. Mobile Safari on the iPhone made HUGE improvements to the mobile browsing experience, but nearly all of the websites were built for big screens and mouse pointers. Using the mobile browser on the iPhone (or any smartphone) is a lot of zooming and dragging. Even worse, some of the things we worked so hard on when it came to RIAs, like drag-and-drop, didn’t work the same way (or at all) and became more of an annoyance than a great feature.

So almost overnight all of the user interface paradigms the web had moved towards were rendered useless for this generation of mobile browsers. There were some initial attempts at fixing the issue, the best example is iUI by Joe Hewitt, but most people moved towards native apps. With better access to all of the new features, who could blame them?

So what does this mean for Flash developers? To be honest, I’ve been a little nervous. There is a huge drive to get Flash on mobile devices when the world seems to be crazy about apps. If you want to build apps with Flash, you can do so with AIR for Android (and eventually other platforms). But I don’t want apps. I want the web. Up to now, a lot of the interest/debate has focused on consuming basic content in Flash. People want Flash on their devices so they can watch video and play games. But we were making huge progress on in-browser RIAs with Flash. I want that momentum back in mobile form.

But what if we can revolutionize the in-browser mobile application experience the way Flash helped revolutionize RIAs on the PC? There is already an undercurrent of anti-native sentiment in the development community. Take a look at Sencha Touch, which is a fantastic looking mobile application framework designed specifically for i-devices and the mobile browser. And their first marketing campaign is even better, declaring the “end of native” at WWDC.

That’s exactly what the Flash community should be striving for. What’s so great about native? The performance? The user interface? Those are both things we can overcome with better technology and better design. Is it that it’s so easy to make money? Then the web is ripe for a better business model. The biggie is feature access. But here’s where Flash has always led the pack. We’ve had camera/microphone access forever and have always led the way in expanding the functionality the browser could take care of. If we can follow that trajectory on mobile then Flash developers are in a great position to make mobile browser apps a reality.

And that’s what I’m excited about. Screw native. I’m a web developer.

One of the PHP demos that goes over pretty well is my Flex socket demo. It used to be that Flex/Flash was really the only way to take advantage of WebSockets but with browser vendors implementing bleeding edge support for HTML5, developers can now use the WebSocket API in JavaScript. I wanted to combine that with the Canvas API and try to recreate a basic example of my Flex socket demo in HTML5/JavaScript. It mostly works (demo embedded at the bottom).

• socket.html – HTML/JS file for connecting to the socket server
• socket.php – PHP file that creates the socket server

It’s been kind of cool to see the browser vendors really move forward to implement support for various bits of HTML5 and CSS3 without a defined spec. That can be problematic because the spec is still changing, causing code to break in new versions of browsers, but in general it means that web developers can live on the cutting edge for most browsers. Currently, the WebSocket API (and this example) should work in the latest version of Chrome and the Firefox 4 beta.

Overall the WebSocket API is pretty easy to use. I took my existing PHP socket server code that works in Flash and tried to use it for the HTML5 version but all I was getting was the “close” event. The problem was that I wasn’t thinking about the handshake. Flash uses a policy file to determine whether or not it can connect, but the WebSocket API uses a handshake. I was able to grab some example code, change my PHP server to add the handshake then everything basically worked. The only other small change I had to make was to add a character (chr 0 and chr 255) to either end of the message I was sending through the socket_write method. I’m still not entirely sure why this is, but my onmessage event wouldn’t fire until I added those.

I’m very excited about the Canvas API in HTML5. If you’re a Flash developer who has been working with the Flash drawing API, you’re going to be able to do some very cool stuff. The APIs are fairly similar with some syntax changes that you have to be aware of. The biggest pain I found was that once something is on the canvas, it’s on the canvas. You can’t reference specific drawn elements like you can in ActionScript. That makes doing things like the hover effect on specific charting points basically impossible.

Partly because of that, and because I’m still getting used to JavaScript I went with a very scaled down version of the chart. All this chart does is draw some grid lines and then plot the points as it gets them from the socket server. When you get to the end, the points are drawn off the page. I also couldn’t really figure out how to add to a path in a function call so I just went with the points instead of making it an actual line graph. I’m fairly sure that most of these are due to my JavaScript incompetence and not a limitation of Canvas.

It was both a lot of fun and very painful to go back to JavaScript. It’s an incredibly powerful language but if you come from Flash, you’ll find yourself banging your head against the wall because of subtle differences. The one thing that keeps tripping me up is figuring out how the DOM works compared to Flash. Another sticking point is the tooling. We have very good tooling on the Flash side compared to JavaScript. Chrome’s developer tools and Firebug both help a lot, but there’s no tool out there that provides code completion for the Canvas drawing API. When you don’t know the API that well, it means a lot of Googling, and a lot of the examples are pretty basic. I think a tool with basic code completion for Canvas would make it a lot easier to start creating complex content in.

It’s definitely rough to go from Flash to JavaScript but hopefully I’ll be playing around with the new stuff in HTML5 more, especially as Dreamweaver gets more support baked in.

I didn’t realize until Renaun blogged it that the Flex 4.1 SDK includes Flash Player 10.1 and AIR 2. One of the biggest pains for me during the beta period was copying over files and folders to merge the 4.0 SDK with AIR and Flash Player so I could do development in Flash Builder. I didn’t know they were doing a 4.1 that included both of the new runtimes.

That means you can grab the Flex 4.1 SDK, and using Flash Builder 4 you can add it to your list of SDKs and start taking advantage of the new APIs including multi-touch, geolocation, and socket server. As Renaun mentioned, make sure you target Flash Player 10.1 or above in your project when you’re selecting the new SDK or you won’t be able to use the new APIs.

Flash on!

Last week I presented at the Front Range PHP User Group on getting started with Flex and PHP. It was a really awesome group and I had a great time presenting. Thanks guys for having me and for sticking around for drinks afterwards. If you were at the meeting (or just want to take a look) I just posted my slides as well as my demos from the event. The slides are embedded below and you can grab the demos from my DropBox account. There isn’t much documentation on the demos, but hopefully they’re semi-helpful.

Getting Started with Flex and PHP View more presentations; from Ryan Stewart.

If you’re a citizen of the Internet, you probably know that the World Cup kicked off today. If you follow me on Twitter you know I’m not a huge soccer fan, but I am a fan of global events like this so I’ll definitely be keeping it on in the background. I may even be hitting one of the local bars at some point to drink way too early and watch. But mostly I’ll be watching it online and ESPN3 has all of the world cup action streaming along with stats, info, and anything else you could ask for. And it’s all powered by Flash.

My colleague, Jens Loeffler has a great writeup on the app and the experience. It’s all powered by the Flash Platform and Flash Media Server. You get multiple audio channels (so you can listen in Spanish, which I think is the best way to listen to goals being scored) as well as picture-in-picture and real time highlights that appear along the timeline so you can go back and see the cool moments. It’s a really great showcase of Flash and how the whole platform comes together to provide an excellent viewing experience.

Flash on soccer fans!

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.

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

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.

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.

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.

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.

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.

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.

; ;
Click to play

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.

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.

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.

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.

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.

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.