Example Added for GpxAs3 – The Flash/Flex GPX Library

Last week I added an example file to the GPX library that Simeon and I created for Flex/Flash/AIR applications. If you haven’t seen it and are interested in checking it out you can grab the code from the project page on GitHub.

The example provided is a very, very basic one that just takes a GPX file and plots the waypoints on Google Maps. It’s an AIR application so to use it you just drag and drop the GPX file onto the app. The code is here.

I haven’t been able to do anything cool with it yet, but I have some things in mind once I get a bit of downtime. If you’re using it, I’d love to hear about it.

Come to Flash Camp Boston for free, March 19th

We always do a lot of events on the West Coast but I’m extremely happy to be able to announce that we’re going to be holding a very special Flash Camp in Boston, on March 19th, from 5:00 – 11:00. It’s going to cover all of the new stuff in Flex 4 and Flash Builder 4 as well as a sprinkle of ColdFusion Builder for those who are interested in checking out the latest ColdFusion IDE. One reason I’m excited about this Flash Camp is that we’re bringing in a bunch of engineers from the San Francisco and San Jose offices to come present on their Flex 4 and Flash Builder areas of expertise. We’ll also have Deepa, fresh off of her promotion to Flex product manager, to give the keynote.

Here’s the tentative agenda and important info. You can register for free at the Flash Camp Boston event site.

How Much: Free and open to the public (Limited space and Registration required)
When: Friday, March 19th, 2010. 5:00 p.m. EST – 10:30 p.m. EST
Where: The Charles Hotel, Harvard Square, 1 Bennett St. Cambridge, MA 02138
Why: Why not?
What to Bring: Yourself and your laptop. We’ll be providing the beer, food, prizes, and access to parts of the engineering team so you can get all of your Flex questions answered.

5:00 – 5:45 p.m. Registration/Food/Drinks/Networking
5:45 – 6:15 p.m. Keynote
6:15 – 6:45 p.m. Overview of Flex 4
6:45 – 7:00 p.m. What’s New in Flash Builder 4
7:00 – 7:20 p.m. Break
7:20 – 7:50 p.m. Animation and Effects in Flex 4
7:50 – 8:05 p.m. Introducing ColdFusion Builder
8:05 – 8:20 p.m. PHP and Flex 4
8:20 – 8:50 p.m. Creating Custom Layouts in Flex 4
8:50 – 9:10 p.m. Break
9:10 – 9:40 p.m. Advanced Skinning in Flex 4
9:40 – 9:55 p.m. SpringSource and Flex 4
9:55 – 10:15 p.m. Flash Builder 4 Secrets
10:15 – 10:30 p.m Flash on Mobile
11:00 p.m. Doors Close

For those of you who can’t make it to Boston we’re also going to be running an event in San Francisco just a bit later with a very similar schedule. So those of you on the West Coast can get some face time with the engineers as well.

AIR and Flash Player coming for Android and Mobile Devices

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.

AIR 2 Beta 2 Available – Much Improved Printing Support

If you missed it yesterday, AIR 2 beta 2 is now available on Adobe labs. This release includes some bug fixes, some optimizations, and a few new features including support for TLS/SSL socket communication and much improved support for interacting with printers. I sat down with the engineer who did a lot of the work on the new printing API and interviewed him about it. He also walked me through a demo of the new features. The APIs let you have complete control over printing and customize the experience. It’s worth checking out.

Discussing New Printing Features in the AIR 2 Beta 2 from Ryan Stewart on Vimeo.

Important Flex 3.5 Update

If you have updated to Flex 3.5 you want to be sure to grab the new version of the SDK. There is a bug that has been fixed which caused issues with the auto-update UI. Here’s the scoop.

The Flex team has released an update to the 3.5 SDK that addresses an issue with the Flex-based AIR auto-update UI packaged within the SDK (SDK-24766). The refreshed build, SDK 3.5a, has only a few files modified in order to fix this issue and this change does not affect the signing and caching of the SDK 3.5 RSLs originally released in December.

We encourage all developers using SDK 3.5 to upgrade their build to SDK 3.5a to continue their development. The SDK 3.5a can be found in the “Latest Milestone Release Build” table here:http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+3.

HTML and Flash Thoughts

Kevin Lynch blogged today in response to a number of issues that have cropped up recently and does a great job of laying out both Adobe’s vision for Flash and for web tools. That and a couple of other posts got me thinking a bit. The first is Jeffrey Zeldman’s post. He contrasts Flash with some of the benefits of standards. Most of the time I see “HTML5 is going to kill Flash!!” without any kind of rational conversation on why. Jeffrey does a better job than most. His intro paragraph is a perfect example:

