simpleIO: A Java package for Novice Interactive and Graphics Programming

1. INTRODUCTION

Twenty years ago simple constructs in BASIC and Pascal made interactivity and graphics accessible to novice programmers. The requisite techniques were easily incorporated into introductory curricula in Computer Science[2]. Students were highly motivated to complete programming assignments because projects were fun. Current introductory CS courses have lost that motivation because graphics and interactive programming is difficult in modern Graphical User Interface (GUI) environments. Programming GUIs is inherently concurrent and depends upon mastery of concepts such as events and threads[1,5]. In this paper we discuss some possible solutions to this problem, and present a support library called simpleIO that we developed[3]. The package allows novice programmers immediate access to GUI functionality and text file handling in Java.

The "old fashioned" languages such as Turbo Pascal included graphics and interactive primitives that directly controlled the input and output devices of these machines. To receive user input, a programmer wrote code that suspended all activity until the user response was complete. This is a form of a turn taking dialog. Neither the computer nor the user may proceed until it is their turn to do so. This model is easy for novices to understand and also reinforces the idea that an algorithm is a sequence of steps that describes a solution.

Modern GUI environments support a different interaction. Both the user and the system may be engaged in a number of simultaneous activities through display windows that either may modify. Rather than responding to a simple prompt or a hierarchical menu, the user initiates activities through a variety of devices such as buttons, menus, dialog boxes, or more directly through mouse movements and clicks as well as key strokes. The program therefore must be attuned to a variety of input devices; ready to change context at any time. Clearly, this is not a methodical turn-taking dialog that can be captured in a straightforward sequential process. Programming GUIs therefore requires some level of comprehension of input events (such as mouse clicks) and concurrency (to switch contexts based on user input).

GUI programming is also inherently object-oriented[4]. Managing the sheer complexity of multiple windows and input devices requires a programming viewpoint that encapsulates data and methods and goes beyond either procedural or functional models.

At least two questions arise with regard to a first course in programming. To what degree should students be required to master the nuances of GUI concepts? To what degree should they be required to master object-oriented techniques? Pessimistically, programming GUIs is hard, and should therefore be avoided. But then we loose the compelling projects that are interactive and employ graphics[6]. Optimistically, programming GUIs may reinforce object-oriented programming. Besides, as our students contend, it is fun.

We have identified five general approaches to the problem:

  1. Ignore GUIs entirely. Require students to write text-based programs that use input/output constructs based on libraries such as C's stdio, C++ ioStream, and the Java System.in and System.out classes.
  2. Promote non-sequential programming models from the onset by embracing GUI and concurrent programming immediately; for example introduce the Java Abstract Windows Toolkit (AWT)[1] and the Java Thread class immediately.
  3. Have students write program fragments rather than complete programs.
  4. Include instruction in the use of a GUI-design tool that supports a general purpose programming language. Visual BASIC is an example.
  5. Use special purpose libraries that enhance a general purpose language.
 We have adopted the fifth solution in the belief that students should learn to write complete programs early on, that they have enough to master without the complexity of non-sequential models, and that learning GUI-design environments detracts from the proper focus of a first semester course in Computer Science. Furthermore, as we will argue in the next section, we believe that ignoring GUIs is not only boring, but actually thwarts the development of good design and implementation skills, especially in Java.

The simpleIO package we describe allows novice students to write a single sequential Java program that follows a turn-taking dialog within the broader context of a GUI and thread-based Java environment. The student writes a complete application in Java, inheriting interactive functionality from our class SimpleGUI. As we will show, our model reinforces good object-oriented programming style in Java without initially burdening the student with many complex concepts and a deluge of esoteric detail. Furthermore, unlike GUI-based design tools that may detract from the focus of the course, our package reinforces essential programming principles such as using methods (procedures), passing parameters, and operating on the results of functions.
 

2. EXAMPLE WITH simpleIO

Figure 1 shows an example of a first program written by a student at one of our institutions to convert temperature from Fahrenheit to Celsius. Two classes are defined, an application class ConvertApp and a support class ConvertTemp. The application creates an instance of ConvertApp and calls its methods getFahrenheit and showCelsius. Since ConvertTemp extends the class SimpleGUI, it can call SimpleGUI methods such as getDouble and displayResult (underlined in the code.).
 
