Flash Camp Phoenix – January 29th

If you’re in the Phoenix area and are interested in hearing from some great speakers talk about Flex, Flash, and AIR, you’ll want to check out Flash Camp Phoenix on January 29th. I love coming down to Phoenix because it’s a great community. And there’s a lot to talk about. We’ve started releasing more info on Flash Player 10.1 for mobile devices, we’ve had AIR 2 in public beta for a while, and our Flash Platform family of tools is starting to come together in a big way.

I may also try to set up some hiking afterwards with Dan Florio so if you’re interested, keep that in mind.

AIR 2 and Flash Player 10.1 Betas now Available

Tonight we’ve released the AIR 2 and Flash Player 10.1 betas on Adobe Labs (direct download links for Flash Player and AIR). This is the first time we’ve simultaneously released the desktop (AIR) and browser (Flash Player) runtimes for all three platforms (Mac, Windows, Linux) at once, which is a great milestone for the Flash Platform. So what is this release and why should you care? One thing to note is that this is just the desktop runtimes, not any mobile runtimes. Those will be coming later. Luckily a lot of the work we did for mobile in terms of adding new APIs and optimizations are all in these releases so you’ll still get a lot of the benefits.

Flash Player 10.1

Lots of new stuff in Flash Player 10.1 including the multi-touch APIs, the performance gains, and some new networking APIs. The biggest thing (IMHO) with this release is the huge, huge memory improvements. Kevin showed the slide at MAX but it’s worth mentioning again. Without any code changes you’ll see significant improvements in memory with Flash Player 10.1.

flash_player_mem_footprint

AIR 2

air_logo_cloudsThe AIR team has been kicking all kinds of ass and I think AIR 2 is going to be a great release. One of the things we heard over and over again after AIR 1.0 was that people wanted more access to the native APIs of the operating system. AIR 2 brings a lot of that. Now you can open up a file with its default application as well as invoke native commands with the new NativeProcess API. We’ve also added the ability to create a socket server inside an AIR application and monitor changes to mounted drives. Plus a lot more. And you get all of the performance enhancements (and more) from Flash Player 10.1 so it should be a lean, mean AIR experience for end users as well.

Developing with the new Runtimes

(Update Christian has a list of AIR 2 resources that will help.) We won’t have a new Flex SDK for these runtimes yet so it’ll take a tiny bit of manual work to add support for the developer tools and the new runtime. Nick Kwiatkowski has a great screencast up for using the AIR 2 SDK in Flash Builder. It basically involves creating a copy of the Flex 4 SDK and then manually copying over the AIR SDK so it overwrites the AIR 1.5 SDK that ships with Flex 4. On the Flash Player side you’ll have to grab the playerglobal.swc and replace it in your Flex SDK.

I’m pretty excited about this particular set of runtimes. Talking to developers it seems like AIR 2 hits the mark and helps them accomplish more. Seeing the foundation put in on Flash Player 10.1 to create really great mobile experiences is also exciting. As always make sure to provide any feedback or any issues you run into over on the forums.

Really Slick Chess App in Flex/AIR

Greg Wilson has been busy working on a pet project with some friends that shows off nearly the full range of the Flash Platform. I got to see some early prototypes and screenshots so it’s really cool to see it in action. They spent a lot of time on the user interface and it’s an incredibly polished application. It’s also making use of the new AIR marketplace try/buy features so if you’re interested in monetizing your AIR applications you can download this to get a sense of how it works.

You may have to wait a little while currently to start a game, but once you do, it’s worth it. The graphics for the app are awesome. The UI is a really important part but as I said, they are making full use of the Flash Platform stack including using ColdFusion and LCDS. Greg’s next blog post is going to cover that part of it.

The only downside is that Greg is making the rest of us look like slackers. Adobe is supposed to be shut down this week but he’s cranking out software releases.

Tweetdeck One Year Later

There’s a good interview with Iain Dodsworth, the creator of TweetDeck, over on Louis Gray’s blog. Louis was one of the first people to discover and talk about TweetDeck and decided to chat with Iain a year later about how things are going. TweetDeck is still the Twitter client I use the most and provides me the most flexibility in searches and groups. During the interview there were a couple of AIR-related thoughts from Iain that I thought were worth sharing:

Louis: What made you decide to develop TweetDeck? You certainly went a different way with your product than others did, using the multi-column format, integrating Summize, groups, etc? What drove its initial feature set and had you choose the AIR platform?

Iain: …. AIR was an easy decision at the time – I had already been developing applications in Flex for financial institutions in London and there was no quicker way for a one man team to develop an application cross-platform.

