CISC 370 Lecture Notes for Class No. 11, March 14, 2000

Assignment

Reading:

Horstmann & Cornell, chap. 8 thru p. 313

Exercises: none

Today's Lecture Topics

1. Homework and logo demos

2. Working with images: An image gallery.

   In this implementation the paintComponent() method displays a single image and the main application program has control over which images are displayed when and for how long. The code is in ImageGallery class in the directory $CISC370HOME/example-progs/pictureGallery/version1/.

   Note that repaint() is called each time the imageNo is changed by the method setImageNo(). This schedules, in a separate thread, a call to paintComponent().

   Without the loop and the necessity to clear previously painted areas, the paint() method is much simpler in the new implementation.

3. A second version of the ImageGallery that uses the Observer/Observable paradigm. We will use this as a lead-in to the discussion of event handling in Java 2.0.

   The Observable class represents an observable object, or "data" in the model-view paradigm. It can be subclassed to represent an object that the application wants to have observed.

   An observable object can have one or more observers. After an observable instance changes, an application calling the Observable's notifyObservers() method causes all of its observers to be notified of the change by a call to their update() method. All observers must implement the Observer interface.

   There are two key methods in the Observable class that are used in the ImageGallery.setImageNo() method. They are: notifyObservers(Object obj)
   If this object has changed, as indicated by the hasChanged() method, then notify all of its observers and call the clearChanged() method to indicate that this object has no longer changed. Each observer is notified by a call o.update(this,obj) for each Observer o that has registered with this.

   setChanged()
   Indicates that this object has changed and must normally be called before calling notifyObservers().

   Things to note about version 2 of this code.

   • The observer/observable paradigm provides a clean separation between the code that represents the object and the code for displaying the object.
   • The interface Observer plays a role exactly like the interface CallBack in our previously discussed generic sort example. That is, it specifies the interface that an observer must adhere to in order that an Observable object can interface with it. In this case, however, there can be multiple observers of an object.
   • The Mediatracker code must be moved from ImageGallery to IGDisplayer because the Mediatracker constructor needs a Component object for which to track the images. Since ImageGallery now extends Observable (instead of JFrame), it is no longer a Component. On the other hand, IGDisplayer extends JFrame, which is derived from Component and can thus use the Mediatracker. Also since the main program must also wait for the image to load, it needs access to the media tracker to tell it when an image has finished loading. Thus, we need to add a method getTracker to the IGDisplayer class.

   Overview of what must be done to use the observer/observable paradigm

   1. The object to be observed must subclass the Observable class.
   2. The observer class must implement the Observable interface. That is implement the method

                public void update( Observable O, Object arg )
                

      where O is the observable object that calls update and arg is an optional object that the observed object can choose to send to the observer. In our example, the new image is sent via arg.
   3. Each observer must register with the object it is observing by calling the observed object's addObserver() method. This is done in the IGDisplayer constructor with the code
      if.addObserver( this );
      

4. Event handling overview

Back to the CISC 370 homepage.

This page has been accessed times since 13 Mar 2000.

Corrections, suggestions and comments to Bob Caviness

Copyright 2000 B. F. Caviness