Figure 1: A Temperature Conversion Program

Figure 2 shows a sample run. All of the user interaction, including the error dialog is handled by the simpleIO package. The novice student programmer is not distracted from the problem at hand: temperature conversion, but gains an appreciation for interactivity issues as well as for delegating responsibility to other classes. Students are quickly engaged in object-oriented design, if only on a superficial level.
 

2.1 simpleIO Promotes Good Design

One aspect of good design is to maintain the integrity of the language in the support package. Therefore, the simpleIO package encourages the use of class instances rather than static classes and discourages the use of class (static) variables except where they are appropriate. This is in contrast to packages that enhance the usability of System.in and System.out, which may encourage students to misuse static objects. Another aspect of design is to concentrate on the task at hand, and delegate responsibility for sub-tasks to other classes or methods. This is classic top-down design.

When students initially use standard text-based packages such as Java's System.out.println, or C's stio, either their interactive code is terribly brittle, or they get side-tracked from the algorithm they are implementing as they grapple with converting text to other data types. Typically, the student must convert from bytes or the String class to the proper numerical type. The simpleIO package avoids this and instead promotes the concept of delegating responsibility. The code the student writes is a straightforward example of a method call. The error detection is built into the SimpleGUI methods.

Figure 2 showed an example of an error in the user interaction. The student gains an appreciation for the need to create robust code without being required to master complex concepts. The student can focus on getting the requisite input, without the distracting problem of converting the input from one form to another.

 
Figure 2: Execution sample of Temperature Conversion Program

3. THE simpleIO PACKAGE

Our goals for the design of the simpleIO package were as follows.
  1. The interface is for classroom use.
  2. Beginners need to focus on a single thread.
  3. Keep a history of results.
  4. Keep it simple.
  5. Save and print results.
  6. Cover the basic data types plus menus.
  7. Integrate graphics and interactivity.
  8. Support simple access to text files for the basic primitive types plus Strings.
 

3.1 The SimpleGUI environment

In Figure 2, a main window, labeled "User Interaction History" appears when a SimpleGUI object is created. All input methods (with prefix "get") display their prompt and their result in this window. There are two output methods: displayResult, shown above, and displayRow, that displays the contents of an array. The history window is useful for instructional purposes: the entire execution may be viewed, saved or printed, for example for inclusion in a student lab report. The attributes of the history window may be customized, for example the font size may be increased during a lecture for viewing by a large audience.

3.2 Text responses: double, int, char, String.

In Figure 1 real input is received from the user via the getDouble method. The SimpleGUI class also supports methods for primitive types int, and char as well as the String class. We chose to support only one primitive type each for reals and integers to reduce package's complexity. The getType methods allow the programmer to specify the display prompt as illustrated in Figures 1 and 2.

The methods for the primitive types also allow the programmer to specify a lower and upper bound, for example, a range of integers. The getType methods are overloaded. A single string argument to the method resorts to a default range. Otherwise the student can specify the range as the second and third arguments. This is an example of how we reinforce standard Java techniques. Novice programmers see many examples of method overloading before they write it themselves.

3.3 Programming Boolean Choices

Novice programmers may not appreciate the full potential of Boolean values because they have little opportunity to receive such values from a user. For example, in traditional text-based dialog, the user might respond to a true/false (yes/no) query with a character such as "Y." The student is forced off the task at hand to the problem of what character input to tolerate, and how to interpret the result. For example the student must encode a complicated statement such as "if the user typed one of the following characters then do this, otherwise do that."

We encourage the use of the boolean type through a SimpleGUI overloaded method called getBoolean. Fig. 3 shows code fragments and the corresponding display. The form that has a single string prompt as an argument produces a "true" value by default. The second form allows the programmer to specify a choice.

Figure 3: Examples of getBoolean

3.4 Multiple Choice Responses

