In the preceding chapter, you were introduced to the java.applet.Appletclass. In order to tell Java that this program is going to be an applet, all that you basically need to do is create a subclass of the Applet class. Everything that makes up an applet is inherited from the superclass java.applet.Applet. Included in this inheritance are the basic user interface, methods for accessing parameters from an HTML page, and several methods known as life-cycle methods that are called directly by the system you use to organize your program. Another method that is part of the java.awt.Componentclass (which would be a super-super-super class to the class containing your applet) is the method paint(), which is used to draw various things in your applet's pane. The following shows an example of what the structure of a typical applet might look like:
import java.awt.Graphics;class ABClass extends java.applet.Applet {public void init() {/* Initialize any variables, images, etc here.Any initialization that only needs to be done once should beincluded here because this method is called only once. */}public void start() {/* This method can also be used for initialization.However, the difference for this one is that it is used forcomponents in your applet that need to be initialized morethan once, or if the reader leaves the applet and thenreturns. This method can be called more than once. */}public void stop() {/* This life cycle method is the counterpart to start().Any code to suspend execution should be retained here. */}public void destroy() {/* This method is used to clean up the applet before it isfinished. This method is called only once. */}public void paint(Graphics g) {/* Any code to draw, write, or color things on theapplet pane belongs here */}}
In the preceding pseudo-applet, each method is called by the system at a particular moment, under specific circumstances, or in a special order. Some of the methods can be called more than once depending on how the user engages the applet and the environment in which the applet is being run.
To review more closely the logistics of an applet, the fact that an applet is designed to run in the heterogeneous and possibly unsecured environment of the Internet has imposed several restrictions on it. Most of this is review from the last chapter, so this explanation highlights an applet in its strictest sense, pointing out potential differences with that of applications. Also, note that in certain situations, there are exceptions to the following restriction, even in applets. In some cases, these restrictions can be lowered depending on the type of Internet browser running the applet and its configuration.
Applets cannot read or write to the user's file system. This means that the applet cannot access anything locally or place anything locally either. For example, many Windows-based applications written in C utilize an initialization file (an .INI file) in 16-bit Windows or the Registry in 32-bit Windows to store information about the application and any user preferences. This is not possible in the current applet model and imposes a challenge to traditional programming techniques. This limited access can also include just checking to see if a file even exists on the user's system.
Applets cannot utilize native methods, load shared libraries, or run any programs that may be on the user's system. The major security concern here is that native methods and local shared libraries (such as DLLs) can facilitate a loophole in the Java security model described in the previous paragraph.
Applets cannot communicate with any server other than the one from which they originated. In some cases, an encrypted key can be used to verify a particular applet to a server, or a server accessed due to a configuration with the Internet browser, but access to any server on the Net cannot be assumed.
Overall, applets provide a different format for program execution and a very tight security model, which is necessary in the very open environment of the Internet.
No comments:
Post a Comment