Reading 25: Graphical User Interfaces

Input is handled differently in graphical user interfaces (GUIs) than in typical command-line or text-input user interfaces. A typical text UI has an input loop that displays a prompt, reads a command typed by the user, parses it, and decides how to direct it to different modules of the program.

If a GUI email client were written that way, it might look like this (in pseudocode):

while (true) {
    read mouse click
    if (clicked on Check Mail button) doRefreshInbox();
    else if (clicked on Compose button) doStartNewEmailMessage();
    else if (clicked on an email in the inbox) doOpenEmail(...);
    ...
}

But in a GUI, we don’t directly write this kind of code, because it’s not modular. GUIs are put together from a variety of library components – buttons, scrollbars, textboxes, menus – that need to be self-contained and handle their own input. For example, here is how you create a button (in various languages):

Java:

JButton playButton = new JButton("Play");

HTML:

<button id='playButton'>Play</button>

TypeScript (accompanying the HTML):

const playButton = document.getElementById('playButton');

The resulting button looks on screen something like this:

Play

This button handles its own input from the mouse and keyboard. Deep inside the graphical user interface library is an input loop that is reading from the mouse and keyboard, and passing those input events to the appropriate components of the GUI.

In order to make your program do something when the button is clicked, you attach a listener to it:

Java:

playButton.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent event) {
        playSound();
    } 
});

TypeScript:

playButton.addEventListener('click', function(event:MouseEvent):void {
  playSound();
});

GUI event handling is an instance of the Listener pattern, also known as Publish-Subscribe. In the Listener pattern:

• An event source generates (or publishes) a stream of discrete events, which correspond to state transitions in the source.
• One or more listeners register interest (subscribe) to the stream of events, providing a function to be called when a new event occurs.

In this example:

• the button is the event source;
• its events are button presses;
• the listener is a function provided by the client – in Java, the anonymous ActionListener instance, and in TypeScript, the function expression;
• the function called when the event happens is actionPerformed.

An event often includes additional information which might be bundled into an event object (like the ActionEvent here) or passed as parameters to the listener function.

When an event occurs, the event source distributes it to all subscribed listeners, by calling their listener callbacks.

So the control flow through a graphical user interface proceeds like this:

• A top-level event loop reads input from mouse and keyboard. In Java and most graphical user interface toolkits, this loop is actually hidden from you. It’s buried inside the toolkit, often running on a separate thread created by the toolkit, and listeners appear to be called magically.
• Each listener does its thing (which might involve e.g. modifying objects in the view tree), and then returns immediately to the event loop.

The last part – listeners return to the event loop as fast as possible – is very important, because it preserves the responsiveness of the user interface.

The Listener pattern isn’t just used for button presses. Every GUI object generates events, often as a result of some combination of low-level input events. For example, in Java:

• JButton sends an action event when it is pressed (whether by mouse or keyboard)
• JList sends a selection event when the selected element changes (whether by mouse or by keyboard)
• JTextField sends change events when the text inside it changes for any reason

And in HTML:

• <button> sends a click event after it receives both a mousedown (the mouse was pressed down) and a mouseup event (when the mouse was released).
• <select> sends a change event when the user selects a different element from the dropdown menu (whether by mouse or by keyboard)
• <input type=text> sends change events when the text inside it changes

button.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent event) {
        ...
    } 
});

new Thread(new Runnable() {
    public void run() {
        ... 
    }
}).start();

playButton.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent event) {
        playSound();
    } 
});

app.get('/song', function songHandler(request: Request, response: Response):void {
   ...
});

playButton.addEventListener('click', function clickHandler(event:MouseEvent):void {
  playSound();
});

Using callbacks requires a programming language in which functions are first-class, which means they can be treated like any other value in the language: passed as parameters, returned as return values, and stored in variables and data structures.

Programming languages are full of things that are not first-class. For example, access control is not first-class – you can’t pass public or private as a parameter into a function, or store it in a data structure. The notion of public and private is an aspect of your program that Java offers no way to refer to or manipulate at runtime. Similarly, a while loop or if statement is not first-class. You can’t refer to that piece of code all by itself, or manipulate it at runtime.

In old programming languages, only data was first-class: built-in types (like numbers) and user-defined types. But in modern programming languages, like Python and JavaScript, both data and functions are first-class. First-class functions are a very powerful programming idea. The first practical programming language that used them was Lisp, invented by John McCarthy at MIT. But the idea of programming with functions as first-class values actually predates computers, tracing back to Alonzo Church’s lambda calculus. The lambda calculus used the Greek letter λ to define new functions; this term stuck, and you’ll see it as a keyword not only in Lisp and its descendants, but also in Python.

Guido van Rossum, the creator of Python, wrote a blog post about the design principle that led not only to first-class functions in Python, but first-class methods as well: First-class Everything.

In Java, the only first-class values are primitive values (ints, booleans, characters, etc.) and object references. But objects can carry functions with them, in the form of methods. So it turns out that the way to implement a first-class function, in an object-oriented programming language like Java that doesn’t support first-class functions directly, is to use an object with a method representing the function.

