17.2 AWTSWING COMPONENTS


17.2 AWT/SWING COMPONENTS

In Java, the GUI components one places on a screen come from either the packages that begin with the prefix java.awt[3] or the packages that begin with the prefix javax.swing. The components are designed so as to generate events when subject to human interaction. These events can be captured and processed by objects that implement certain interfaces defined in the java.awt.event and the javax.swing.event packages.

The more commonly used AWT and Swing types in a Java based GUI program can be broadly divided into the following four categories:

Top-Level Containers: AWT/Swing components that are top-level containers are meant for holding other graphical objects, which can be intermediate-level containers or atomic components. Graphical components including other graphical components within them gives rise to containment hierarchies. Every AWT/Swing program must have at least one top-level container and every containment hierarchy in an AWT/Swing program must have a top-level container at its root. Moreover, an atomic GUI component cannot be made visible on a screen unless it is in some containment hierarchy. Examples of the commonly used Swing top-level containers are JFrame, JDialog, and JApplet. All of these are heavyweight[4] containers. The heavyweight Swing containers are extensions of their AWT counterparts, which are all heavyweight. For example, the Swing container JFrame is derived from the AWT container Frame. It is possible and common for a program written in Swing to have more than one containment hierarchy. For example, an applet that brings up a dialog will have at least two containment hierarchies, one rooted at JApplet and the other at JDialog.

Intermediate Containers: Intermediate containers are often not directly visible but are nonetheless useful for organizing the visual layout of the graphical objects they hold. Examples: JPanel, JScrollPane, JTabbedPane, and so on. The intermediate container InternalFrame mimics a frame. However, unlike JFrame, which is heavyweight, InternalFrame is lightweight.

Atomic Components: The self-contained graphical components-referred to as the atomic components-are held by top-level and intermediate containers. Examples of these are JButton, JTextField, JScrollBar, and so on. All atomic components in the Swing packages are lightweight.

Miscellaneous Classes: These include classes for managing the layout of the components, for controlling the look and feel, for fetching information from the underlying operating system, and so on. Examples of these are GridLayout, FlowLayout, Toolkit, Graphics, and so on.

Now for a bit of background on AWT and Swing in the evolution of the Java language, first came AWT with Java in 1995. From the standpoint of designing sophisticated GUI and applets, AWT was fairly rudimentary. Under AWT, each Java component created a corresponding component using the native GUI API.[5] This meant that Java could only support those components that existed in all the important platforms of the day. This fact-referred to as the "least common denominator" approach-caused a Java button on a Unix platform to look like a Motif button, and on a Windows platform to look like a Windows button. While early on, this property of Java to create a native look-and-feel was considered to be a positive point, the thinking in the community changed as time went on. Software developers began to see the benefits of a programmable approach to look-and-feel that would allow a GUI to look the same and to work the same across diverse platforms. Enter Swing at this juncture. The Swing packages (which form a large part of the Java Foundation Classes (JFC)), besides giving the application developers a programmable look-and-feel, contain many other innovations over AWT, such as the computationally more efficient lightweight components, better debugging support, more efficient event handling, decorative borders, ability to place icons on components, double buffering, and so on.

[3]The acronym AWT stands for Abstract Window Toolkit.

[4]A component is considered heavyweight if it has associated with it a peer class that acts like a wrapper for the corresponding native API component. Many of the AWT components are heavyweight. Let's say the native API is Motif. Then to draw an AWT button, Java will actually invoke a peer class to call on a Motif button. By contrast, lightweight components are peerless. Since a lightweight component is drawn without invoking any native GUI API code, it is possible to achieve the same look-and-feel across platforms. Given a choice between a lightweight component from one of the Swing packages and a heavyweight component from an AWT package, you should choose the former since the lightweight components are computationally less demanding. Another reason for preferring a Swing lightweight component over an AWT heavyweight component that does the same thing is that the former gives you transparent pixels. Because of transparent pixels, a lightweight component can appear to be nonrectangular. On the other hand, a heavyweight component is always rectangular.

[5]See the footnote discussion earlier in this section about "peered" components.




Programming With Objects[c] A Comparative Presentation of Object-Oriented Programming With C++ and Java
Programming with Objects: A Comparative Presentation of Object Oriented Programming with C++ and Java
ISBN: 0471268526
EAN: 2147483647
Year: 2005
Pages: 273
Authors: Avinash Kak

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