An Introduction to the JApplet Component
A brief summary of thr JApplet Component concept
The JApplet component is a subclass of java.applet.Applet. An Applet is a Java program that is meant to be embedded in a web page. This is why we used ShowFruits.htm to run the appletviewer from DOS (NetBeans internally creates an html file for the applet). Also, applets should be granted certain permissions and privileges before running components like the filechooser that accesses the computer's hard drive. When an Exception is thrown the applet will not run if the permissions are not set. The applets.policy file specifies that applets have all permissions for the local machine. This is appropriate for a testing environment.
JApplet is simply an enhanced version of Applet that allows developers to work with JFC/Swing component architecture. All Applets (and JApplets) have a Life Cycle that starts when the web page they are located on is loaded onto a web browser such as Internet Explorer. Since we will be running our applet through NetBeans or the appletviewer command, our Applet's lifecycle starts when the command is issued. First, an instance of the applet's class is created. Next, the applet initializes itself through the init() method. Then, the applet starts execution (start()). Any calls to the stop() method halts the execution. The applet is unloaded and all associated objects are cleared when the destroy() method is called through the 'quit' menu item on appletviewer or by closing the appletviewer window. The developer overrides or writes his own implementation of these methods to customize an applet.
Any calls to the repaint() method in JApplet causes the applet to redraw (or render) itself. A user can customize the rendering by overriding the paint method with the signature paint(Graphics g). The method automatically takes the Applet's Graphics rendering as an argument. Within the paint method, the developer may use the parameter g of type Graphics to customize rendering. The paint method is integral to the functioning of most applets.
Two threads can execute concurrently in any applet. First, the main thread creates an instance of the class and executes the init() and start() methods. A user event on the 'Applet' pull-down menu in the applet viewer is handled by this thread. The AWT-EventQueue runs the paint() method and performs graphics rendering.
In our program, the init() method sets the look and feel of the application to match that of the Windows OS and initializes an ArrayList to the fruits in the input file. It also lays out the components (an ImagePanel custom component to display each fruit's image and six JLabel components to display the title and value of each fruit's name, color, and calories properties) onto the content of the Applet viewer. Then, the components are initialized to contain the properties of the first fruit in the list.
Next, the init() method creates a separate thread of execution and delegates the work of cycling through the fruits at a specific time interval to the new 'slideRunner' thread. This is necessary because the JVM expects the threads running the init(), start(), and other Applet methods to return upon completion of the method. A slideshow that cycles repeatedly within one of these methods will cause the method to never complete execution and return. and the applet will be deadlocked as a result. As such, the slideRunner thread simply sleeps for one second, sets the components to reflect the values in the next Fruit in the myfruits ArrayList, and calls the repaint() method to render the screen for the next slide. Calls stop() suspends this thread while calls to start() get it running again. Closing the window or selecting Applet -> Quit calls the destroy() method. Here, the slideRunner thread is interrupted and the memory of the Fruits arrayList is released by setting the ArrayList to null.
