Whenever the browser needs to draw the page containing this applet, it tells the applet to draw itself by calling the paint() method. For simplistic applets, this calling protocol between the browser and your applet might be all that you need, but for more complex applets (for example, those using animation), this approach is too limited. In fact, the browser calls many Applet methods that were not overridden here, so only a small subset of the full browser-applet protocol was used.
For starters, the browser calls the init() method to initialize an applet. There was not an init() method in the simple example nothing needed to be initialized. But if your applet has any initalization to do (namely, code it needs to execute only once, at the start of its execution), it should put all this code in an overridden init() method. Here is an example that overrides the init() method:
Import java.awt.Graphics;
Import java.unil.Date;
Public class Applet2 extend.java.applet.applet.Applet { String message;
Public void init () {
Date date = new Date (System.currentTmeMillis());
Message = “I was born at: “+ date.toString();
}
public void paint (Graphics g) { g.darwsting (message, 10, 20);
} }
In addition to the paint() method responsible for the redrawing of the applet, you now
applet is displayed. In this example, the init () method records the date and time at the moment the applet is initialized and converts this to a string that the paint() method will use to draw this frozen time when the applet needs to be redrawn.
Graphically printing a string is done with the Graphics drawnString() method. It takes a string and the coordinates for the string’s position.
The browser invokes three more methods on an applet during an apples’ts life cycle:
Start() When the applet’s HTML page comes into view or the browser is deiconified Stop() When the applet’s HTML page is left or the browser is deiconified
Destroy() When the browser’s garbage collector determines the applet is no longer necessary to keep in memory
To see the full browser-applet protocol in action, type in the following program, compile it, and tell your favourite Wed browser to load a Wed page with the applet embedded in it.
Make sure you browser shows “Java console output.” On Net-scape’s Navigator browser, you enable this by selecting Show Java Console in the program’s Options menu. For Internet Explorer, it actually logs output to disk instead of sending it to the console.
Here’s the code:
Import java.awt.Graphics;
Public class AppletLife extends java.applet.Applet { Public void inti() {
System.out.printIn(“browser wants me to : initialize mysef”);
}
public void stop () {
System.out.printIn(“browser wants me to : start running”);
}
public void paint (Graphics g) {
System.out.printIn(“browser wants me to : stop runnung”);
}
public void destroy () {
System.out.printIn(“browser wants me to : clean up before being removed.”);
} }
The first time load HTML page, you should see the following output printed to the Java console:
Browser wants me to: intialize my self Browser wants me to: strat running Browser wants me to: redraw myself
This means the init(),star(), and paint() methods are always called when an applet is first loaded and run. The sequence can differ from what is listed here; due to asynchronous aspects of the protocol, the paint() method can legally be called before the start() method. The init() method, however, is guaranteed to be called before all others.
Now, whenever the browser window needs to repaint itself-for example, after having been obscured by another window overlapping it-you should see an additional:
Browser wants me to: redraw myself
This is because the browser needed to completely redraw itself to undo the graphically inconsistent picture it was showing.
Remember that the entire GUI desktop metaphor your machine maintains is just a clever, graphical illusion. Any computer has a flat, uniform screen bitmap that doesn’t enforce or care about these “overlapping” and clipping rectangular rectangular areas called “windows.”
The “nutural behaviour” of a computer screen in much more like that of a painting canvas in a painting program: The canvas has no restrictions whatsoever. In a GUI environment, then when windows are depth-arrange in this plain bitmap environment, it means some windows will be partially or entirely overwritten, while others will need to redraw themselves. Since your applet is part of a window, it too must play along to maintain the illusion. If not, your applet will soon become graphically corrupted, or more likely, erased completely. This is why it is important to have an applet repaint itself using the paint() method whenever the browser commands it to (and as quickly as possible, as always).
If you load a different Wed page in your browser or just codify it, you should see your applet print the following line:
Browser wants me to: stop running
You will probably wonder what this means since your applet was not executing any code at the anyway. Think about the kind of applications can be used for-animation, real-time updating of information fetched from an internet server, general entertainment, and so on. All these types of applets are real-world applets, and they are very different from what has been demonstrated so far in this book. Real-world applets usually run constantly.
To illustrate, imagine that the start() method in your last applet never ended because it had to animate something all the time. Such an applet would be very wasteful of processor resources if it kept on animating even after the user switched to a different page. Yet that is exactly what would do if you didn’t take any steps to ovoid this problem; the way to avoid the problem is by using threads.
In Chapter8, you saw how threads allow you to do several things at the same time.
Imagine all of an applet’s core processing and functionality (the animating, for example) being run in a separate thread. This way, whenever the applet’s page is displaced by a new page, you can simply freeze the thread, and when the applet’s page is reloaded, you can let the thread run again; this is the real purpose of the start() and stop() methods of Applet. They assume that all your applets are written with multithreading in the first place. In later chapters, you will learn how to actually write applets built around a thread, but for now, just keep in mind that start() and stop() are really meant to control applet threat so that they do not consume processor resources while they are not in view.
If you now click on your browser’s Back button to revisit the page with our applet, or deiconify the browser, you will see the console print:
Browser wants me to: start running Browser wants me to: redraw myself
Because the browser assumed your applet thread had been put to sleep when you switched pages, it now asks your applet to wake up the thread again, immediately followed by an request to repaint the applet. This is because the applet’s façade was overwritten a long time ago by the previous page and any of its applets.