Rice University - Comp 212 - Intermediate Programming

Fall 2001

Lecture #15 - Java Graphical User Interfaces ("GUI"s) and the Model-View-Controller ("MVC")

Java uses two main packages to manage graphical user interfaces:

1. java.awt -- "AWT" stands for "Abstract Windowing Toolkit". This holds the base classes used to manipulate the screen. It is outmoded however and has been largely replaced with the Swing package.
   1. java.awt.event -- a sub-package that holds classes used for the events in the AWT.
2. javax.swing -- "Swing" refers to who knows what. Some say that it refers to the transition from AWT to something better. It holds many replacement classes for the old AWT. Use Swing instead of AWT when given a choice

The Java GUI system is an Event-Driven System, which means that it does not work in the usual "start-here-go-to there-and-end-somewhere-else" type format. Instead it essentially just sits around, waiting for "events" to occur. Examples of events are:

• The user clicks a mouse button.
• The user types something on the keyboard.
• The user closes or minimizes or maximizes a window.
• The user moves the mouse.
• and many, many more.

For a GUI component (such as a button) to respond to a GUI event, we must register the event with the GUI component by adding an "event listener" to the component. We will explain later how to do that in many examples. When an event occurs, then the Java GUI system (not the user's program!) calls a corresponding method on a corresponding object.

First, let's discuss the classes involved:

Components:

• All GUI elements are derived from java.awt.Component
  • Examples:
    • Buttons -- accept mouse clicks
    • Labels -- display single lines of text
    • Text fields -- allow keyboard input.
    • Text areas -- displays multple lines of text.
    • Radio buttons -- allows either-or choosing
    • Check boxes -- Allows selection of an option.
• Containers: Components that hold other Components (See the Composite design pattern)
  • Examples:
    • Panels -- generic Component containers, used for organizing and laying out of Components.
    • Scroll panes -- allows for a Container that is larger than can be shown and thus needs to be scrolled. Can hold only one text area or panel.
    • Frames -- The "window" that pops up on the screen. Usually has a title bar and minimize/maximize buttons. Usually can be resized by the user. Might have a menu bar too.
• Layouts: Automatic positioning of GUI elements in a Container. Preferable to fixed position layout.
  • Examples
    • BorderLayout - (frame default) Positions components along the edges ("north", "south", "east", "west") or in the center ("center").
    • FlowLayour - (panel default) Positions components in a centered horizontal line.

Communicating with GUI components

• MVC summary (See the MVC design pattern)
  • Separate the program into (at least) two distinct sections:
    • The Model -- The "guts" of the program that actually contains the logic of how the program runs.
    • The View - the part of the program that directly communicates with the user. The code for the GUI would be here, for instance.
  • The model and the view are independent of each other, that is, the model doesn't care how the system communicates to the user, just that it does. Likewise, the view doesn't care how the calculations needed to perform the overall task are done, just that they are.
  • The model and the view thus deal with each other in abstraction.
  • But the model and the view don't even know what methods they offer to each other. They each only know what methods they need from the other--which does not imply that those are the methods actually presented!
  • This means that there must be another object(s) in-between the model and view -- an "adapter". (See the Adapter design pattern)
  • Models and views only know about their adapters, not each other. Usually, only the interfaces for the adapters need to be defined, as the class hierarchy that the adapter belongs to is irrelevant.
  • We will generalize these ideas in the next lecture.
• Listeners/Adapters
  • The Java AWT system uses "listener" interfaces to enable components to communicate with each other.
  • For instance:
    • A JButton uses an object that implements the ActionListener interface to communicate to it's "model".
    • When the button is clicked by the user, it calls the actionPerformed() method of its ActionListener. The button doesn't care what happens, just that the adapter will tell whomever is supposed take care of the issue that the button was clicked.
    • For today's lab, we will have the button talk to the frame that holds it. The frame will be the button's "model".
    • Anonymous inner classes are a great way to implement listeners.
  • For interfaces that have lots of methods are thus a pain to deal with when you only want to implement one or two of those methods, Java provides abstract classes with those methods already written (they don't do anything). Thus you only need to override those methods you want. Java calls these, not surprisingly, "adapter" classes.