Converting Applications to Applets

As luck would have it, the bit that I am particularly interested in, Converting Applications to Applets, crops up quite early in the getting started with Applets lesson. The section opens with a paragraph on the technical differences between an application and an applet, and then goes on to outline what it calls the "basic steps ... to convert an application program into an applet program.". I quote:

• You need to create a subclass of java.applet.Applet in which you override the init method to initialize your applet's resources the same way the main method initializes the application's resources.
• init might be called more than once and should be designed accordingly. Moreover, the top-level Panel needs to be added to the applet in init; usually it was added to a Frame in main. That's it!

When I read the words "That's it" after two short bullet points, I am lead to believe that what is being explained is pretty simple, and that the conversion will comprise inserting a few words here and there. But after reading these bullets I felt none the wiser.

I therefore take advantage of the invitation to compare the source code of an application with that of an applet. I open both source code files and paste the content side by side into two columns of a spreadsheet. This makes the comparison much easier, and I can begin see the differences referred to in the text.

The first bullet point above opens with: "You need to create a subclass of java.applet.Applet ... ". And at the top of the applet source code, where packages are imported, I note an extra line:

import java.applet.Applet;

And after that, where the application declares the following class:

class SwingUI extends JFrame   
implements ActionListener {

the applet declares:

public class ApptoAppl extends Applet   
implements ActionListener {

So far so good, but as I skim through the rest, simple comparisons escape me. I therefore turn back to the lesson, where I find the two initial bullet points (which were supposed to be "it") have been replaced or embellished but five more:

• The applet class is declared public so appletviewer can access it.
• The applet class descends from Applet/JApplet and the application class descends from Frame/JFrame.
• The applet version has no main method.
• The application constructor is replaced in the applet by start and init methods.
• GUI components are added directly to the Applet; whereas, in the case of an application, GUI components are added to the content pane of its JFrame object.

The first two of these seems to correspond to the first subclause of the first of the two bullets, and to be illustrated by the snippets of code shown above. The third seems to correspond to the last subclause of the first of the two bullets, and is confirmed when I scroll to the bottom of the source files, and note that the main method is certainly missing from the applet.

The fourth bullet refers to the "application constructor". I'm not sure that my application has a constructor, but the term rings a bell from the theory lessons, so I'd better go back and check what it means. Turns out that I wrote quite a bit on the subject in September, and by the look of it I didn't enjoy those lessons any more than this one.

Feeling bored, I compile both source files into classes and run them. To my surprise both run OK. This was quite interesting for me as an exercise because I had never before applied Swing outside NetBeans. It is also a bit easier for me to interpret the code, knowing what the app looks like. And even the constructor makes a bit more sense in the context of a GUI. More sense at least than it did with my bicycle. The constructor applies values to variables, or objects, and when the objects are components on a form, the name makes more sense, because it "constructs" the form.

In the application the "constructor" puts a label and a button on something called a jpanel. In the applet, the init method appears in place of the constructor, and that is where the text box and button are created. It is irritating in an example like this where one is trying to compare two things that the order is inconsistent. In the App, the button and label are created before the jpanel. In the applet, the jpanel is replaced by a BorderLayout, which is a substantive (but unlisted and unmentioned) difference between the two, but to confuse the learner, in the applet, the BorderLayout is defined before the button and label. To confuse the reader even further, bullet point five refers to a JFrame, of which there is none in the application.

In the applet, the Init method is followed by the Start, Stop and Destroy methods. These all include a System.out command. It is not clear whether these are required, or simply put in as a distraction.

Further down the page, the button ( public void actionPerformed(ActionEvent event) code is identical in both App and Applet. This is quite heartening, because in most apps (and certainly in mine) that is where the crunchy code is written. So at least that much can be copied and pasted.

In summary, I wouldn't really call this process converting an application to an applet, so much as comparing and contrasting an application with an applet. Certainly I am not convinced that there is an easy way to "convert" my application to an applet. I can see how I can reuse some of my code, but I think the first step will be to create an applet from scratch, and then perhaps I can splice in reusable code.