9.3.2 Viewer Implementation

When implementing the viewer functionality using the Swing framework, it is important to bear in mind the issues described in Section 9.2.2 with respect to delayed rendering. In Swing, the process of painting the GUI components is carried out in an independent thread which accepts asynchronous notifications of changes to the presentational data. Therefore, the presentational data must be cached on receiving update notifications from the main reactor thread.

In the example given here, the viewer component accesses the current model state using the appView instance of the view interface previously shown in Listing 9.5. This provides access to a single item of presentational data, in the form of the current stopwatch timer value. In this case the raw timer data is not cached directly, but pre-formatted within the context of the Reaction view update callback. This is illustrated by the code fragment shown in Listing 9.8.


\begin{listing}
% latex2html id marker 2006\begin{verbatim}...
// Local ver...
...}
\caption{Caching the Stopwatch Data on Reaction Update Callback}
\end{listing}

Once the cached presentational data has been updated, the Swing framework is notified of the changes using the panel repaint request method. This causes the displayed view of the data to be repainted at an arbitrary point in the future, within the context of an arbitrary Swing framework redraw thread.

The procedure used to repaint the displayed view from within the context of the Swing framework redraw thread is a standard text rendering routine, as shown in Listing 9.9. This takes the currently cached string representation of the stopwatch time and renders it to the screen at a specific position in the displayed window.


\begin{listing}
% latex2html id marker 2013\begin{verbatim}...
// Create a ...
...tim}
\caption{Rendering the Stopwatch Data on Swing Paint Request}
\end{listing}

Figure 9.1: Running the Stopwatch Example
\includegraphics[width=.7\textwidth]{guisupport.figs/StopwatchExampleWindow.eps}

The combination of the buttons added to the GUI window in Section 9.3.1 and the rendered version of the current stopwatch time yields the window display shown in Figure 9.1. This looks and behaves just like a conventional Swing based application, even though the underlying Reaction based model is completely independent of the GUI toolkit being used.