Kevin Hoyt

As I was hanging out in Madrid, getting acclimated for the AIR Europe Tour, I started thinking about what I was going to present - specifically around script bridging. In the United States, I just talked about how Flash and HTML are separate, but can be integrated. I though it would be good to actually show how separate they are in the browser, and contrast that with how integrated they are in Adobe AIR. Several hours spent exploring ideas, and a new demonstration was born.

In the browser, JavaScript and Flash in the browser can communicate via a class in Flash called ExternalInterface. It’s relatively straightforward to use. The Flash content must declare what functions JavaScript can call, and then what actual functions those map to inside that content. JavaScript calls into those functions by getting ahold of the element ID for the Flash content and simply calling functions as though they were methods on that element. Flash can call JavaScript functions by using the ExternalInterface.call() method.

ActionScript to register a function:

// Register a method to be called by JavaScript
ExternalInterface.addCallback( "upload", doUpload );

Calling that registered function from JavaScript:

// Calls into Flash to manage file upload and results
function doUpload()
{
	document.getElementById( 'upload' ).upload();
}

Calling from ActionScript to JavaScript:

// Call JavaScript to pass the resulting data
ExternalInterface.call( "doComplete", event.data );

On the surface this looks pretty straightforward. It’s the implementation that reveals the problems. The HTML/JavaScript logic is written in one tool; something like Dreamweaver CS3, Aptana, or just TextMate. The Flash content might be coming from Flash CS3 or Flex Builder. What that means in the end is bouncing between multiple languages and tools to get Flash and HTML/JavaScript to play nicely together. If you’re using a framework on either side (i.e. Flex or Ext) that means knowing even more about both sides of the house.

How does this compare with Adobe AIR?

If you’re authoring with Flash or Flex, you have at your fingertips a full HTML/CSS/JavaScript rendering engine in the form of WebKit. Given that Flash doesn’t render HTML particularly well in the browser, that first step of integration is actually really powerful and enabling. Using ActionScript you can actually drill into the JavaScript DOM directly. This allows you to create, update and delete elements as well as set their values, whether that be more HTML element, or just text and values.

// Calling a custom JavaScript function from ActionScript
web.htmlLoader.window.doComplete( doc.toXMLString() );

// Calling a DOM method from ActionScript
// In this case setting the value attribute on an HTML input tag
web.htmlLoader.window.document.getElementById( "txtNombre" ).value = "Hola Mundo!";

If you’re a JavaScript developer, you have what I consider to be particularly visionary integration. First of all, if you use any AIR functionality from JavaScript, you’re actually using Flash functionality. You can see this mapping in action by opening and reviewing the “AIRAliases.js” file. You’ll see the configuration of the “air.” namespace, and then assignments of Flash classes to JavaScript names. These are what you actually use when you’re leveraging AIR features - Flash classes.

var file = air.File.desktopDirectory.resolvePath( 'hola.txt' );
var nombre = null;
var stream = new air.FileStream();

stream.open( file, air.FileMode.READ );
nombre = stream.readMultiByte( stream.bytesAvailable, air.File.systemCharset );
stream.close();

alert( nombre );

As a JavaScript developers you’ll now have a whole variety of new features that you didn’t directly have access to previously (i.e. upload with progress indicators, byte manipulation, etc.). Many of these features have been in the Flash Player for a while, just somewhat crippled by the browser sandbox. This hasn’t stopped developers from building functionality around the possibilities that those features create. This brings me back to the demonstration (source code, live example of upload) I originally mentioned.

In this demonstration there are two approaches - the browser and the desktop.

The browser approach leverages Flash for file upload, but is invoked by JavaScript. Flash is used for the file upload because you can (a) limit the type of file selected and (b) show progress, which is not something that the browser provides itself. When a Zip file has been uploaded, the server grabs information about the contents of the file and sends that data back to Flash as an XML document. That XML document is in turn handed back to JavaScript (via ExternalInterface) where jQuery iterates through the content and builds an HTML table.

As mentioned earlier, that’s a lot of back-and-forth between JavaScript and Flash, while also requiring you to handle multiple tools and technologies.

The AIR (or desktop) approach takes advantage of the fact that you can access local data, and of integration between JavaScript and Flash. But how do you unpack a Zip file with JavaScript? That’s not built into Flash is it? No, but byte manipulation is available. So you’re telling me that I have to unpack that Zip file myself? Normally I’d say yes, but as it turns out, David Chang has already done that for you and packaged it as a Flash library.

It turns out, that as a JavaScript developer using Adobe AIR, you can actually directly leverage that Flash library, exactly as you would any other JavaScript library. A Flash library (SWC) is packaged in Zip format, so unpack it using whatever tool you prefer and get at the “library.swf” you’ll find inside. Now write the following SCRIPT tag in your HTML to load that library and make it available to you from JavaScript.

<script src="library.swf" type="application/x-shockwave-flash"></script>

You might want to reference David Chang’s documentation to understand the classes you now have available to you, but at a high level, you want to use the reference “window.runtime” to get over to the Flash side of the house. This is what the AIR aliases file does for you. Now simply invoke David’s classes to unpack and inspect the AIR file. If you’re up for it, you can create a table of elements to display the content.

function doSelect( e )
{
	var data = new air.ByteArray();
	var element = null;
	var stream = new air.FileStream();
	var zip = null;

	stream.open( e.target, air.FileMode.READ );
	stream.readBytes( data );
	stream.close();

	zip = new window.runtime.nochump.util.zip.ZipFile( data );

	for( var e = 0; e < zip.entries.length; e++ )
	{
		elem = document.createElement( 'div' );
		elem.innerText = zip.entries[e].name;

		document.body.appendChild( elem );
	}
}

If you’re a Flex developers, there’s fun for you in this demonstration as well. Another aspect of this demonstration is a Flex-based AIR application that loads the HTML page from the browser examples I talked about earlier. Using Flex and ActionScript you can load and read the Zip file, and then build an XML document that describes the contents of the file - just like the server would have done for the browser. Then you can pass that XML data over to the exact same method we used in the browser, and jQuery will render an HTML table for you.

The integration of Flash/Flex and HTML/JavaScript is really powerful. It’s all too common to get into this war of what’s better, Flash or Ajax. The reality isn’t about only Flash or only Ajax, but rather using the best tool for the job. In the browser that can be challenging at times due to the technical requirements. With Adobe AIR however, you can quickly integration Flash if you an Ajax developer, and JavaScript if your a Flash developer. It’s the best of both worlds, and on the desktop to give you unparalleled functionality and features.

This entry was posted on Monday, March 31st, 2008 at 1:55 pm and is filed under AIR, Ajax, Flash, Flex, HTML, JavaScript, Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.