Another problem in text-based dialog is selecting from a discrete set of input, for example selecting from the days of the week. Such user input can control cascading if/then/else or switch statements. However, implementing the input choice is often far more complicated than implementing the decision choice, and the former detracts from the latter. For example, the student may have to write code that requests a number corresponding to the day, then confirm that the number is in bounds etc. A classic repetitive solution for such error detection is fundamentally wrong with GUIs in Java. A thread should be used instead. More to the point, the user input should come from a menu not from an integer value.
 
Figure 4: An example of getMenu

Figure 4 shows how we support menus with SimpleGUI method calls. The format follows the style of the AWT for adding items to a GUI component, and thus lays the foundation for understanding the AWT later. The programmer creates the menu with SimpleGUI method createMenu, then calls addChoice repeatedly with a string argument. The method getChoice uses its string argument as the prompt for the menu, and returns an integer corresponding to the list position of the selected item.

3.5 Graphics and Interactivity

Rudimentary graphics programming is compelling for beginners, and has pedagogical value because the function calls that render graphics images give practice in passing arguments. The Java AWT class Graphics supports the standard objects: lines, rectangles, ovals, arcs as well as strings. These may be displayed in a multitude of colors and figures may be filled. Images such as gifs and jpegs may also be displayed.

A Graphics object is instantiated when an AWT component such as an Applet is created. The corresponding Graphics instance is called within the component's paint method. To render graphics, the programmer extends the Applet, and over-rides the paint method to include method calls to the Graphics instance. In our experience students quickly grasp the technique because it reinforces concepts of extending a class and over-riding a method.

But without a thorough knowledge of events, even experts find it hard to integrate graphics and interactivity. Our simpleIO package contains a class SimpleGraphic.. Just like an Applet is part of a web browser, the SimpleGraphic object is part of a SimpleGUI object. Students draw with the same technique as with an Applet, but have the added functionality of SimpleGUI interactive methods.

3.6 Files

Text files are typically part of the CS 1 curriculum, however in Java, persistent storage of data should be accomplished by serializing a class rather than storing to a file. However, the serializing features of Java are still relatively new and unstable[1]. File and stream handling in Java is very sophisticated, and consequently very complicated for novices. We therefore extended the Java Reader and Writer classes, creating SimpleReader and SimpleWriter in the simpleIO package that behave in the classic open file, operate sequentially, close file model. They have methods (getType and putData) that correspond to our getType and displayResult methods. Our basic data types can be stored as strings in a text file. We use these classes and methods sparingly, and defer the discussion of serialized objects to CS 2.

4. SUMMARY

The simpleIO package gives students easy access to interactivity with graphics in Java. But the package was intentionally designed to be limited. We encourage students to go beyond it and learn to user the AWT. The design of the package was modeled on the AWT. It encourages students to create, instantiate and extend classes, thus supporting good object-oriented programming habits in Java.

The simpleIO package is implemented in Java 1.1 and should continue to function correctly in Java 1.2. It has been tested on MacOS( 7.5 and up) under Codewarrior, on Windows95 under JBUILDER and Semantic Café, and on Solaris (Sun) with the JDK. The package may be obtained at DELETED TO REMAIN BLIND..

5. ACKNOWLEDGEMENTS

Lana Kucherovsky implemented the original version of SimpleGUI. Versions 2 and 3 were developed at (DELETED) by a group of undergraduates. Thanks to Joe Turner, Penny Anderson, Norm Neff and Shawn Sivy for insights into pedagogy and system design.
 

REFERENCES

  1. Chan P. and R. Lee "The Java Class Libraries Second Edition" Addison Wesley, Reading MA. 1998
  2. Koffman, E. "Turbo Pascal 5th Edition" Addison Wesley, Reading MA. 1995.
  3. Deleted to remain blind.
  4. Shneiderman, B. Designing The User Interface, Third Edition, Addison Wesley, Reading MA. 1997.
  5. van der Linden, P. "Just Java, second edition" SunSoft Press, Mountain View, CA, 1997
  6. Wolz, U., D. Domen, & M. McAuliffe, Multi-media integrated into CS 2: An interactive children's story as a unifying class project , SIGCSE Bulletin Vol. 29, no. 3, 1997, Conference Proceedings of ITiCSE 97