Structure

The Smashboard source has been modularized to conform around the object-oriented paradigm symbolized by Java and the Swing framework. Implementation of new widgets and features has been made easy due to this design protocol.

The root of the project consists of base classes that define the properties of the application and allow developers to effortlessly adjust them to match their team. Refer to Figure 3 for a UML Diagram of the base of the project (and utilities). Dashboard is the main class to define properties of the application frame where the canvas is drawn on. Thus, instance data such as the size, title, color, etc. belong to it. The canvas that is drawn on this dashboard is defined in the Canvas class. As per the UML, Dashboard creates, or instantiates, a Canvas that belongs to that Dashboard. The Canvas contains data on the properties of the painted objects for the dashboard, such as the static images and data displayed. Static Images are images that are simply displayed for decorative purposes and should not change during the life of the application. Data accommodates those data that must be displayed on the canvas, and binds them to a specific widget. A key belongs to each Data object that is used to retrieve records in the Network Tables matching it. Utilities are used to provide complex services that are simplified by functions to perform them with ease, such the interpolation of two colors. All of these classes commit to the implementation of the main running class, Smashboard. This instantiates Dashboard and defines all of the data that must be displayed onto it. It also sets up the update loop that calls all the update methods for each referenced object. The update loop is a simple infinite loop that delays between each frame, probably due to pinging the Roborio for the Network Tables. This setup allows very simple implementation of new features with methods for each step in the application’s life.

The Widget hierarchy (see Figure 4) is a very straightforward order in which each widget contains specific properties and behaviors that abide to the Dashboard lifecycle. Each widget possesses basic properties that define their position on the canvas. They also possess behaviors that are overridden by each child, including an initialization method, a paint method (to draw the widget on the canvas), an update method (that is invoked in the main update loop), and mouse events. With these base properties and behaviors defined for each widget, it is simple to implement new ones as to construct a completely new and functional feature. For example, the gear holder status widget simply declares two new attributes: the open status and the widget for the closed status. With this, the parent methods are overridden and the operations for these attributes are actualized. Polymorphism is used to accomplish all of this and maintain the modularity.

In all, the structure of the Smashboard has an emphasis on standardized units that allow the development of new tools to be elementary and efficient.