Louis: TweetDeck, while popular, has also highlighted issues on Twitter’s end, especially around the service’s API limits. Also, the product has been a notorious memory hog and can take a good share of processing power. How are you working to reduce the demands taken on power users’ desktops, and how have you found working with Twitter and their API team, as they recently upped the API accesses users could hit per hour from 100 to 150?

Iain: I have worked very closely with Adobe to make improvements to the TweetDeck codebase and to work around various AIR/Flex issues. CPU & memory usage is an ongoing area for improvement and can sometimes be a bit of an art-form but we are getting there and the current version is a marked improvement over previous versions.

We’re always working (both on the actual runtime and with developers) to make sure that the AIR experience is better. I know the AIR team has been helped tremendously by Iain and all of the TweetDeck users. So congrats on a year Iain and thanks for helping make AIR a success.

Adobe AIR as “PDF of Web 2.0″

I love watching people discover AIR for the first time and give some thought to what it really means. We’ve gotten a lot of traction with AIR. The Marketplace continues to grow, developers continue to be excited about it, and both end users and developers alike are tweeting about how cool AIR is. There are a few bugs that we still need to work out of course, and we need to have more of a dialogue with users about how to performance tune their applications so they don’t balloon with memory as they’re used. But aside from that, the platform is in a really good place. That’s why it’s fun to think about the future.

Having one runtime that enables you to not worry about the operating system you’re on is a really powerful thing. Want to switch to Linux but don’t want to give up your apps? If they’re built on AIR you won’t have to. Think about the mobile implications. The success and popularity of the App Store for the iPhone has been huge. Imagine that but across every major phone and device operating system out there. With AIR we have gone a long way towards bridging the gap between the web and the desktop. We’ve given web developers a way to quickly and easily create desktop applications. That’s resulted in a lot of creativity and some very neat applications. And it’s coming at a time when a web-desktop bridge is exactly what the web needs to move forward. So as a developer, if you’re building an AIR app, you’re on the cutting edge of something very big.

Flash Player 10 Mac/Win/Linux Release Candidate Now Available

The Release Candidate build for Flash Player 10 on Linux (And every other platform) is now available for you to go grab and check out. A bunch of new things in this version:

  • Camera input works a whole lot better (V4L1 and V4L2 cameras both work; V4L2 cameras don’t peg the CPU anymore)
  • Software fullscreen performance is vastly improved
  • Faster, more stable windowless mode (but be sure to use very recent browser builds)
  • SSL now handled through NSS instead of flashsupport-OpenSSL alliance
  • White speckles are gone from video playback
  • Important stability fixes (fewer crashes)
  • Still not 64-bit native, just to get that out of the way

I continue to be happy about Adobe’s support for Linux. As more applications move into the browser with HTML or the Flash Player and to the desktop with AIR it makes it easier to switch. Mike Chambers just posted a really good screencast on how to get started with AIR on Linux.

Great Opportunity to Get Flex/AIR Training from the Best

Two of the best guys out there when it comes to teaching are going to be providing a cheap Flex and AIR Training Session July 19th and 20th. Mike Kollen and Chuck Freedman are the instructors and the training will be in Silicon Valley so if you’re a startup doing Flex work or a consultant who is looking at getting into the RIA business, this is a great way to do it.

You can head on over to their website, For Those About to Code, and register for the session. The cost is $675 which is a very, very good price for a couple of days of this kind of training. They’ve also got a few other courses tentatively scheduled including advanced Flex, Flash and AIR, and Flex UI/Skinning.

Debug Flash Applications with FireBug and ThunderBolt

At the on AIR tour in Berlin I just saw a really cool project called Thunderbolt by Jens Krause that lets you debug Flash applications in the browser using the very popular Firebug plugin. The project is an open source project and it’s hosted on Google code. It makes it really, really simple to get debug output and errors right inside of the Firebug browser interface.

Thunderbolt

For those of you not using Firebug you can also get an AIR version of the console that lets you send the output from a Flash application to an AIR app. It’s also open source and works pretty much the same way. The source code for that is also available. The application uses a combination of Flex and HTML and makes use of the YUI Tree component to display the output.

It’s another one of the great OSFlash projects so if you haven’t checked out OSFlash, you definitely should. There’s a ton of stuff going on in the open source Flash world.

On Desktop Application Platforms and User Interfaces

No matter what kind of developer you are I encourage you to read Peter Bright’s post about .NET. It’s a fascinating look at the history of Windows development and how it’s progressed (or regressed) over the past few years when compared to OS X. I’ve never done desktop development – I was always a web developer – so I can’t speak to the particular pain points or moving between operating systems. But I think this article is especially important for budding AIR developers who are helping cross the chasm of desktop development and web development.

