Introduction to GUI Programming

Most of the programs you have written so far probably communicated through text: a line of output in a console, a number printed, or a message typed back to the user. This article introduces a different kind of program, one whose result is a picture that appears in a window. The example is called SimpleGraphicsStarter.java, which comes from Section 3.9 of the text. Its job is easy to state: it draws a large number of disks, and each disk is randomly colored and randomly positioned.

As you read, keep one question in mind: after the program has finished drawing, what does the graphics window look like? The rest of this article builds the answer step by step, starting from the idea of a graphical user interface and ending with a before and after view of the window.

The text describes SimpleGraphicsStarter.java as the first example of a GUI program in the course. This is a useful starting point because the program is small enough that you can see the whole idea at once: it produces a graphical result, and that result is what the program is about. Later programs in the text build on this same idea, so it is worth understanding this first example clearly before adding more complexity.

The defining feature of SimpleGraphicsStarter.java is that it generates graphics with random properties. The program draws a large number of disks, and each disk is randomly colored and randomly positioned. The word randomly applies to two properties of each disk: its color and its location in the window.

Because the properties are random, the program does not draw one fixed picture that you could predict in advance. It draws many disks, and each one has its own color and its own place. Taken together, the drawing is a collection of disks that all differ from one another. Thinking of the final picture as a collection, rather than as a single object, is the key to reading the program's result.

To read the result, compare the graphics window before and after drawing. The figure below shows the window at two moments. Before the drawing, the window has no disks in it. After the program has drawn, the window holds a large number of disks. Each of those disks has its own color and its own position, which is what the source means by randomly colored and randomly positioned. The change from the first state to the second is the whole effect of the program.

Notice what the diagram does not claim. It does not say which color any particular disk receives or where it lands. The source only states that each disk is randomly colored and randomly positioned, so the trace tells you the kind of change that happens and the kind of picture that results, not a fixed list of exact values.

Running the same graphics program twice does not give you the same picture twice. The code and its structure stay identical from one run to the next. What changes is the set of random values chosen for each disk's color and position, so each run produces disks with different properties.

This is why the question to ask is about the kinds of properties the output has. Two runs can both show many disks, each with its own color and place, while looking different in every specific detail. The shared structure of the output is predictable even though its exact appearance is not.

Imagine you have written a working dynamic array for integers, a container that grows as you add items. Now you need the same thing for strings, then for decimal numbers, then for colors. If the only real difference between these versions is the name of the element type, you are copying the same logic over and over and editing one word each time. Programmers find this tedious, and every copy must be maintained separately. Generic programming is the response to that situation. Its goal is to write the code once, in a form that works for many different types of data.

Consider what changes between a dynamic array of integers and a dynamic array of colors. The steps for adding an item, growing the storage, and reading an item back are the same. The only detail that differs is the name of the type of item being stored. When two pieces of code differ only by a type name, the underlying idea is general, and the type is an input you have not yet abstracted away. Generic programming removes the repeated copies by leaving that type open.

Java's approach to generic programming is parameterized types. A class such as ArrayList leaves its element type open, and it is used as ArrayList<String>, ArrayList<Color>, or more generally ArrayList<T>. The figure below labels each part of ArrayList<String>.

Read ArrayList<String> as follows: ArrayList is the class, and String is the type parameter that fills the open slot. The type inside the angle brackets is the element type, which means this list is used for strings. There is only one ArrayList class. The type inside the angle brackets is what changes between uses, so ArrayList<Color> uses the same class with Color in that slot.