Graphical User Interfaces
[Part 8 of 11]

So far, we've been running our programs from the command line. With your analyst's head on you might be used to this, however, viewed as a normal computer user it is pretty strange; we generally run software that works through a series of windows, menus, buttons, etc. Here, then, we'll finally look at how we build these kinds of program. It isn't difficult once you get used to it, but it requires little bits of everything we've learnt so far, from arrays, to method calls, to inheritance.

Further info:

If you are interested in gridbag layouts, see this tutorial.

 

We won't look at the javax.swing package on this course, because it is slightly more complex and has a slightly different model for building interfaces compared with the java.awt package (see the second set of slides, below). However, it is worth a look. You can find out more at the Oracle Swing Tutorials.

Quiz:

Fill in the correct missing line to give the user a GUI with a Frame and Button:

public void MyApp () {
   Frame f = new Frame("My App");
   f.setSize(200,200);
   Button b = new Button("My Button");
   f.add(b);
    ______________________________
}


  1. b.setVisible(true);
  2. f.setVisible(true);
  3. setVisible(true);
  4. setVisible();

Correct! You need to call the container's setVisible method, passing in true. It would be just setVisible(true); if you were extending Frame, but here we're making a standard Frame object.

Further info:

Given that you can either make a standard Frame (S) or extend the Frame class (E), and you can either have external (X) listeners or implement the listener yourself (Y), there are four variations of frame and listener you can have. Here they are for the tickbox example in the slides:

Version 1 (S-X): CheckboxGUI1.java
Version 2 (E-Y): CheckboxGUI2.java
Version 3 (S-Y): CheckboxGUI3.java
Version 4 (E-X): CheckboxGUI4.java
Listener class for 1 and 4: CheckboxListener.java

 

For more examples see 'key ideas', below, and the course code cookbook.

 

It is worth noting that, as we saw saw with FileDialogs, if you create a Frame without a label it can hang round in the background and stop programs exiting after they've run their course. In most GUI-based systems this isn't usually a problem as most are shut down with a call to System.exit, which will dispose of any remaining objects.

While we're on the subject of FileDialogs, now we've see how to make a Frame object, it is less likely you'd do:

FileDialog fd = new FileDialog(new Frame());

And more likely you'd do:

Frame f = new Frame("My GUI");
FileDialog fd = new FileDialog(f);

or, if you're extending Frame:

FileDialog fd = new FileDialog(this);

Where this refers to the object you are in, i.e. the class that extends Frame.

Quiz:

What is the likely missing line in this code to get it working?

public void MyApp () {
   Frame f = new Frame("My App");
   f.setSize(200,200);
   Button b = new Button("My Button");
   f.add(b);
    ______________________________
   f.setVisible(true);
}

  1. f.addActionListener(b);
  2. b.addActionListener(f);
  3. f.addActionListener(this);
  4. b.addActionListener(this);
  5. addActionListener(b);
  6. addActionListener(f);

Correct! You register the ActionListener inside the object making the event. In the absence of any other information, and given the standard classes for Frame and Button, the only likely listener is this.

Further info:

We'll come back to the software process later in the course. For now you can find some info on the software release cycle on the Wikipedia page.

For more info on usability testing, see Useful Links, and Recommended Texts.

Quiz:

The usual symbol for a user in UML is _____________________.

 

  1. a stick man
  2. a winking face
  3. a picture of someone scratching their head and looking perplexed
  4. a mysterious void, only noticeable because of the faint sound of screams

Correct! As found in use-case diagrams.

[Key ideas from this part]