Section 8 : The java.awt Package

Write code using component, container, and LayoutManager classes of the java.awt package to present a GUI with specified appearance and resize behavior, and distinguish the responsibilities of layout managers from those of containers.

Layout Managers

There are two reasons for Java using layout managers.

Firstly, precise layout is a repetitious and often performed task. Therefore, according to the principles of OOP, layout functionality ought to be encapsulated into one or more classes to automate the task.

The second and practical reason stems from Java’s platform independence. Java components borrow their behavior from the window system of  the underlying hardware on which JVM is running. The problem here is that buttons and other components have different sizes when instantiated on different platforms. If Java encouraged precise pixel level sizing and positioning, there would be a lot of Java GUIs that looked exquisite on their platform of origin and terrible on others. Java deals with this problem by delegating precision layout work to layout managers.

Containers and Components

When a container is constructed, it is given a default layout manager. A container confers with its layout manager to determine where components will be placed and (optionally) how they will be resized. If the container subsequently gets resized, the layout manager again lays out the components. 

Component size and position

A component’s size and position can be changed by calling its setBounds() method. Generally, this call proves to be useless since layout managers usually have the last word. It is they who decide the size and position of the component, since their call to the component’s setBounds() occurs after any calls to this method by the program. If you wish to have control over the size then probably it is best to use FlowLayout.

Layout policies

Every Java component has a preferred size. The preferred size expresses how big the component would be without intervention by a layout manager. Preferred size is the smallest size necessary to render the component in a visually meaningful way. Preferred size is platform dependent, since component boundary decorations vary from system to system.

When a layout manager lays out its container’s child components, it has to balance two considerations: the layout policy and each component’s preferred size. First priority goes to enforcing layout policy. If honoring preferred size would mean violating the layout policy, then the layout manager overrules the preferred size.

FlowLayout

This layout manager always honors a component’s preferred size.

It arranges components in horizontal rows. It is the default manager for Panels and Applets. It fits as many components as possible into the top row, left to right in the order they were added, and spills the remainder into second row.

Within each row the components are centered and evenly spaced. The justification of the clustering can be controlled by passing a parameter (FlowLayout.LEFT, FlowLayout.RIGHT and FlowLayout.CENTER)  to FlowLayout constructor.

The default gap between components is 5 pixels in both the horizontal and vertical directions. This gap can be changed using another of its constructors.

1. FlowLayout()

2. FlowLayout(int justification)

3. FlowLayout(int justification, int hGap, int vGap)

GridLayout

This layout manager always ignores a component’s preferred size.

The GridLayout class is a layout manager that lays out a container's components in a rectangular grid. The container is divided into equal-sized rectangles, and one component is placed in each rectangle.

Components appear in the order they were added, from left to right, row by row.

1. GridLayout()

2. GridLayout(int rows, int columns)

3. GridLayout(int rows, int columns, int hgap, int vgap)

BorderLayout

This is default manager for Frames. It divides its territory into 5 regions: BorderLayout.NORTH, BorderLayout.SOUTH, BorderLayout.EAST, BorderLayout.WEST, and BorderLayout.CENTER. Each region can contain one component. This layout is not affected by the order in which components are added. Instead you must specify which of the five regions will receive the component you are adding. 

The manager honors the preferred height of components in the north and south and forces them to be exactly as wide as the container. The north and south regions are useful for toolbars, status lines and any other controls that ought to be as wide as possible, but no higher than necessary.

In east and west, a component gets to be its preferred width but the height extends from bottom of the north component (if there is one) or to the top of the container (if there is no North component), to the top of the South component (if there is one) or to the bottom of the container (if there is no south component).

The fifth region is Center which is simply the part of a container that remains after north, south, east and west have been allocated. When adding a component to center, it is legal to omit the second parameter to the add() call; the layout manager assumes  that you meant center.

GridBagLayout

This is the most complicated layout manager. It divides its container into an array of cells, but different cell rows can have different heights, and different cell columns can have different widths. A component can occupy a single cell or it can span many cells. This manager requires a lot of information to know where to put a component. A helper class GridBagConstraints is used hold the layout information. When you add a component, you use the add(component, object) version of the add() method, passing an instance of the GridBagConstraints as object parameter.

To provide the layout information different fields of the GridBagConstraints class are required to be set. These fields are:

CardLayout

It lays out its components in time rather than in space. At any moment, a container using this manager is showing one or another of its components; all the other components are unseen. A method call to the layout manager can tell it to display a different component. All the components (which are usually panels) are of its components; all the other components are unseen. A method call to the layout manager can tell it to display a different component. All the components (which are usually panels) are resized to occupy the entire container. The result is similar to a tabbed panel without the tabs.

No layout manager

To use no layout manager, just call setLayout(null);

If a container has no layout manager, it honors each component’s x, y, width and height values. So you can call setBounds() on a component, add it to a container and have the component end up where you want it to be. The problem with this approach is that if your container resides in a larger container that gets resized, your layout may need to be redone to save components from being overlaid or clipped away. People who do this find that they have to write code to detect when the container resizes and more code to do the right things when resizing occurs. This ends up being more complicated than creating your own layout manager.

section8-1-1 | section8-1-2 | section8-1-3 | section8-2

Sections : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11

If you wish to download the complete notes (around 100 pages - pdf or doc file) for a small price, click here.

This site is hosted by TRKHosting.com

Contact | Home | Java | Jokes | Poems | Musings | Site Map | Kudos | Downloads | Useful Sites | Interesting | System Setup  

 Number of Pages viewed on this site since January' 2003 :

For any queries, comments or suggestions, write to me .

This site never compromises your privacy, please read this site's privacy policy.