6.096 Lecture Notes

Oct. 22nd, 1997

Done by Abdul Ghani Sa'ad
 
 
 
    As previously seen, in putting together systems of interesting communities, there is a contract between the arguments passed and the method invoked. However, when entities that provide services are built, this relationship is not as clear.

    The aim in this lecture was to build two screens, each displaying a monogram of initials, as seen below:

The purpose of this was to explore how GUIs are organized, and how GUIs interact with each other.
 
 The code design for such a program is split into two entities:
  1. Provided a certain component, the task here is to display this component onto the screen in a useful way (i.e. in the form of a window). This entity therefore has a 'visual appearance' contract.
  2. The second entity is what actually provides the component to be displayed by the first. This is the monogram which can also be altered by user interaction. The contract of this entity can thus be viewd as a 'data storage' contract.
The discussion in class revolved around the code contained in the handout.
The classes discussed in the following notes provide shortcuts to their codes, so please follow the code provided closely!
 
 

    The contract of the first entity acts to connect between the class containing the main method, i.e. that which starts the entire program, and java's event manager, which tells the program which events are taking place, such as the close-window button being pressed.

    This entity in itself is divided into two things, or classes: DefaultFrame and WindowClosingListener. The DefaultFrame object extends java's Frame class, and is what receives the component and actually displays it graphically. A Frame is in fact what we commonly think of as a window, and it's position in the hierarchy of java.awt is as follows:

            Component
            Container
            Window
            Frame

Note that DefaultFrame is what is created by the main method, and its init( ) method is also called which causes it to be actually displayed on the screen.
 
    The init( ) method of Frame is overriden in DefaultFrame, so that a new WindowClosingListener can be added. This brings us on to the second class in the entity, which is an extension of WindowAdapter. This is the DefaultFrame's listener, which will cause the window to close when the WindowClosingEvent is passed to it. In fact, the windowClosing method will shut down the entire program, i.e. all windows (or frames) because the System.exit(0) method is used in windowClosing.
 
    Since Main and java's event manager are incompatible, or cannot communicate, the contract of this first entity fills the gap between them as seen in the diagram below. Note that the first part of this contract, the DefaultFrame, is identified by Main, which in turn identifies its own Listener. This Listener responds to java's event manager, and thus closes its DefaultFrame in the case of a windowClosing event.

 
The code in thw WindowClosingListener basically says:

To summarize how these classes interact, DefaultFrame is responsible for displaying the component on the screen, while WindowClosingListener is responsible for handling DefaultFrame and making it go away.
 

 

    As for the second entity, the 'data storage' entity, this is outlined in the following:

     SafeMonogram basically is the class that will store the two characters in its fields. Its getChars( ) method is what will return these characters in the form of a string.

    The system so far already handles two functions: Main creates the frame which will contain the monogram, and the frame will disappear if the close-button is pressed. The remaining function that is required is for the monogram to change its displayed initials when two characters are typed in. This function requires a new contract that binds the two 'display' and 'storage' entities. This contract requires things that will:

The last point will be dealt with first. The AWT component, AlphaCanvas (which extends Java's Canvas), will be able to paint the characters of the monogram by using its inherited paint method and the characters stored in SafeMonogram. This Canvas, which creates our SafeMonogram with initialized characters when constructed, can be told to change the string of characters it displays by using two other things: an EventListener and what will be called the 'smarts'. The first, the EventListener is enclosed in the class SimpleKeyListener, which extends KeyAdapter. Its keyTyped method is called by Java when a key is pressed, and in turn tells the 'smarts' what that key is.

    The second thing involved in changing the display, the 'smarts' is contained in the class WiredAlphaSmarts. What happens here is that handleChar is called when a key is pressed. When two keys have been pressed, this gives a new monogram to our component. This class uses two other provided classes to go about its functionality: AlphaSmarts and Wire. AlphaSmarts is what provides handleChar( ), while Wire contains the putObject and the getObject methods. Basically, WiredAlphaSmarts, with this combined functionalty acts as a Reader/Writer in the following manner:

  1. When something happens (i.e. new initials are typed), I'll tell you through this.putObject.
  2. Continually listen to see if you are telling me something, and then call this.getObject.
It is important to note that the first method causes WiredAlphaSmarts to act like a Writer. This is done in an event-driven manner. The second method is considered the Reader, and uses a self-animated while-true loop (in a run method).

    The contract of WiredAlphaSmarts therefore serves to alter the monogram's initials though its association with the three classes: SimpleKeyListener, AlphaSmarts and Wire.

    This concluded the end of the lecture.
 
 

 
 
If you have comments or suggestions, email me at aboud@mit.edu
 
This page created with Netscape Navigator Gold
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
.