What's Interesting?
Check out these pages to find out the most
interesting features of the Game and
Player programs and investigate the code
that implements them.
This section analyzes the design of classes that comprise
the Game and Player applications, including discussions
on why we made certain decisions and the tradeoffs we made
in doing so. In particular this section focuses on
decisions we made about subclassing, using interfaces, using anonymous
and inner classes, and how we arranged the classes and interface
in packages.
[PENDING: this section is under construction]
A collection of box diagrams show you the
classes that implement and control the various elements in the
GUI's of both the Game and the Player applications.
Both the Game application and the Player create and use many
threads. When different threads access and change the same data
concurrently, the threads must be synchronized to avoid errors.
Additionally, some threads depend on state changes that are
affected in other threads. In cases such as this, the threads
involved must coordinate.
The Player and the Game communicate in two different ways:
the Game broadcasts status information and
the Player makes requests of the Game.
This talks about the JDK APIs that we chose to
accomplish these feats of communication and why we chose them.
Then the section goes on to describe the classes and the
code that participate in the communication between the Game
and the Player.
To protect against cheating, the Game
signs all BINGO cards played in each game.
When a Player claims to have a winning card, the Game
verifies the signature on the card to make sure that
its was signed by this Game for the current game.
[PENDING: this section is under construction]
Like other applications, the Player and the Game applications
contain UI elements that let the user tweak various program settings.
(Program settings are often called parameters or properties.)
This section looks at the code in the Player that manages the
application's settings. The discussion takes a top-down approach
and looks at each layer in the code that takes a part in managing
the program settings, from the user elements, to how the various
settings affect the play of the game, to how the application uses
the JDK's Properties mechanism to remember settings between invocations.
[PENDING: this section is under construction]
