Unit 5: Introducing Swing LH 5

• The origins of swing, swing is built on the AWT

• Two Key Swing Features
• The MVC connection
• Components and containers
• Although the AWT is still a crucial part of Java, its
component set is no longer widely used to create
graphical user interfaces.
• Today, most programmers use Swing or JavaFX
for this purpose.
• Swing is a framework that provides more powerful
and flexible GUI components than does the AWT.
 The Origins of Swing
• Swing did not exist in the early days of Java. Rather, it
was a response to deficiencies present in Java’s original
GUI subsystem: the Abstract Window Toolkit.
• The AWT defines a basic set of controls, windows, and
dialog boxes that support a usable, but limited graphical
interface.
• One reason for the limited nature of the AWT is that it
translates its various visual components into their
corresponding, platform-specific equivalents, or peers.
This means that the look and feel of a component is
defined by the platform, not by Java. Because the AWT
components use native code resources, they are referred
to as heavyweight.
 Limitations of AWT
• The use of native peers led to several problems.
First, because of variations between operating
systems, a component might look, or even act,
differently on different platforms. This potential
variability threatened the overarching philosophy
of Java: write once, run anywhere.
• Second, the look and feel of each component was
fixed (because it is defined by the platform) and
could not be (easily) changed.
• Third, the use of heavyweight components caused
some frustrating restrictions. For example, a
heavyweight component was always opaque.
• Swing Is Built on the AWT Although Swing
eliminates a number of the limitations inherent
in the AWT, Swing does not replace it.
• Instead, Swing is built on the foundation of the
AWT.
• This is why the AWT is still a crucial part of
Java.
• Swing also uses the same event handling
mechanism as the AWT.
• Therefore, a basic understanding of the AWT
and of event handling is required to use Swing.
• Two Key Swing Features As just explained,
Swing was created to address the limitations
present in the AWT.
• It does this through two key features:
lightweight components and a pluggable
look and feel.
• Together they provide an elegant, yet easy-to-
use solution to the problems of the AWT.
• More than anything else, it is these two
features that define the essence of Swing
1. Swing Components Are Lightweight
• With very few exceptions, Swing components are
lightweight.
• This means that they are written entirely in Java and do not
map directly to platform-specific peers.
• Thus, lightweight components are more efficient and more
flexible.
• Furthermore, because lightweight components do not
translate into native peers, the look and feel of each
component is determined by Swing, not by the underlying
operating system.
• As a result, each component will work in a consistent
manner across all platforms
2. Swing Supports a Pluggable Look and Feel
• Swing supports a pluggable look and feel (PLAF).
• Because each Swing component is rendered by Java code rather than by
native peers, the look and feel of a component is under the control of
Swing.
• This fact means that it is possible to separate the look and feel of a
component from the logic of the component, and this is what Swing
does.
• Pluggable look-and-feels offer several important advantages.
 It is possible to define a look and feel that is consistent across all platforms.
 Conversely, it is possible to create a look and feel that acts like a specific
platform. For example, if you know that an application will be running only
in a Windows environment, it is possible to specify the Windows look and
feel.
 It is also possible to design a custom look and feel. Finally, the look and feel
can be changed dynamically at run time.
• Java 8 provides look-and-feels, such as metal and Nimbus, that are available to
all Swing users. T
• the metal look and feel is also called the Java look and feel.
• It is platform independent and available in all Java execution environments. It is
also the default look and feel.
 The MVC Connection
In general, a visual component is a composite of
three distinct aspects:
• The way that the component looks when rendered
on the screen
• The way that the component reacts to the user
• The state information associated with the
component No matter what architecture is used to
implement a component, it must implicitly
contain these three parts.
Over the years, one component architecture has
proven itself to be exceptionally effective: Model-
View-Controller, or MVC for short.
The MVC architecture is successful because each piece
of the design corresponds to an aspect of a
component. In MVC terminology,
• The model corresponds to the state information
associated with the component. For example, in the
case of a check box, the model contains a field that
indicates if the box is checked or unchecked.
• The view determines how the component is displayed
on the screen, including any aspects of the view that
are affected by the current state of the model.
• The controller determines how the component reacts
to the user. For example, when the user clicks a
check box, the controller reacts by changing the
model to reflect the user’s choice (checked or
unchecked). This then results in the view being
updated.
• By separating a component into a model, a view, and a
controller, the specific implementation of each can be
changed without affecting the other two. For instance,
different view implementations can render the same
component in different ways without affecting the
model or the controller.
• Although the MVC architecture and the principles behind it
are conceptually sound, the high level of separation
between the view and the controller is not beneficial for
Swing components. Instead, Swing uses a modified version
of MVC that combines the view and the controller into a
single logical entity called the UI delegate.
• For this reason, Swing’s approach is called either the
Model-Delegate architecture or the Separable Model
architecture. Therefore, although Swing’s component
architecture is based on MVC, it does not use a classical
implementation of it.
In summary,
• Model represents component's data.
• View represents visual representation of the
component's data.
• Controller takes the input from the user on the
view and reflects the changes in Component's
data.
• Swing component has Model as a separate
element, while the View and Controller part
are clubbed in the User Interface elements.
Because of which, Swing has a pluggable
look-and-feel architecture.
 Swing Features
• Light Weight − Swing components are independent of
native Operating System's API as Swing API controls
are rendered mostly using pure JAVA code instead of
underlying operating system calls.
• Rich Controls − Swing provides a rich set of advanced
controls like Tree, TabbedPane, slider, colorpicker, and
table controls.
• Highly Customizable − Swing controls can be
customized in a very easy way as visual appearance is
independent of internal representation.
• Pluggable look-and-feel – Swing based GUI
Application look and feel can be changed at run-time,
based on available values.
Swing Hierarchy
 Components and Containers
A Swing GUI consists of two key items:
components and containers.
• However, this distinction is mostly conceptual
because all containers are also components.
• The difference between the two is found in
their intended purpose: As the term is
commonly used, a component is an
independent visual control, such as a push
button or slider.
• A container holds a group of components.
Thus, a container is a special type of component
that is designed to hold other components.
Furthermore, in order for a component to be
displayed, it must be held within a container.
Thus, all Swing GUIs will have at least one
container. Because containers are components,
a container can also hold other containers. This
enables Swing to define what is called a
containment hierarchy, at the top of which must
be a top-level container.
Components
• In general, Swing components are derived from the
JComponent class. ( except the four top-level
containers)
• JComponent provides the functionality that is common
to all components. For example, JComponent supports
the pluggable look and feel. JComponent inherits the
AWT classes Container and Component. Thus, a Swing
component is built on and compatible with an AWT
component.
• All of Swing’s components are represented by classes
defined within the package javax.swing. The following
table shows the class names for Swing components
(including those used as containers).
Container.
• Unlike Swing’s other components, which are
lightweight, the top-level containers are
heavyweight. This makes the top-level containers a
special case in the Swing component library.
• As the name implies, a top-level container must be
at the top of a containment hierarchy. A top-level
container is not contained within any other
container.
• Furthermore, every containment hierarchy must
begin with a top-level container. The one most
commonly used for applications is JFrame. The
one used for applets is JApplet.
• The second type of containers supported by
Swing are lightweight containers. Lightweight
containers do inherit JComponent. An example
of a lightweight container is JPanel, which is a
general-purpose container.
• Lightweight containers are often used to organize
and manage groups of related components
because a lightweight container can be contained
within another container.
• Thus, you can use lightweight containers such as
JPanel to create subgroups of related controls
that are contained within an outer container.