CS 3230 - Chap 10 Notes

Deploying Applets and Applications

Applet History

History (p.491) - Applets gave Java a lot of its early hype. You may recall from Chapter 1 that the Sun folks were having trouble selling their Java technology. As a "proof of concept" they decided to capitalize on the hype surrounding the Internet by deploying small Java GUI programs (called Applets) through web browsers.

Active content (p.492) - Java Applets can be considered a form of "Active Content". Other examples are Shockwave Flash, JavaScript, and ActiveX controls.

Issues with browsers (p.492) - Netscape did not keep up with current versions of Java in their Navigator browser and Microsoft would either deliberately ship outdated versions of Java with Internet Explorer or drop support completely. This prompted Sun to release the "Java Plug-in" (previously called "Activator") which would download the current version of the JRE from their website.

Intranets (p.493) Java applets have had a limited presence on public web sites, but they have found a home on corporate Intranets.

If you want to look at some real, live Java applets, check out games.yahoo.com for a boatload of examples.

Making an Applet (p.494)

Most Basic Applet (p.494)

To create your most bare-bones applet you need 2 files:

  1. A .java file that contains a class that extends the Applet class. See HelloWorldApplet.java. Of course, you also need to compile the .java file to a .class file.
  2. An HTML file with an APPLET tag in it that gives the name of a .class file that contains an Applet. See hello_world.html. Note the text between the opening and closing tags for non-Java-enabled browsers (see p.505, bottom).

Once you've done that, there are 2 ways to view it (p.494)

  1. Use the appletviewer program that comes with the JDK
  2. View it in a Java-enabled browser

Life Cycle of an Applet (p.498)

There are 4 key methods called durring an applet's lifetime:

You can select the menu items on the appletviewer to call each of these methods (handy for debugging).

Applet Security (p.499)

Applets follow a "sandbox" idea, which means they are restricted from doing numerous things including:

No significant "Applet viruses" have ever been written, despite the gloomiest predictions.

While all of these restrictions make applets much more secure, they also make them very inadequate for many purposes. "Java Web Start" (below) was meant to address some of these shortcomings.

Cute / Stupid / Informative Applet Tricks

Making a popup window (p.500) - An applet can instantiate and show a frame, thus creating a popup window. See PopupCalculatorApplet.java from your book on p.501. (Also uses CalculatorPanel.java.) To see it run, you can click this link.

Making both an applet and an application (p.518) - If you must know, here's how you can do it.

Converting an application to an applet (p.496) - If you want to do this, you can follow the 8 easy steps on p.496.

The APPLET HTML Tag

Positioning Attributes (p.502) - They are basically the same as for the IMG tag. The small bulleted list at the bottom of p.502 gives positioning attributes and the table on p.503 shows the values for the align attribute. The Figure at the bottom of p.503 is worth a thousand words.

Code Attributes (p.504) - These tags specify where the applet can find its .class files and what file format they will be in (JAR file, serialized object, etc.).

OBJECT tag (p.506 middle) - The W3C would rather you use the OBJECT tag because it is designed to be the general-purpose "active content" tag. In fact, the APPLET tag has been deprecated, but its use is still widespread.

Parameters (p.506 bottom) - An applet cannot take command-line parameters as a console app can, so the APPLET tag can contain N optional PARAM tags which have "name" and "value" attributes. The values of these parameters can be accessed from within an applet by calling the getParameter() method (p.507) which takes a String and returns a String.

Accessing resources

Now that you have your applet up and running, you'll want to do something interesting with it.

URL (p.511)

The URL class is used to obtain resources from the server that hosts the applet. Note that, per the security restrictions, you cannot contact any server other than the hosting one ("phone home").

There are two handy methods you can use to retrieve URLs to the host server:

Multimedia

Images (p.512) - You can easily load an image in an applet by calling the getImage() method. Look at the small code snippet on p.512. (If only it was so easy to do in an application...) Then you can display it in the paintComponent() method by calling Graphics.drawImage().

AudioClip (p.512) - Similar to images, you can call getAudioClip() to retrieve an .au (or .wav) file and then call AudioClip.play(). A simpler approach: you can just call Applet.play().

showStatus() (p.514) - This is a handy method that you will probably want to use when loading multimedia files. You can use it to display a message in the status bar.

Communication with the Web Browser (p.514)

The previous multimedia-related methods actually ask the browser to fetch things for us. There are a couple other methods you can use to control the browser.

getAppletContext() (API p.515) - Returns an AppletContext object that you can then use to manipulate the browser.

showDocument() (p.514 bottom) - Use this to load a web page. The only downside is that it will replace the web page that contains the applet. A better alternative is to use the two-argument version to open the page in a different frame.

Source code: Bookmark.java from your book on p.517. (Or, click this link.) Note that it loads web pages in a named frame.

Developments in the Applet World

Since applets were first released out into the wild, some changes have been made in how you can deploy them and what you can do with them.

Packaging

Some techniques for readying applets / applications for deployment.

JAR files (p.523) - If your applet uses numerous classes, you probably don't want to make the user download a zillion little files individually. JAR files are basically ZIP files that contain a bundle of classes (or anything else you want to put in there) so the user only need download a single, big file.

The jar program (p.523) - at the bottom shows some examples of how to use the jar program that comes with the JDK. The table on p.524 shows all the options you can pass to the program (they are very similar to the UNIX tar program.)

Packaging applications (p.525) - Your book describes how to make a JAR file into a self-contained, properly documented, self-running (p.526) program. (The "SwingSet2" demo we looked at is an example of this.)

Java Web Start (p.532)

"Java Web Start" is Sun's solution to overcoming the limitations of applets brought about by the very restrictive "sandbox" security model. The idea here is to make web-deployable Java applications more useful. You might think of these as "Applets Mark II".

Differences from Applets (p.532) - The bulletted list on this page spells out the important differences. The biggest is that you just make a normal application with a frame and a main() method.

JNLP (p.535 top) - The "Java Network Launch Protocol" API allows programs to make use of a limited set of native OS features, such as printing and saving files to the local hard drive (with restrictions). You could think of this as the "Relaxed Sandbox" security model.

Storing Application Preferences (p.544)

This is something that is useful for Java applications, but cannot be used by Applets. ("Java Web Start" applications can store preferences as well.)

Properties API (p.545) - Older API, creates a .properties file made up of key/value pairs. You use the Properties class. See CustomWorld.java for how to save / load preferences (but the app doesn't do anything useful with them).

Preferences API (p.551) - Newer API, designed to overcome shortcomings of Properties (bulleted list p.551). You use the Preferences class, which creates an XML file instead. See PreferencesTest.java