I’ve always been a web developer in a lot of ways because it was easier. The browser handled all of the complicated work for me so I could write some UI code, some server side code, and then pretty easily make stuff appear on the screen. As I got into Flash and Flex more and more I was able to upscale the experience, make my little web applications look and feel more like native desktop applications, and all the while have the Flash Player worry about the hard parts of sophisticated development. Now with Adobe AIR I’m building desktop applications under that same idea. Maybe I’m lazy, maybe it’s bad that I don’t understand the fundamentals of desktop development, but the ease of web development combined with a better delivery mechanism has exploded and that’s where all the creativity and fun is. More people can be web developers and everyone is benefiting. So when I read articles like this about the frustrations of desktop development I wonder about what AIR holds for these people.

There are definitely things that AIR doesn’t do. It’s meant to be RIAs on the desktop and not a full replacement for native desktop applications. But it packs a bunch of functionality into APIs that will resonate with web developers. They make sense. We were able to start from scratch and AIR hides all of the complicated and possibly outdated API work that you’d have to do on any operating system. And the same code works on Mac, Windows, and Linux so you’re not locked into one operating system.

But one part of the article actually makes me worry about AIR, and it’s something I’ve been thinking about for a while. If we’ve got cross-platform AIR applications running on the desktop, what happens to the native look and feel that is very beneficial from a user interface standpoint? I don’t have a good answer. But Peter tears into the problem and makes some great points. Is Windows fragmented enough from a UI standpoint that we encourage AIR developers to try and follow the Apple UI guidelines where possible? Do we create our own set of UI guidelines (possibly using the Flex Interface Guidelines) that take into account the subtleties of web technologies on the desktop? Do we let developers use whatever UI guidelines fit their technology (Ajax/Flash) and get out of the way?

I don’t think the last one is the answer but I do think that as AIR becomes more widely adopted we need to encourage people to be good UI citizens. After reading Peter’s article I’m glad I never had to do desktop development. I like everything about web development and that’s one reason why I like AIR so much. But I realize there are pitfalls abound when combining the web and the desktop. I think it’s going to make for a lot of interesting philosophical conversations across a lot of different groups and that’s a good thing.

Update: Ethan picked up on this as well. Hopefully he’ll post more of his thoughts :)

Real Time Communication with Flex and AIR using ColdFusion and LiveCycle Data Services

In this walkthrough I’m going to take you through using ColdFusion (which contains LiveCycle Data Services) to create real time communication between an application in the browser and one on the desktop built with Adobe AIR. Both applications are written in Flex. You’ll see how we can create a better user experience on the desktop by using things like drag-and-drop and still tie that into a real time scenario inside of the browser.

The first thing you need to do is get ColdFusion 8 or LiveCycle Data Services (LCDS). For this tutorial I’m using RTMP which BlazeDS doesn’t support. I’ll have a BlazeDS example out later this week hopefully. ColdFusion has a LiveCycle Data Services install on top of it, so that’s what I’m going to use. You can grab all of the code from my SVN repository under the GPXShare project. You’ll also need my AS3 GPX library. I’ve got a sample GPX file you can use as well.

The second thing to be aware of is there are two general categories of communication in LiveCycle DS: the real time communication using RTMP and data management. Data Management lets you do things like synchronize data between online and offline sources while real time communication allows you to push data to clients instead of having to force clients to check in with a server. Data management is included in LiveCycle DS but not Blaze DS and BlazeDS doesn’t support the RTMP protocol but does have support for AMF for psuedo-real time communication. For this I’m just talking about real time messaging over RTMP. Damon Cooper has a good blog post about the differences between RTMP and AMF and how they apply to BlazeDS and LiveCycle DS.

The code is really, really simple. In my example, called GPXShare, I have two applications, one is a Flex-based application running in the browser and the other is a Flex-based AIR application on the desktop. You’ll see that I’m reusing a lot of code, one of the great things about using Flex is that you can quickly and easily move between the browser and the desktop. What I’m going to do is take an XML file with a bunch of GPS waypoints, drag it on to my AIR application, which will then send out that data to the browser application. You can have any number of browser applications open – each one “subscribes” to messages coming from the AIR application so they get the data in real time. The second part adds a tiny bit of collaboration. I want to be able to select a specific waypoint in either the AIR version or the Flex browser version and have that selection be highlighted on all the clients. All of that is really easy to do with LiveCycle Data Services.

Let’s first take a look at the AIR application. In my AIR app I have two pieces of code which establish a Producer and Consumer:

