HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Like most web surfers, I just love Java Applets. I love what people are doing with them, and all the nifty new content being developed. Week to week, the number of original and creative applets being added to the Gamelan site, for example, is increasing exponentially (http://www.gamelan.com). At least twice per week I like to go to that site and see what's new.

One thing I can't stand, however, is waiting for other people's applets to start. I mean, I can certainly understand and be tolerant of my own applets, whose many class files must be downloaded not to mention graphics and audio files, which takes time. I must look a little silly, sitting there with baited breath starring at unreactive grey rectangles on my web pages. I know what will eventually show up is worth seeing.

This patience may be due to just a little bit of bias, since I seem to feel any Applet I write is worth waiting for. I can't see why my friends or clients don't immediately share my opinion. The situation seems to go like this: I make some neat-o keen Applet with fancy UI, animation, custom control classes, the works. I happen to be using whatever T1 connection is available to me at the time while I do this development, so applet loading times seem pretty insubstantial. Then I call someone I want to impress (my wife or my mom, most likely) and point them to my URL. More so lately, the sigh of patient, though strained, indulgence I get from the other end of the phone indicates my victim might not enjoy loosing twenty minutes or more waiting for her 28.8K modem to download everything. I imagine other users probably like the delay even less, that is if they are even will to wait at all.

The application initialization delay is not new. A common device is to throw an initialization, or "splash screen", window up to announce your application, and to give the user something to look at while an application loads. Why not do the same thing with applets?

To that end, I'd like to share with you a generic splash screen applet I've developed. The idea is that, whenever you have an applet with potentially long loading and initialization times, it would be best to put up a fancy image or something before that long downloading occurs. Users appreciate that kind of thoughtfulness. Anyway, by giving the user something to look at, it will buy an applet some precious time to perform downloading and initialization.

The FlashSplash applet is a generic splash screen for other applets. When you embed a FlashSplash applet, you specify in the applet's parameters just two things: the URL to a splash screen image to display before loading the target applet, and the name of the target applet class to actually start loading. The FlashSplash applet, upon starting, will download and display the splash screen image before attempting to download and start the target applet. Any applet can be used as a target. Here's sample HTML for a FlashSplash applet that loads an image before loading and starting a target Applet:

<APPLET CODE="FlashSplash.class" WIDTH="400" HEIGHT="300">
<PARAM NAME="splash-SplashImage" VALUE="splash.gif">
<PARAM NAME="splash-TargetApplet" VALUE="MyTargetApplet"> </APPLET>

The trick of the FlashSplash applet is that FlashSplash objects actually act as a proxy AppletStub for the target applet. As you may know, the only way for an applet to communicate with the browser is, ultimately, through the AppletStub interface. (The AppletContext is used also, but it is only through the AppletStub that an applet can get a reference to the AppletContext.) So, The FlashSplash class actually implements the AppletStub interface and hands itself off as an AppletStub to a target applet. The FlashSplash Applet, which is derived from the Panel class also like all applets, also acts as the parent Container for the target applet. The unsuspecting target applet, unaware that its parent Container and AppletStub are actually another applet, merrily runs as expected without too much fuss. (Actually, there are a couple of minor problems, but I'll explain that in a little bit.)

The code for the FlashSplash applet class, which is remarkably simple, is shown in Listing 1. You may notice a little bit of oversimplification where multi-threaded synchronization is concerned, but it makes for much more readable code. I have no doubt an able programmer could make this FlashSplash applet truly thread-safe with minimal effort.

There are two problems with the use of FlashSplash applets with respect to the target applet: First, the FlashSplash and the target applet share a set of parameters. Since the FlashSplash just passes through calls to getParameter( ), then the target Applet has the same parameters the FlashSplash has. This could cause a problem if there were parameter name conflicts. I've tried to minimize that problem by only having two parameters to the FlashSplash applet, and both of them start with the prefix "splash-".

The second, probably more serious, problem is that the target applet is not registered with the browser as a running applet. That means other loaded applet that try to find and communication with the target using AppletContext.getApplet( ) or AppletContext.getApplets( ) will not get a reference to the target applet. Instead, they can only get a reference to the FlashSplash. This is not a horrendous problem, as long as your other applets are aware of FlashSplash. In that case, you could add a getTarget( ) method to the FlashSplash class that the other applets could call to get a reference to the target applet. I leave the addition of that method as a exersize for the reader.

After adding FlashSplash loaders to my web pages, I find it a little easier to convince people to take a look at my applets. I would suggest you do the same for your personal or professional applets.

About the Author
Brian Maso is a programming consultant working out of Portland, OR. He is the co-author of The Waite Group Press's upcoming release The Java API SuperBible. Before Java, Brian spent five years corralled in the MS Windows branch of programming, working for such notables as the Hearst Corp., First DataBank, and Intel. Readers are encouraged to contact Brian via e-mail at "[email protected]" with any comments or questions.


Listing 1

import java.awt.*;
import java.net.*;
import java.applet.*;

public class FlashSplash extends Applet
        implements AppletStub, Runnable {
    // Private member variables
    private String m_strTargetAppletClassName;
    private Applet m_appletTarget;
    private URL m_urlSplashImage;
    private Image m_imgSplash;
    private boolean m_fStarted;

    // In init, a background thread responsible for downloading
    // the target Applet class is created after the splash image is 
    public void init() {
        // Gets splash image URL and target class. This code assumes 
URLs are
        // relative URLs.
        try {
            m_urlSplashImage = new URL(getDocumentBase(),
            m_strTargetAppletClassName =
        } catch(MalformedURLException e) {
            System.out.println("FlashSplash loading problem: " + e);
            m_urlSplashImage = null;

        // Download image.
        try {
            MediaTracker mt = new MediaTracker(this);
            m_imgSplash = getImage(m_urlSplashImage);
            mt.addImage(m_imgSplash, 0);
        } catch(Exception e) {
            System.out.println("Splash image loading problem: " + e);
            m_urlSplashImage = null;

        // Start background thread to download target Applet class.
        Thread t = new Thread(this);

    // start() method passes through to target Applet, if created.
    public void start() {
        if(null != m_appletTarget)
        m_fStarted = true;

    // stop() method passes through to target Applet, if created.
    public void stop() {
        if(null != m_appletTarget)
        m_fStarted = false;

    // destroy() passes through to target Applet, if created.
    public void destroy() {
        if(null != m_appletTarget)

    // In paint, only draw the splash image.
    public void paint(Graphics g) {
        if(null != m_imgSplash)
            g.drawImage(m_imgSplash, 0, 0, this);

    // Runnable interface methods: run.
    // run() is responsible for loading the target applet class
    // and creating an instance.
    public void run() {
        try {
            System.out.println("Target applet: " + 
            Class c = Class.forName(m_strTargetAppletClassName);
            Applet a = (Applet)c.newInstance();
            setLayout(new BorderLayout());
            add("Center", a);
            m_appletTarget = a;
        } catch (Exception e) {
            System.out.println("Trouble loading target Applet class: "
                               + e);
            m_appletTarget = null;

    // Methods of the AppletStub interface. These implementations
    // make FlashSplashes simple proxy AppletStubs. These methods
    // are already implemented sufficiently by inherited implementations
    // from the Applet class: isActive, getDocumentBase, getCodeBase,
    // getParameter, getAppletContext. To be implemented: appletResize
    public void appletResize(int width, int height) {
        resize(width, height);


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.