Programming for Geographical Information Analysis: Core Skills

Programming for Geographical Information Analysis:Core Skills Lecture 8:Core Packages: The Graphical User Interface

Review Extend superclass class A extends B { //Gets all public bits } Implement interface class C implements D { // Fulfils promises } Methods that take a superclass will take the subclass, because they’ll only use the superclass bits.

Inheritance We can only extend one Class, but we can implement many Interfaces using commas. class A extends B implements C, D, E {

This lecture The Graphical User Interface (“GUI”). Event-based Programming. The User Experience.

Example WIMP GUI

The Graphical User Interface (GUI) Nested objects subclassingjava.awt.Component e.g. a ‘Window’ object containing a ‘JTree’ containing ‘Label’ objects. All have a ‘Look and Feel’ Two packages… java.awt (Abstract Windows Toolkit: standard Look and Feel). javax.swing (Part of the Java Foundation Classes (JFC): separates Look and Feel from components so you can let the JVM pick).

Major starting containers Superclasses: Component Monitors keys/mouse and resizing. Container Uses ‘LayoutManager’ objects to position contents. Window Superclass for windows style objects : rarely used on own. Classes actually used: Panel and Canvas A window with no border etc. Panel subclassed by Applet. Frame Window with border, close buttons and, potentially, menus. JDesktopPane Used for making desktops.

Frame example import java.awt.*; public class PopUp { public PopUp() { Frame frame = new Frame("My Window"); frame.setSize(300,300); frame.setVisible(true); } public static void main (String args[]) { new PopUp(); } } You’ll need Ctl-C to close it, or to shut the command window. Components do not usually respond to users automatically. All measurements in pixels.

The life of a Frame In your constructor create a Frame with a title. Frame frame = new Frame ("My Window"); Set the size of the Frame. frame.setSize(int width, int height); frame.setSize(300,300); Show the Frame. frame.setVisible(true);Opposite is(false)

Adding other components In the constructor make the other Components and add them to the Frame. Label newLabel = new Label(“My Label”); frame.add (newLabel);

The Alternative To extend Frame and add functionality. import java.awt.*; class PopUp2 extends Frame { public PopUp2 () { super("My Window"); setSize(300,300); Label newLabel = new Label(“My Label”); add (newLabel); setVisible(true); } public static void main (String args[]) { new PopUp2(); } }

Some useful components JButton Checkbox / JCheckBox JRadioButton Button List / JList JTable Note: you can group CheckBoxes with a ‘CheckboxGroup’ and Buttons / RadioButtons with a ‘ButtonGroup’ so that only one of a group can be ‘on’ at once. JProgressBar JToolBar JFileChooser JTree Menu / JMenu

Layout managers Objects that control where components added to a container are displayed. LayoutManager layout = new LayoutManager(); guiObject.setLayout(layout); Default for most is FlowLayout - as each component added they fill across the available space then wrap to the next line. Frame’s BorderLayout allows you to add things to the CENTER/NORTH/SOUTH/EAST/WEST of the component. Most of the rest are, frankly, pants. The only one the pros use is GridBagLayout - this gives absolute positioning control, but allows for windows to resize. We’ll use FlowLayout and BorderLayout, but if you use GridBag you’ll be ruler of the geeks. Lucky old you.

Summary GUIs are made up of objects that subclass Component. Some subclass Container, which in turn subclasses Component. These are usually the basis of a GUI. You can make a Container, or extend it to add functionality. You can then make and add Components. By default, none respond to user actions.

Event based programming Programs don’t usually run in a set sequence, they wait for something to happen. When they’re used or clicked, GUI Components send out objects that subclass java.awt.AWTEvent. Other classes can register as ‘listeners’ with the Components that send out the event objects. Listeners get sent the AWTEvent objects. They can then do appropriate actions.

Event based programming Listeners must implement particular sub-interfaces of the EventListener interface. These are in the package java.awt.event. By implementing these interfaces the listener classes are forced to provide methods that cope with the AWTEvent objects they are sent.

Example Checkbox in a Frame. Checkboxes demand an ItemListener with an itemStateChanged method that takes in an ItemEvent.

What sending events is really doing o When a class registers with an event producer, the producer adds the class to an array of EventListeners inside itself. OurListener implements EventListener add(EventListener) Array of EventListeners eventListeningMethod (AWTEvent e)

What sending events is really doing When an event is ‘sent’ the Component producing the event calls the appropriate method inside all the objects in the array. o OurListener implements EventListener Clicked etc. Call array elements eventListeningMethod (AWTEvent) Array of EventListeners eventListeningMethod (AWTEvent e)

What sending events is really doing Remember that because the classes in the array implement EventListeners, we can guarantee that they always have the right methods. Our implementing classes are automatically treated as the parent Interface, because we never use any other methods.

Destroying the Frame Frames produce a WindowEvent when they’re opened, closed, minimized etc. You can register with a Frame if you implement WindowListener, and its seven methods.

Destroying the Frame We could implement WindowListener to listen for the closing event. There is, alternatively, an abstract class WindowAdapter we could extend. We’d then overload its default windowClosing method. However, for such a minor case we tend to use the following code. This sets up an anonymous inner class which does the same thing: addWindowListener(new WindowAdapter(){ public void windowClosing(WindowEvent e){ ((Frame)e.getSource()).dispose(); // or System.exit(0); } });

Why go through so many hoops? Encapsulation would seem to dictate GUI and listeners should be the same class. But, it’s quite possible that the GUI is on one machine and the controller objects on another. We are trying to encourage two forms of software architecture: Model-View-Controller. n-tier.

Model-View-Controller (MVC) architecture Separate Look and Feel from actions and data. In Swing each component has an associated Model class which contains the data. You can provide your own model for a component by subclassing the Model class or by implementing the appropriate interface. For example, you could subclass DefaultListModel or implement the ListModel interface, and then use the JListsetModel method to attach your data-model to the component.

GUI Processor Database N-tier architecture Usually run over networks. Three-tier architecture A ‘thin’ GUI client on the user’s machine (‘fat’ clients do more analysis). A processing application (usually on a machine dedicated to complex processing). A data server (usually a database). Client talks to Processor which talks to Data server. Divides resources to most appropriate machines. N-tier: more middle level apps talking to each other.

Summary The GUI is a set of nested subclasses of ‘Component’. GUI based programs don’t run in a set sequence, they wait for events. Most components when used send out ‘events’. We make ‘listener’ objects which we register with each component. When something happens, the listener is informed through an interface defined method and acts. This allows us to separate the look from the processing and data.

The user experience Many people design for geeks. We need to design for the general public, but make advanced functions available for those that want them. We should try to help the user by... Using familiar keys and menus (e.g. Ctrl + C for copy). Including help systems and tutorials.

Designing for users At every stage when designing the GUI, think “is it obvious what this does?” Make all screens as simple as possible. Users learn by trying stuff - they rarely read manuals, so think carefully about what the default behavior of any function should be. Hide complex functionality and the options to change defaults in ‘Options’ menus. Most of all consult and test.

Initial consultation User consultation is a vital part of development. Users should be consulted first. If the users don’t like your software, you’re sunk. Find out what people expect to get from the system before adding extras. If it helps draw UML User Case diagrams. User Cases can be used to break a large project up into smaller bits. Do the most difficult important bits first if possible!

Usability testing When you think you have a bit users are interested in up and running, test its ‘usability’. Sit your users down with the software and get them to play with it. It’s useful to set them common tasks to do. See how long they take to do stuff, and what they do that’s unexpected. Some companies use mirrored windows. Remember, users don’t make mistakes - it’s your fault if you lead them the wrong way!

Release If you’ve been testing enough you shouldn’t have any usability problems. Most problems will be bugs from users doing unusual things. Can release alpha and beta versions to a broader number of testers or the public to test for bugs and at the same time ask for user comments. At this point you’ll need to delimit time for... User improvements (should be minimal) Refactoring (simplifying the code) Fixing bugs. If you try and do two at once it’s bound to get confusing.

Summary Always design assuming the user… Will experiment rather than read the manual. Will base these experiments on what they expect to find. Always base the software design around what the user wants. Always test the user’s opinions and the usability as you develop.

Practical Adding a GUI. Next lecture Images and Graphics

Programming for Geographical Information Analysis: Core Skills