<mx:Producer id="producer" destination="GpxShare" />
<mx:Consumer id="consumer" destination="GpxShare"
			    message="doMessage( event );" />

. The Producer lets me send code out and the Consumer is what watches for changes. Each of those point to a destination which tells all of the connected clients how to pass the information back and forth. There are a couple of things we need to configure on the server now that we’ve seen the consumer and the producer.

  • The Destination – The first thing is to set the destination. We’re looking for a file called messaging-config.xml in the /WEB-INF/flex/ directory. In ColdFusion it’s located in your wwwroot directory. Add the following code in between the <adapters> node:
    <destination id="GpxShare">
    	<adapter ref="actionscript" />
    	<channels>
    		<channel ref="cf-rtmp" />
    	</channels>
    </destination>
    
  • The Channel – Now that we’ve set the destination, he second thing we need is to make sure that “cf-rtmp” channel exists. The channel tells the connected clients which protocol they’re all using to get to each other and where to send the information. Here we’re looking for a file called services-config.xml which will be in the same place as the destination config file. Once you find it, the channel definition should already be there you just need to uncomment it and tweak it. It should look like this:
    <channel-definition id="cf-rtmp"
    	class="mx.messaging.channels.RTMPChannel">
    <endpoint uri="rtmp://localhost:2048"
    	class="flex.messaging.endpoints.RTMPEndpoint"/>
    <properties>
             <idle-timeout-minutes>20</idle-timeout-minutes>
                  <serialization>
                      <instantiate-types>false</instantiate-types>
                  </serialization>
              </properties>
    </channel-definition>
    

So we’ve got our configuration files set up (you’ll have to rebuild your Flex project if you’re following along at home to make sure they get the new configuration settings). With that Producer/Consumer tag set up in our AIR application we’re ready to send out some data. Using the AIR API’s I’ve enabled drag and drop events from the file system so that when I drag in a GPX file, it will parse the data and display it in the grid. Once that happens we use the Producer to send the data out to all of our consumers with a doSend() function:

// Send our changes out to the consumers
public function doSend( array : Array ):void
{
	// Create the message and set the message body to our data
	var mess:AsyncMessage = new AsyncMessage();
	       mess.body.waypoints = array;
	       producer.send( mess );
}

The doSend() function is called after we finish opening the file from the file system and we just pass in the array of Waypoints. We create a new asynchronous message for storing our data and then set the body of that message to our data. In this case I’m sending an array with the name of waypoints. Finally we call the send() method on our Producer to fire it off. Now lets take a look at what happens inside of our browser application.

If you take a look at the code, you can see that we get to reuse a lot. Same data grid code and the same Producer/Consumer code. In this case, the browser is acting as a Consumer and you can see we’ve set the message attribute: message="doMessage( event );". This sets all of the consumers to watch for new messages and when they come in to call that doMessage function. So when we get message from our Consumer (the AIR application) with new GPS data, we call doMessage() in the browser:

// This is what happens when we get a message from the producer
public function doMessage( event:MessageEvent ):void
{
	// Logic checks to see which kind of message we're getting
	if( event.message.body.waypoints != null )
	{
	   dg.dataProvider = event.message.body.waypoints as Array;
	}
	dg.selectedIndex = event.message.body.selectedIndex;
}

Pretty straight forward. We’re passing in a MessageEvent and that MessageEvent contains the waypoint array we passed in from the AIR application. The only semi-tricky thing is that because this application also sends the selected row information back and forth, I do a check to make sure we actually have waypoint data and not just a new selected row number.

So that’s it! The only other part to the application is sending the selected row back and forth. For that you can again reuse a lot of the same code between the AIR application and the browser application. In both applications we follow the same steps. Set up a change event to fire on our data grid when we select a new row which calls a doChangeSend() function. Then attach the selectedIndex to the message body and pass it through the AsyncMessage. Now when we receive that message we set the selectedIndex of our data grid:

// When we make a change to the datagrid we
// send a message with this function
public function doChangeSend( event : ListEvent ) : void
{
	// Create the message and set the message body to our data
	var mess:AsyncMessage = new AsyncMessage();
	       mess.body.selectedIndex = dg.selectedIndex;
	       producer.send( mess );
}
// When we get back a change event
// make sure the right index is selected
public function doMessage( event:MessageEvent ):void
{
	dg.selectedIndex = event.message.body.selectedIndex;
}

That’s all there is to it. Remember you can grab the source code for both the browser-based Flex application and the desktop-based Flex application built with Adobe AIR from my SVN repository. If you have any question, leave a comment or send me an email. Damon Cooper also has a great list of resources for BlazeDS and LiveCycle Data Services for more information.