ActionScript: getURL vs. ExternalInterface – When & Why

This post all stems from a project I’ve been working on very recently, making a drop-down menu in flash, that sits in a HTML page. What we’re talking in relation to here is, getting flash to execute JavaScript DOM functions.

Now, there are couple of ways for Flash to interact with its host page. The first one that springs to mind is getURL(), the same function that enables flash to load webpages. The second requires a little more preparation, and is ExternalInterface.call(). Both have an upside and both a downside. One’s old-school and one’s new-school. There are however, real reasons why you should use one instead of the other in different situations.

getURL

  • getURL takes advantage of the abilities of your browser. After all, http: isn’t the only thing your browser can do. You can (amongst other things) call javascript directly. So, instead of passing a new url through the getURL function, you could pass a javascript function, which would execute on the page. You could, theoretically, pass an entire javascript function as a single string, and execute javascript on your html page – without the function existing in the html.
  • The downside to this is that getURL overrides anything the browser is trying to execute. So, if you’ve got a stack of javascript functions that are executing, getURL will effectively kill them. – Once flash executes the getURL function, kiss your other functions goodbye.

ExternalInterface

  • ExternalInterface is an ActionScript 2 ‘gateway’ for JavaScript / ActionScript communication. As well as it’s ability for two-way communication, ExternalInterface doesn’t kill off other scripts running in the browser.
  • The downside, from a flexibility point-of-view is that ExternalInterface can only call existing functions in either language, it can’t create them on the fly. Which is more secure, I suppose.

So, to summarise:

getURL: Kills running scripts, but doesn’t need a named function to exist

ExternalInterface: Doesn’t kill running scripts, but does need a named function to exist

, , ,

About James

James is a Senior New Media Developer at MMT Digital, and has BA(Hons) in Design for Interactive Media from the University of Gloucestershire. He loves designing and producing all sorts of website and Flash-related things, as well as prattling on about technologies.Day-to-day he works with Flash, Dreamweaver, Director, Microsoft Office Sharepoint Server 2007 (MOSS) and in his spare time he mucks about in Flex and Wordpress.Follow James on Twitter.

Connections and Related Posts

You can connect with Psyked.co.uk through other media using these links:

13 Responses to “ActionScript: getURL vs. ExternalInterface – When & Why”

  1. Terry Coatta 12th October, 2007 at 8:39 pm # Reply

    Has anyone had any experience with getting ExternalInferface to work with SWF’s that are embedded in PDF documents. ExternalInterface.available returns true, but I haven’t found the way to call a function exposed by the addCallback() method.

  2. James 13th October, 2007 at 6:09 pm # Reply

    I haven’t really had any experience using SWF’s in PDF documents. In the ExternalInterface documentation they only ever mention webpages – assumedly because they can run JavaScript. But they do mention that other scripting languages’ functions can be called, such as VBScript or even C#.

    From what I understand, the addCallback() method should execute any named function in the document that hosts the swf file – are you sure that you can execute scripts in this fashion within PDF documents? Perhaps this is a question for the FlashCoders mailing list…

    Here’s a few things I looked into, but I don’t think any of them answer your question directly;

    Using the ExternalInterface

    ExternalInterface.addCallback()

    Embedding Flash in PDF files

  3. Terry Coatta 13th October, 2007 at 9:54 pm # Reply

    PDF’s have a facility for executing Javascript and I have seen other comments that the ExternalInterface features work from C# and VB when you embed a PDF via an ActiveX control. So, I think the basic capabilities are there.

    The main issue is how to access the ExternalInterface stuff from the Javascript running in the PDF. We haven’t figured out what object to access in order to call the method added via addCallback() for example. Similarly when we try the call() method, it always fails… it’s seems like the names of the Javascript functions in the container may be mangled in some way.

    BTW – We do have fsCommand() working to send information from the SWF to the containing PDF Javascript code. What we really need now is the other direction (to call from the container into the SWF).

    Terry.

  4. James 15th October, 2007 at 8:44 pm # Reply

    Wow. I’m afraid I have no idea on this one… let me know if you make any progress though!

  5. James 20th October, 2007 at 11:37 am # Reply

    It’s a long shot, but have you tried using the fully-quallified classnames for the FSCommand / ExternalInterface?

    I know there’s not supposed to be a difference, but I’ve encountered some issues with Firefox – the ExternalInterface commands not executing unless I used the full flash.external.ExternalInterface.call() – and yet still working fine in Internet Explorer.

    I wonder if the PDF problems could be something similar?

  6. Terry Coatta 20th October, 2007 at 5:38 pm # Reply

    I’ll give that a try.

    Thanks!

    Terry.

  7. Victor S. 17th March, 2008 at 6:06 pm # Reply

    sorry for the bump…

    u said that “We do have fsCommand() working to send information from the SWF to the containing PDF Javascript code.” ….

    but i cant find any info on this and icant get it to work… can someone give me an example?

    thanx

  8. Terry Coatta 20th March, 2008 at 11:14 pm # Reply

    We just use:

    fscommand(cmd);

    in the Flash code. ‘cmd’ is a line of JavaScript that will be executed by the JavaScript interpreter running within the PDF document. If you have defined JavaScript functions in hte document, you should be able to call them.

    Terry.

  9. me 20th August, 2008 at 10:47 am # Reply

    Hi,

    A bit of a late reaction but in your article you state that ExternalInterface does need a named function to exist.
    This is a common misconception, as explained in .

  10. James 20th August, 2008 at 11:12 am # Reply

    @me – that JavaScript injection article (http://www.actionscript.org/resources/articles/745/2/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page2.html) is quite interesting – and a neat hack, which could prove useful in certain situations…

  11. dmitry 21st February, 2009 at 2:29 am # Reply

    THANK YOU SO MUCH JAMES!
    flash.external.ExternalInterface.call(“alert”, “ALERT”);

  12. jeff 14th September, 2009 at 6:55 pm # Reply

    Hello-

    James, thank you for the insight into the ExternalInterface function. I am trying to get actionscript to communicate w/ javascript. The situation is: I have an aspx page, w/ a login and password at the top and a flash movie as the main active area. When user clicks on a btn in the main area, I need to call javascript from flash to check if user is logged in already or the id and password are valid. From what I know to keep it on the client-side, ExternalInterface is the best option. I thought using this w/in a btn to receive a value through a string, then based on the value returned have an if/else conditional to navigate to the proper frame label…either please login with your username and password, or grant access and go to the appropriate frame. Could you help fill in the blanks? Thanks…..

    -Jeff

  13. Brad 8th June, 2010 at 6:38 pm # Reply

    Hi James,

    I know it’s an old article, but great stuff.
    Have you tried calling getURL from flash (or Captivate, etc) inside a ConnectPro environment to make JS calls? I have a function working great in Firefox and Chrome, but the function does not fire in Internet Explorer. As usual trying to make things work in IE is 80% of my work :) . Any ideas?

Leave a Reply

Note: This post is over 4 years old. You may want to check later in this blog to see if there is new information relevant to your comment.