Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

ExternalInterface: SWFs Communicate with the World Around Them

Initiate reliable, stable communication between SWFs and the containers that love them using Flash 8's new ExternalInterface class.


advertisement
hen I was a boy, I used to walk miles to school in the sleet and snow—uphill in both directions. The days of yore weren't much easier when we aging developers were cutting our teeth on Flash/JavaScript communication. We had to deal with a messy collection of kludges and workarounds that, all together, still wouldn't work in the majority of contemporary browsers.

You kids today have it easy. Why, Flash 8's new ExternalInterface class makes getURL("javascript:"), fscommand , and LocalConnection hacks a distant memory.

Introducing ExternalInterface
ExternalInterface was developed as a standard, reliable method for Flash SWF files to communicate with their hosts. In the familiar browser world, ExternalInterface gets around hazily supported technologies like LiveConnect by using ActiveX in Windows IE and the new NPRuntime interface in other browsers. Developed by a group of today's leading browser and plug-in developers, nearly all modern browsers support NPRuntime with the exception of Opera. However, Opera engineers contributed to the development of NPRuntime and Opera support is coming soon.



Additionally, ExternalInterface will work with other host languages, theoretically improving communication with potential SWF containers like projectors, Director, and other rich applications developed in languages such as C#, C++, or just about any other host that can use embedded Flash files.

Stability and compatibility aren't the only improvements, either. In the past, approaches such as fscommand were limited in the number, size, and types of data sent to and from Flash. Commands were required, arguments were limited, and data had to be converted into, and back from, strings. Using ExternalInterface, you are free to use any number of arguments with any names, you can use a variety of data types (including Number, Boolean, Array, and more) and you can receive synchronous return values after each communication, if desired.

All of this is also surprisingly easy to use.

HTML
I'll begin explaining the steps required to use ExternalInterface by focusing on Flash/JavaScript communication and discussing the familiar aspects of the host file, beginning with HTML.

The first piece of the puzzle is placing the SWF in the HTML page. What follows is a standard object/embed tag group created by Flash, albeit simplified a bit for space. This allows you to focus on the key elements of this tag group: the allowScriptAccess, id, and name parameters seen below:

1 <object classid="clsid:d27cdb6e-ae6d-11cf-96b8 444553540000"
codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=7,0,0,0" width="320"
height="240" id="mySWF"> 2 <param name="allowScriptAccess" value="sameDomain" /> 3 <param name="movie" value="mySWF.swf" /> 4 <embed src="mySWF.swf" width="320" height="240" name="mySWF" allowScriptAccess="sameDomain"
type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" /> 5 </object>;

The allowScriptAccess parameter allows your SWF to be scripted by an outside source. There are a few settings for this parameter but, for brevity, I'll use sameDomain to both allow script access but maintain a significant degree of security. This will only allow script calls from the same domain at which the SWF resides. This prevents outside host pages that may be embedding your content from controlling the file.

The object id attribute and embed name attribute are both used to identify which SWF you want to control with your script. I'll show you how to find the necessary SWF using JavaScript in just a moment.

The next portion of HTML is the call to the JavaScript you'll be using. This is for JavaScript-to-Flash communication. Any valid invocation of JavaScript will work. Most commonly, the javascript: protocol or an onClick event handler are used. However, one function may call another, intervals and timeouts may be used, and so on.

<a href="javascript:containerToFlash('Hello')">Hello</a>;

Finally, any type of recipient for Flash-to-JavaScript communication can be established. In this example, I'll use a simple form element to display a string sent from Flash. However, as in the case of outgoing calls, many approaches may be used to store incoming data. For example, variables may be populated or data can be routed to other recipients, such as frames, windows, other functions, other server submissions, etc. (Note that the JavaScript form action used below is just for improved HTML validation. It is not a part of the ExternalInterface process.)

1 <form action="javascript:void(0)" name="fromFlash"> 2 <textarea rows="5" cols="50" name="flashMessage"></textarea> 3 </form>;



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap