Finishing an Applet

When is your applet finished? When it works and meets at least the minimum standards described in the following section. Some higher standards we'd like you to meet are described in the section The Perfectly Finished Applet (page 455).

Before You Ship That Applet

Stop! Before you let the whole world know about your applet, make sure that the answer to all of the following questions is yes.

1. Have you removed or disabled debugging output?

   Debugging output (generally created with System.out.println), although useful to you, is generally confusing or annoying to users. It also can slow down your applet. If you need to give textual feedback to the user, try to do it inside the applet's display area or in the status area at the bottom of the window. Information on using the status area is in the section Displaying Short Status Strings (page 425).

2. Does the applet stop running when it's off-screen?

   Most applets should not use CPU resources when the browser is iconified or is displaying a page that doesn't contain the applet. If your applet code doesn't launch any threads explicitly, you're probably okay.

   If your applet code launches any threads, unless you have a really good excuse not to, you should implement the stop method so that it notifies the threads that they should stop. For an example of implementing the stop method, see the section Using a Thread to Perform Repeated Tasks (page 451).

3. If the applet does something that might get annoyingplay sounds or animation, for exampledoes it give the user a way to stop the annoying behavior?

   Be kind to your users. Give them a way to stop the applet in its tracks, without leaving the page. In an applet that otherwise doesn't respond to mouse clicks, you can do this by implementing the mouseClicked method so that a mouse press suspends or resumes the annoying thread. For example:

   boolean frozen = false; //an instance variable 
   
   public void mouseClicked(MouseEvent e) { 
    if (frozen) { 
    frozen = false; 
    start(); 
    } else { 
    frozen = true; 
    stop(); 
    } 
   } 

The Perfectly Finished Applet

The previous section listed some rules you should follow to avoid making your applet's users want to throttle you. This section offers tips that can make dealing with your applet as pleasant as possible. Some of the tips here aren't easy to implement. Still, you should be aware of them and implement what makes sense for your applet.

1. Test your applet well.

   Before you unleash your applet on the world, test it thoroughly. Once it works well in your normal browser/platform combination, run it in as many browser/platform combinations as you can find. Ask people whose computers are behind firewalls to test it. Take advantage of the Web; you can usually get other people to perform much of the testing for you.

2. Make sure that your applet follows the 100% Pure Java guidelines.

   Throughout this tutorial, you can find tips on how to make programs work well on any Java platform.

3. Use parameters to make your applet as flexible as possible.

   You often can define parameters that let your applet be used in a variety of situations without any rewriting. See the section Defining and Using Applet Parameters (page 433) for information.

4. If your applet has more than one file, consider providing an archive.

   See the section Combining an Applet's Files into a Single File (page 441) for information.

5. Make your applet appear as soon as possible.

   Applets can do several things to decrease their perceived startup time. The Applet subclass can be a small one that immediately displays a status message. Some or all of the applet's files can be compressed into an archive file to decrease total download time. If some of the applet's classes or data aren't used right away, the applet can either delay loading them until they're needed or use a background thread to load them. If you can't avoid a lengthy delay in your applet's startup, consider using a small helper applet nearby to give status.

6. Make your applet adjust well to different sizes, different available fonts, and different platforms.

   Applets don't always get all the screen real estate they want. Also, the amount of space required to display your applet's UI can be affected by platform/machine variances in font availability, drawing techniques, resolution, and so on.

   By using layout managers wisely, you can make your applet adjust well. If your applet has a minimum required size, you can use the getSize method to check whether your applet is big enough. If your applet or custom components in it draw text using graphics primitives, you should check and adjust font sizes.

7. If your applet can't do its job, make it fail gracefully.

   Sometimes, your applet doesn't get the resources it needs. It might get so little space that it can't present a meaningful user interface. Or it might not be able to connect to a server. Even if your applet can't adjust successfully to the lack of resources, you should at least attempt to make your applet fail gracefully. For example, you might display a visible messageeither in the applet's drawing area or in a helper applet near itthat explains what happened and gives hints on how to fix the problem.

8. Be wary of using text in images.

   Although using images to draw text can result in good-looking, predictably sized text, the result may be illegible on some low-resolution displays.

9. Use windows wisely.

   Windows have good points and bad points. Some platforms, such as TV-based browsers, might not allow top-level windows. Also, since applet-created windows can take a while to appear, they can be disconcerting to the user. However, putting some or all of an applet's UI in a window makes sense when your applet needs more space than it can get in the browser. Using a window might also make sense in the rare case when your applet needs to remain visible even when the user changes pages.

10. Supply alternative text for your applet.

    By using alternative text to explain what your users are missing, you can be kind to users who can't run your applet. You can supply alternative text as described in the section Specifying Alternative HTML Code and Text (page 439).

11. Implement the getParameterInfo method.

    Implementing the getParameterInfo method now might make your applet easier to customize in the future. Browsers can use this method to help generate a GUI that allows the user to interactively set parameter values. See the section Giving Information about Parameters (page 437) for information on implementing getParameterInfo.

12. Implement the getAppletInfo method.

    The getAppletInfo method returns a short, informative string describing an applet. Browsers and other applets can use this to give information about your applet. Here's an example of implementing getAppletInfo:

    public String getAppletInfo() { 
     return "GetApplets by Kathy Walrath"; 
    }