Sams Teach Yourself Visual J++ 6 in 21 Days
(Publisher: Macmillan Computer Publishing)
Author(s): Rick Leinecker
ISBN: 0672313510
Publication Date: 11/01/98

Constructors

Seasoned C++ programmers are probably looking for a constructor in which they can initialize their variables. Java provides one, probably for us old C++ salts. The constructor is named after the applet. For our Hello1 applet it would be a method named Hello1(). Although some might not agree (personal habits vary widely), the constructor is a good place in which to initialize variables. Assigning values to variables in the constructor and declaring variables at the top of the applet separates them for clarity and gives you one place to check when things aren’t what they should be.

---

Note:  All Java classes might or might not have constructors—it’s up to the programmer who creates the class. When a class is instantiated, such as when it’s created from a program that’s going to use the class, the first method that’s called is the constructor (unless the class has no constructor). These methods are called constructors because they’re technically part of the class construction process.

---

Here’s what the beginning of an applet with applet variable declarations and variable initialization in the constructor would look like:

public class Hello1 extends Applet
{
    int x, y;
    int nHorizontal, nVertical;

    // Hello1 Class Constructor
    //-------------------------------------------------------
    public Hello1()
    {
        x = 5;
        y = 20;
        nHorizontal = x * 2;
        nVertical = y * 3;
    }

    // Place other methods here.

}

The init() Method

The next of the common methods that will be called is the init() method. The init() method is called by the Virtual Machine when an applet is first loaded or reloaded. Use this method to perform whatever initialization your applet needs, such as initializing data structures, loading images or fonts, creating frame windows, setting the layout manager, or adding user interface components.

The init() method is where most programs retrieve parameters. Actually, Visual J++ creates startup code inside of the init() method that calls a method named usePageParams(). The usePageParams() method loads and processes all the HTML parameters. The usePageParams() method is not an override of a method. It’s just a convenient method that Microsoft’s Visual J++ adds.

The start() Method

In a multithreaded applet, the start() method comes next in the sequence of events. It’s in this method that the main applet is created and started. You can add your own code in this method, but you’ll need some basic things. Following is a bare-bones start() method for a multithreaded applet:

public void start()
{
    if( m_Params == null )
    {
        m_Params = new Thread( this );
        m_Params.start();
    }
    // Place additional applet start code here
}

The run() Method

After the start() method is called, the thread begins execution. The program will remain in the run() method until an interruption is detected. In the run() method, repaint() and sleep() are usually called. For most applets, repaint() won’t need to be called every time you go through the loop. You’ll most likely call the repaint() method only when the applet’s display will change as a result of something your program’s code has done.

The value passed to the sleep() method determines the amount of time the applet waits before executing the code in the run() method. Its value is in milliseconds. If the value passed to sleep() is 1000, the sleep() method waits one second before returning control to the applet. If the value is 500, it waits a half second before returning control. A good default value is 50. A bare-bones run() method follows:

public void run()
    {
        while( true )
        {
            try
            {
                // Do stuff here
                Thread.sleep(50);
            }
            catch (InterruptedException e)
            {
                // Place exception-handling code here in case an
                //       InterruptedException is thrown by Thread.sleep(),
                //         meaning that another thread has interrupted
                           this one
                stop();
            }
        }
    }

The stop() Method

When the applet is interrupted, usually by the browser going to another site, the stop() method is called. The thread is destroyed, and you have the opportunity to perform additional steps you might want to take for applet cleanup. Here’s a bare-bones stop() method:

public void stop()
{
    if( m_Params != null )
    {
        m_Params.stop();
        m_Params = null;
    }
    // Place additional applet stop code here
}

The destroy() Method

The destroy() method is called automatically when the applet is terminated. It’s still a good place to put all of your cleanup code because all the exit code will be organized in one place. For this reason, your stop() method should call destroy() after the thread is stopped. You can avoid any code except for the call to destroy() in the stop() method.

You might have some difficulty because destroy() might not be executed as early in the cleanup process as you’d like. A good example from my own programming is a situation in which I have sockets that are open. The applet is far more robust when the sockets are closed immediately as users exit the applet. If there’s any kind of delay in closing the sockets, users can actually come back to the HTML page and rerun the applet. If the sockets are slow to close, the newly instantiated applet will fail when it tries to open these sockets that haven’t yet closed.

It’s okay to explicitly call this method.