Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Java Tip 101: An alternative way for applet-to-applet communication

Learn how to let your applets speak across frames and browser window boundaries

By Tobias Hill, JavaWorld.com, 09/01/00

• The applets originate from the same server and from the same directory on the server.
• The applets are running on the same page and in the same browser window.

Those security restrictions may have been designed that way for good reason; however, the latter requirement limits the ways you can make interesting multiapplet interfaces featuring applet-to-applet (a2a) communication.

Imagine the following scenario:

You have just finished writing a nice stock-market-trade applet and decide to write an even nicer help system for it. You also want the help system to be an applet and to be placed in a different browser frame than the stock-market-trade applet. Your motive for that decision could be based on structural concerns of your Website or the need to always keep the help system on display. In addition, you want to make the help system change to the correct information/guides based on what the user is doing in the stock-trade applet (much like the paper clip in the Microsoft Office suite). You even plan to make wizards within the help system that can remotely point out things and perform tasks in the stock-market-trade applet.

The idea behind that scenario is good. However, since the applets are located on different pages, the Java API in AppletContext will not help you develop the idea completely -- but this tip will.

Using the AppletContext API

Before I explain the alternative a2a-communication mechanism, I will briefly show how the getApplet and getApplets methods work. An applet can find another applet in the same HTML page by either using the getApplet method to look it up by name or using the getApplets method to find all the applets on the page. Both methods, if successful, return one or more Applet objects to the caller. Once the caller finds an Applet object, it can invoke the Applet's public methods.

Suppose that a snippet of the HTML page looks like this:

    <applet code="Applet1" width="400" height="100" name="app1">
    </applet>
    <br>
    <applet code="Applet2" width="400" height="100" name="app2">
    </applet>
    <br>

By using the name attribute in the applet tag, you can refer to a specific applet in the following way:

    Applet theOtherApplet = getApplet("app1");
    theOtherApplet.anyMethod(); //calling any public method

Or, you can use the following code to retrieve all applets on the page:

    Enumeration allAppletsOnSamePage = getApplets();
    while(allAppletsOnSamePage.hasMoreElements()) {
        Applet appl = (Applet) allAppletsOnSamePage.nextElement();
        appl.anyMethod();       //Calling any public method
    }

When the calling applet has retrieved one or several applets on the same HTML page, it can call those applets' public methods.

Using a static data structure

Unfortunately with the standard approach, you are limited to communicating only with applets in the same HTML page. Luckily, you can circumvent that limitation very easily. The way you make a2a communication over page boundaries is based on the fact that two applets, even though loaded in different browser windows, will share the same runtime environment if their codebases are the same. Roughly speaking, the codebase is the directory from which the applet was loaded. See Resources below for a link to a tutorial on codebases.