The digital Webster dictionary application running on my workstation defines primer as "a small introductory book ". Alongside my workstation there is a collection of Java reference books. A quick Web search reveals that, despite Java being less than two years old, there are already well over one hundred books about Java published. I feel that I should justify adding further to this plethora which already includes other introductory books.
This book is described as a primer in contrast with the many tomes some of which contain well over a thousand pages and promise on the cover to teach the reader everything they need to know about Java programming in a frighteningly short period of time. I have been involved with teaching Software Engineering and Software Development for over two decades and my minimum estimate for the transition from novice developer to an initial competence would, for an exceptional student, be in the order of two years. For an experienced developer, without experience of GUI design and development, a shorter period of time might be required by many new concepts and considerations would have to be assimilated and new skills practiced. Consequently this book makes much more modest claims about what it might be able to do for the reader.
AWT and GUIs
This book assumes that the reader is already minimally competent in Object-Oriented Software Development and has some experience of implementation using C++ or Java. (If you are reading this preface with a view to starting to learn Software Development, and Java, from scratch, you should be reading the preface of my Java: An Object First Approach book instead.) This book is intended to allow readers with this minimal competence to obtain an initial competence in the skills involved in using the Java Abstract Windowing Toolkit (AWT) to develop applets and applications which have a Graphical User Interface (GUI).
The development of GUIs adds a further layer of considerations, and complications, to those already involved in the development of general purpose software artifacts. The first of these considerations is that such interfaces must have usability engineered into them from the outset. In the recent history of computing there have been two products, Apple's Hypercard and Microsoft's Visual Basic, which have given developers both an environment and a platform to produce highly interactive graphical artifacts. Despite some excellent applications produced using these tools the average quality of products developed with them has been abysmal.
The reason for this is that, in some senses, they have been too easy to use allowing unskilled and untrained programmers to produce GUIs which do not embody any consideration of the user. Some years ago an educator in California asked on the Usenet comp.lang.visualbasic newsgroup if anyone could advise her on design techniques which she could introduce to her students. There was absolutely no reply from the global community of Visual Basic developers. Concerned about this she asked again, more insistently, and received a single reply. The author of the reply admitted that they too did not know how to design Visual Basic applications but recommended my book on X/ Motif as a good place to start.
User Interface Models
It is against this background that I prepared this book. Like the X/ Motif book the central consideration is the modeling of a user interface in the form of State Transition Diagrams (STDs). From these it is possible to divide the application and its interface into three areas of concern: the visible part of the interface, the program logic which controls it and communicates with the third part which provides the application's functionality. This concern with usability from the outset of the design and production process attempts to ensure that the artifacts produced have a high level of both software engineering quality and usability.
Unified Modeling Language design notation consistently used and emphasized. Exclusive use of release 1.1 of Java and its AWT. Interface usability modeled using State Transition Diagrams (STDs). Software design by consistent use of class and instance diagrams. An example of every 1.1 AWT component included. A case study illustrating different user interface styles. Internationalization and localization techniques. Production of specialized components covered.
The book starts in Chapter 1 with an overview of the developmental process where an initial artifact is designed and produced. Chapter 2 then briefly introduces each of the components which the AWT supplies. Chapter 3 starts the process of illustrating how the existing components can be extended by the developer to satisfy particular requirements. This is considerably easier in Java than in any other common GUI development environment and is central to the production of high quality interfaces.
Chapters 4, 5, 6, and 7 can be thought of as a case study where four different styles of interface are provided for a single application. The application chosen is a Logo style turtle graphics environment known as the tuttle. Some of the interface styles presented are dramatically unsuitable for the controlling of a tuttle. However the intention is that these techniques for the construction of these styles of interface can be applied where the style would be more appropriate. The first of these chapters, introducing the tuttle, also provides an introduction to Java's general purpose graphical and image processing capability.
Chapter 8 extends the functionality of the tuttle, and of its interfaces to encompass undo, save and load capabilities. The final chapter, Chapter 9, introduces Java's facilities for customization, localization, and internationalization. The importance of these considerations belies their location in the sequence; however it would not be possible to introduce these techniques before Chapter 3. Consequently Chapter 9 could be read following Chapter 3, before the tuttles are considered.
Appendix A supplies information concerning other resources which might prove useful. Appendix B contains the source code for some of the classes which do not seem important enough to be included in their corresponding chapters. Appendix C discusses the terminology used in this book compared with the terminology used in other resources. This appendix also provides a reference to those parts of the Unified Modeling Language (UML) notation which is used to express the STDs, class, and instance diagrams.
At the time of completing this book, version 1.1.5 of Java, and of its AWT, had just been released. (Details of how to obtain it are contained in Appendix A.) All of the source code in this book has been compiled with the -deprecation flag against Sun's 1.1.5 javac compiler. During this process I noticed that several constructs which should have caused a deprecation warning to be issued, indicating that they should only be used with the 1.0 Java version, were compiled without comment.
Consequently, although I think that the book is fully compliant with the 1.1 specification, and makes no use of 1.0 constructs which should not be used, I cannot be certain of this. Likewise although I have carefully engineered all the examples used in the book, and tested them on Windows 95, Unix and, partially, on Macintosh platforms, I cannot be certain that there are not any remaining bugs. All I can do is ask that if a reader finds any use of 1.0 facilities, or uncovers any bugs, they should e-mail me the details and I will maintain a list of problems on the Web site associated with my Java books. The URL of this site is given at the end of the preface.
The typographic convention adopted is to use normal italic text whenever a new technical term is introduced, or its meaning significantly elaborated. Helvetica is used for any Java terms used with bold Helvetica for reserved words and italic Helvetica for developer decided terms. Program listings are in small courier with preceding four digit line numbers. Phrases from design schematics which do not directly translate into program terms are also presented in normal italic.
This is the fifth book I have written in the last six years and I have promised my family after completing each that that I would not start another one, at least for some time. They have accepted this promise with more than a pinch of salt and have not complained (too much) about my self-imposed incarceration in my office at times when I should have spent more time with them. Although they are getting rather pass about seeing their names in print; Maria, Leah, and Seana are still providing plenty of hot coffee and patience. Peter Chalk again took it upon himself to critique each chapter in detail at various stages in its production. This was twice the task associated with previous books and he did not complain when the 1.0 draft was rewritten to 1.1. standards. Jackie Harbor was again consistently supportive and made herself immediately available when consultations about the book's production were required. The proximity of the best pizza restaurant in London (the Castillo at the Elephant and Castle) had very little to do with this. Derek Mosely and Alison Stanford provided efficient and effective support to Jackie at Prentice Hall. A selection of students at South Bank had, for them, the rather un-unique experience of allowing themselves to be guinea pigs for yet another of my books. Their experiences with the tuttles chapters in particular revealed several obscure and subtle faults. I would also like to thank Robert Hermann of Sun Microsystems and Jack Hodges of San Francisco State University, who reviewed the manuscript.
South Bank University: London