We’ve actually seen this before in the context of Java threads: the Runnable object that you pass to a Thread constructor is a first-class function, void run().

This design pattern is called a functional object, an object whose purpose is to represent a function. The spec for a functional object in Java is given by an interface, called a Single Abstract Method (SAM) interface because it contains just one method.

Lambda expressions in Java

new Thread(new Runnable() {
    public void run() {
        System.out.println("Hello!");
    }
}).start();

new Thread(() -> {
    System.out.println("Hello!");
}).start();

Lambda expressions in TypeScript

describe("Math.max", function() {
  it("covers a < b", function() {
    assert.strictEqual(Math.max(1, 2), 2);
  });
});

describe("Math.max", () => {
  it("covers a < b", () => {
    assert.strictEqual(Math.max(1, 2), 2);
  });
});

it("covers a < b", () => assert.strictEqual(Math.max(1, 2), 2) );

it("should play the right song", async () => {
  const response = await fetch('http://localhost:8000/song/0');
  ...
});

public interface Dog {
    public String name();
    public Breed breed();
    public int loudnessOfBark();
}

SortedSet<Dog> dogsQuietToLoud = new TreeSet<>(... /* a Comparator<Dog> that sorts by loudness */);
dogsQuietToLoud.add(...);
dogsQuietToLoud.add(...);
dogsQuietToLoud.add(...);
// ...

new TreeSet<>(new Comparator<Dog>() {
  public int compare(Dog dog1, Dog dog2) {
    return dog2.loudnessOfBark() - dog1.loudnessOfBark();
  }
});

new TreeSet<>(new Comparator<Dog>() {
  public Dog compare(Dog dog1, Dog dog2) {
    return dog1.loudnessOfBark() > dog2.loudnessOfBark() ? dog1 : dog2;
  }
});

new TreeSet<>((dog1, dog2) -> {
  return dog1.loudnessOfBark() - dog2.loudnessOfBark();
});

public class DogBarkComparator implements Comparator<Dog> {
  public int compare(Dog dog1, Dog dog2) {
    return dog1.loudnessOfBark() - dog2.loudnessOfBark();
  }
}
// ...
new TreeSet<>(new DogBarkComparator());

playButton.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent event) {
        playSound();
    } 
});

playButton.addActionListener(▶▶A◀◀ -> ▶▶B◀◀);

All our examples of callbacks so far have been from the client’s point of view. The client creates a callback function, passes it to the implementer, and when the desired event occurs, the implementer calls it.

What about the implementer’s side? How does an implementer keep track of callback functions, and make the calls? To illustrate this, we’ll implement a simple counter that calls its listeners whenever it increments.

Counter spec

export class Counter {

    /** Make a counter initially set to zero. */
    public constructor()  { ... }

    /** @return the value of this counter. */
    public get value():bigint  { ... }

    /** Increment this counter. */
    public increment():void  { ... }

    /** Modifies this counter by adding a listener.
      * @param listener called by this counter when it changes. */
    public addEventListener(listener: NumberListener):void  { ... }

    /** Modifies this counter by removing a listener.
      * @param listener will no longer be called by this counter. */
    public removeEventListener(listener: NumberListener):void  { ... }
}

type NumberListener = (numberReached:bigint) => void;

const counter = new Counter();
counter.addEventListener(function(value:bigint) {
    console.log(value);
});

const counter = new Counter();
counter.addEventListener((value:bigint) => console.log(value));

Counter implementation

private _value: bigint = 0n;
private listeners: Array<NumberListener> = [];


// Abstraction function
//    AF(_value, listeners) = a counter currently at `_value`
//       that sends events to the `listeners` whenever it changes
// Rep invariant
//    true

public increment():void {
    ++this._value;
    this.callListeners();
}

public addEventListener(listener: NumberListener):void {
    this.listeners.push(listener);
}

public removeEventListener(listener: NumberListener):void {
    for (let i = 0; i < this.listeners.length; ++i) {
        if (this.listeners[i] === listener) {
            this.listeners.splice(i, 1);
            return;
        }
    }
}

private callListeners():void {
    for (const listener of listeners) {
        listener(this._value);
    }
}

function oneShotListener(value:bigint) {
  console.log(value);
  counter.removeEventListener(oneShotListener);
}
counter.addEventListener(oneShotListener);

Callbacks are our first example of first-class functions, where we treat functions just as we treat data: passing them to and returning them from other functions, and storing them to call later.

Callbacks make code more ready for change by allowing clients to provide their own code to run when an event occurs, so that the behavior doesn’t have to be hard-coded into the implementation beforehand.

Writing a single giant input loop to handle every possible event in a large system is neither safe from bugs nor easy to understand: that single piece of code becomes an all-knowing all-controlling behemoth. Callbacks allow each module in the system to be responsible for their own events.

In future readings, we’ll see further benefits to all three of these properties of good software from the idea of first-class functions.