Lack of Flash in the iPad (and before that, in the iPhone) is a win for accessible, standards-based design. Not because Flash is bad, but because the increasing popularity of devices that don’t support Flash is going to force recalcitrant web developers to build the semantic HTML layer first. Additional layers of Flash UX can then be optionally added in, just as, in proper, accessible, standards-based development, JavaScript UX enhancements are added only after we verify that the site works without them.

My Current Problems with Flash

There are a couple of things I hate about Flash inside the browser. Both of them were covered very well by Richard Leggett in his Flash/HTML5 post. The first is browser integration. One of the things I think a lot of users find annoying about Flash is that it feels so alien in the browser. We have basically a single API, ExternalInterface, that developers can use to connect HTML and Flash. But it’s very awkward and it makes both the development experience and end user experience feel very different. Flash has become the “black box” of the browser. If you take a look at AIR, you see how great those two worlds can be. Flash and JavaScript can call each other’s APIs, Flash can access the DOM, and JavaScript can call Flash only when it needs to, for things like playing sound or performing graphical tricks. SVG and Canvas add a layer of complexity to that, but I don’t think that’s an insurmountable hurdle. In fact, I think those two technologies, when combined with Flash, would make a very interesting combination.

But that leads to the other problem. Flash is horrible when it comes to the semantic web. And this causes some other issues, like deep-linking or search engine optimization that we’ve worked on, but haven’t perfected yet. As Richard says, and Jeffrey notes, the current solutions aren’t entirely bad. Flash works very well with a CMS like Drupal so that you can have the semantic web layer and a Flash layer. And largely it depends on your project. In some cases that semantic layer isn’t going to be as important. It’s also important for developers to use Flash inside HTML where appropriate. Another thing I’d like to see is making it easier to create Flex applications that don’t take up the whole page, but work within an HTML context. Think a bit about what I said above combined with some kind of Dreamweaver/Flash Builder integration so that the developer can unify the HTML and Flash experience at a tooling level.

Adobe Is a Web Tools Company

People seem to think that Adobe has eschewed HTML5 in favor of Flash. A lot of innovation goes into Flash. We have a number of features that our customers want and we’re able to add those to the runtime and create tooling around them because we can move quickly and innovate. HTML5 is obviously more consensus driven. As a result, some of the details that would be required to add tooling support haven’t been fully nailed down yet. But we’ve moved ahead to do what we can. Dreamweaver continues to have great HTML and JavaScript framework support. We’ve shown sneaks of BrowserLab that will help HTML/JS developers see how their site looks in various browsers. We’ve included the latest versions of WebKit in Adobe AIR so that HTML developers can take advantage of a lot of HTML5 features in a desktop context, and in ColdFusion we’ve got support for creating ExtJS 3.0 components with ColdFusion tags. We even sneaked a feature at MAX that used Flash and Illustrator to display animated vector content using the canvas tag. So Adobe is supporting HTML5 in a number of different ways already and experimenting with even more. When the spec is nailed down, you’re going to see a lot of Adobe tools that support it.

Flash Is Driven By Customers

It’s important to remember that Flash isn’t some isolated plug-in that we maliciously deployed on 98% of web browsers and that consistently hits 80% penetration for new versions in 6 months. Flash is driven by customers. Both developers and end users. Developers still want content that runs the same way across browsers (and now devices). They still want web content that provides innovation around things like video, sockets, animation, data push, web camera, 3D transformations, and works across multiple platforms and 98% of the people on the web. There are some developers who won’t ever use Flash, and that’s fine. There are others who want to do things that HTML5 just doesn’t have an option for now. Flash is there to fill that gap. Part of the reason we can innovate with Flash is because we control the source code. While we’ve worked hard to be more open, ultimately it’s our customers demand for innovation that drives us. And I wouldn’t want Flash to open up and lose that ability to innovate. It wouldn’t be fair to our customers.

I’d love to see Flash do a better job of integrating with the browser and the semantic web. And I hope HTML5 pushes us more in that direction. I disagree that the era of plug-ins is coming to a close because I think there will always be web developers who want to do a little bit more and have the same experience across devices and platforms. Adobe can move at that speed while still offering tools for web developers of all stripes because both HTML and Flash are baked into our DNA. I genuinely wish for a more open dialogue between standards organizations and the Flash community. Unfortunately it seems like a “my way or the highway” attitude when it comes to web standards. I can understand that to some degree, but I think the web would be a much better place of everyone took a deep breath and took another look at Flash’s deficiencies and its strengths. With that as a starting point, I think there could be some very valuable conversations about how Flash can do more to support standards while still catering to customers who want new features.