Free Online Courses for Software Developers - MrBool
× Please, log in to give us a feedback. Click here to login
×

You must be logged to download. Click here to login

×

MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation

×

MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation

Writing a Simple Java Applet

In this post, you will extend your knowledge of applets by looking more closely at the construction of an applet, as well as discovering some other methods that are important to Java applets.

The Simplest Java Applet

The Java programming language and libraries enable you to create applets that are as simple or as complex as you like. In fact, you can write the simplest Java applet in only a few lines of code, as shown in Listing 1.

Listing 1 MyApplet.java: The Simplest Java Applet.
import java.applet.*;
public class MyApplet extends Applet
{
}

The first line of Listing 1 tells the Java compiler that this applet will be using some or all of the classes defined in the applet package (the asterisk acts as a wildcard, just as in DOS file names). All of the basic capabilities of an applet are provided for in these classes, which is why you can create a usable applet with so few lines of code.
The second line of code declares a new class called MyApplet. This new class is declared as public so that the class can be accessed when the applet is run in a Web browser or in the Appletviewer application. If you fail to declare the applet class as public, the code will compile fine, but the applet will refuse to run. In other words, all applet classes must be public.
As you can see, you take advantage of object-oriented programming (OOP) inheritance to declare your applet class by subclassing Java's Applet class. This inheritance works exactly the same as when you created your own classes as you can see in the post "Classes in Java - Introduction and Practical Examples". The only difference is that Applet is a class that's included with the Java Developer's Kit (JDK), rather than a class you created yourself.
You can actually compile the applet shown in Listing 1. When you do, you'll have the MyApplet.class file, which is the byte-code file that can be executed by the Java system. To run the applet, just create an HTML document like the one shown in Listing 2. If you need a refresher course on using the tag, take a look in the post "Running Java Applets." If you were to run the MyApplet applet, however, you wouldn't see anything much in Appletviewer or in your Web browser.

Listing 2 MYAPPLET.htmL: MyApplet's HTML Document.
Applet Test Page

Applet Test Page

code="MyApplet.class"
width=250
height=250
name="MyApplet">

The Five Stages of an Applet's Life Cycle


Every Java applet you create inherits a set of default behaviors from the Applet class. In most cases, these default behaviors do nothing, unless you override some of Applet's methods in order to extend the applet's basic functionality. However, although a simple applet like MyApplet in Listing 1 doesn't seem to do much, a lot is going on in the background. Some of this activity is important to your understanding of applets, and some of it can stay out of sight and out of mind.
Part of what goes on in a simple applet is the execution of the applet's life cycle. There are five parts to this cycle, each of which has a matching method that you can override to gain access to that cycle of the applet's life. The five stages of an applet's life cycle are listed here:

Initialization stage. This is the part of an applet's life cycle in which the applet object is created and loaded. At this point, it's appropriate to create objects needed by the applet, as well as initialize values that must be valid when the applet runs. The initialization stage occurs only once in the applet's life cycle. You can tap into the initialization stage by overriding the Applet class's init() method.

Start stage. This stage occurs when the system starts running the applet. The start stage can occur right after the initialization stage or when an applet is restarted. This usually happens when the user switches back to the applet's page after viewing a different page in his or her Web browser. Unlike the initialization stage, the start stage can occur several times over the life of the applet. To provide your own start code, override the Applet class's start() method.

Paint stage. The paint stage occurs whenever the applet's display must be drawn on the screen. This happens right after the applet's start stage, as well as whenever the applet's display must be restored or changed. This can happen when the applet is exposed from underneath another window or when the program changes the applet's display in some way and explicitly repaints the applet. Almost every applet you write will have a paint() method, which is the method you override to provide your applet with its display.

Stop stage. As you may have guessed, the stop stage is the counterpart to the start stage. Java executes this stage of the applet's life cycle when the applet is no longer visible on the screen, such as when the user switches to a different Web page. The default behavior for this cycle, however, is to keep the applet running in the background. If you want to handle the stop cycle differently, you should override the Applet class's stop() method.

Destroy stage. This is the counterpart to the initialization stage and occurs when the system is about to remove the applet from memory. Like the initialization cycle, the destroy cycle occurs only once. If your applet has resources that need to be cleaned up before the applet exits, this is the place to do it. You tap into this cycle by overriding the Applet class's destroy() method. 
   
NOTE

To be entirely accurate, the paint stage isn't considered an actual applet life cycle, but because an applet without a display is likely useless (not always, though), I thought I'd include the paint cycle. Truth is, the paint() method isn't even defined in the Applet class. Rather, Applet inherits paint() from the Component class, a superclass in Applet's long chain of inheritance, which goes from Applet to Panel to Container and finally to Component.

Example: Overriding the Life Cycle Methods


All this talk about life cycles and overriding methods may have left you a little confused as to how all this actually applies to the applets you want to create. In previous chapters, you managed to create applets without dealing with most of this stuff because the Applet class, from which you derived your own applet classes, handled the life-cycle methods in the default manner proscribed by the Java system. If you look at Listing 3, you'll see a small applet that overrides all the methods needed to provide custom behaviors for all the applet's life-cycle stages.

Listing 3 MyApplet2.java: Overriding the Applet Life-Cycle Methods.
import java.applet.*;
import java.awt.*;
public class MyApplet2 extends Applet
{
public void init()
{
// Place initialization cycle code here.
}
public void start()
{
// Place start cycle code here.
}
public void paint(Graphics g)
{
// Place paint cycle code here.
}
public void stop()
{
// Place stop cycle code here.
}
public void destroy()
{
// Place destroy cycle code here.
}
}

Notice that in order to override the paint() method, you must import the java.awt.* libraries, which contain information about the Graphics class. As you learned when writing previous applets in this book, the Graphics class enables you to display information and graphics in an applet's display area (or canvas, as the display area is sometimes called).
If you look for the previous methods in Java's source code, you'll discover that the default implementations of init(), start(), paint(), stop(), and destroy() all do nothing at all. If you want your applet to do something in response to these cycles, you have to provide the code yourself by overriding the appropriate method.



MrBool is a totally free website made for software developers. Our articles and courses are totally free with focus on useful techniques and best practices

What did you think of this post?
Services
[Close]
To have full access to this post (or download the associated files) you must have MrBool Credits.

  See the prices for this post in Mr.Bool Credits System below:

Individually – in this case the price for this post is US$ 0,00 (Buy it now)
in this case you will buy only this video by paying the full price with no discount.

Package of 10 credits - in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download few videos. In this plan you will receive a discount of 50% in each video. Subscribe for this package!

Package of 50 credits – in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download several videos. In this plan you will receive a discount of 83% in each video. Subscribe for this package!


> More info about MrBool Credits
[Close]
You must be logged to download.

Click here to login