The Swing Classes

Team-Fly

JFCs, which are also called Swings, are sets of prebuilt classes that provide Java applications and applets with the building blocks for a sophisticated GUI. The architecture of most Swing components is based on the MVC (Model-View-_Controller) design pattern.

Swing and AWT

Java took off faster than anyone could have imagined; the most visible of the Java APIs (Application Programming Interfaces), AWT, was thrust into the limelight. Unfortunately, the original AWT was not prepared for its sudden rise in popularity.

The original AWT was not designed to be anything akin to a high-powered user interface toolkit used by many developers. Instead, it was aimed at supporting the development of simple user interfaces for simple applets. The original AWT lacked many features that one would expect in an object-oriented GUI toolkit; clipboards, printing support, and keyboard navigation, for example, were all conspicuously absent. The original AWT did not even include such basic amenities as pop-up menus or scroll panes, two staples of modern user interface development.

In addition, the AWT infrastructure was flawed. AWT was fitted with an inheritance-based event model that scaled badly and a peer-based architecture that was destined to become the toolkit's Achilles heel.

One drawback of peer design is that on most platforms, each peer is rendered in a native window. A ratio of one native window per component is not exactly a formula for high performance, and applets that contained numerous AWT components paid a steep performance penalty as a result.

Because the original AWT had a high incidence of bugs, third-party companies began to offer toolkits providing more solid infrastructures and more functionality than did AWT. One such toolkit was Netscape's IFC (Internet Foundation Classes), a set of lightweight classes based on concepts from NEXTSTEP's user interface toolkits. IFC components did not use peer elements, and they surpassed AWT components in many respects. IFC also began to attract more than its share of developers.

Realizing that the Java community was likely to split over a standard user interface toolkit, JavaSoft struck a deal with Netscape to implement JFC (Apple and IBM have also participated in the development of JFC), or Swing. Netscape developers have worked with Swing engineers to embed considerable IFC functionality in Swing components.

Originally, Swing was meant to closely resemble Netscape's IFC. Over time, however, Swing diverged considerably from its original intent as features, such as pluggable look and feel (which provides a common look and feel across platforms and allows developers to guarantee a consistent interface for their Java applications or applets), were added and designs were modified. With release 1.0 most of Swing's outward similarities to IFC had vanished, although a great deal of IFC technology remains embedded within Swing. Today, Swing provides the best of both AWT and IFC in a comprehensive user interface toolkit.

Benefits of Swing

A common misconception about Swing is that it is designed to replace AWT; actually, Swing is built on top of AWT. Swing takes advantage of the AWT infrastructure, including graphics, colors, fonts, toolkits, and layout managers, but does not use AWT components. The only AWT components that have relevance for Swing are the frames, windows, and dialogs. In essence, Swing uses the best of AWT to build a new set of mostly lightweight components while leaving behind the heavyweight components.

To get the most out of Swing, you need a basic knowledge of AWT infrastructure. In addition to using AWT functions, all Swing lightweight components are ultimately derived from the AWT Container class, which in turn extends the AWT Component class. In other words, not only does Swing take advantage of the infrastructure provided by AWT, but all Swing components are actually AWT containers. The AWT Container class itself is lightweight, meaning that it has no peer element and is painted in its container's window.

The Model-View-Controller Design Pattern

The MVC design pattern, like many other design patterns, goes back to the principle of object-oriented design, which advises against making one object responsible for too much functionality. In other words, don't have a single button class do everything; instead, have the look and feel of the component associated with one object and store the contents in another object. The MVC design pattern accomplishes its goal by implementing three separate classes: the model, which stores the contents; the view, which displays the contents; and the controller, which handles user input.

The MVC design pattern specifies precisely how these objects interact. The model stores the contents and has no user interface. A small set of flags that indicate whether a button is currently active or inactive should suffice. The content for a text field is a bit more interesting; it is a string object that holds the current text. If the content is larger than the text field, the user sees only a portion of the text displayed.

The model must implement methods to discover what the contents are and then change them. For example, a text model has methods to add or remove characters in the current text and to return the current text as string. Again, keep in mind that the model is completely abstract. It has no particular visual representation.

The view's job is to draw the data that is stored in the model. One advantage of the MVC design pattern is that a model can have multiple views, each showing a different aspect of the full contents.

The controller handles user-input events, such as mouse clicks and keystrokes; it decides whether to translate these events into changes in the model or the view. For example, if the user presses a character key in a text box, the controller calls the Insert Character command of the model. The model then tells the view to update itself, and the view never knows why the text changed. But if the user presses a cursor key, then the controller may tell the view to scroll. Scrolling the view has no effect on the underlying text, so the model never knows that this event occurred.

Creating a Swing Applet

The following example inherits the JApplet class to create the SwingApplet class, which displays the earth.gif image. The SwingApplet overrides the JApplet init() method. You should put all the code in the init() method you want your applet to execute before it starts. In the SwingApplet init() method, we create a container (to hold the earth.gif image and label) and display the earth.gif image in the center.

    import javax.swing.*;     import java.awt.*;     import java.awt.event.*;     Public class SwingApplet extends JApplet     {         public void init()         {             Container contentPane = getContentPane();             Icon icon = new ImageIcon("earth.gif",                 "An earth GIF on a Swing");             JLabel label = new JLabel("Swing!", icon,                             JLabel.CENTER);             contentPane.add(label, BorderLayout.CENTER);         }     }

Compile this example in MS-DOS using command line javac SwingApplet.java. Assume that the example is in the SwingApplet.java file. The Java compiler produces SwingApplet.class. To execute SwingApplet.class at MS-DOS, use command line java SwingApplet, which should produce the results shown in Figure 13.1.

The JApplet class uses an instance of BorderLayout as the layout manager for its content pane. To stress this fact, the applet listed in the preceding example specifies a layout constraint of BorderLayout.CENTER, which enters the label in the content pane. The default constraint for a component laid out by BorderLayout is BorderLayout.CENTER; specifying the constraint in the applet is not strictly necessary.

click to expand

Figure 13.1: Results of running SwingApplet in MS-DOS


Team-Fly


Java & BAPI Technology for SAP
Java & BAPI Technology for SAP
ISBN: 761523057
EAN: N/A
Year: 1998
Pages: 199

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net