-
Notifications
You must be signed in to change notification settings - Fork 2
User Interface Package
This page is going to go over the user interface model of the project. It will discuss the overall design of the ui package as well as provide insight into how components interact. This page, like many others, will be added to as the project develops and is not set in stone.
In the ui package there is an abstract Control class which is the basis for any class that wishes to handle user input. The Control class is based on the idea that every Control is responsible for reporting information to an object based upon some input by the user. So, we can say that every Control has both a Task and a Controllable object to which it pushes input information to. I have defined a Task to be an enumeration for now, it includes general tasks that may be applicable and utilized by a variety of objects. The Controllable interface is implemented by objects that wish to be controlled by Controls, the objects must provide methods that can receive input from any Control because input information may vary between the types of Controls that are defined.
Information about Control sub-classes coming soon...
In the ui package there is an abstract Element class which is the bases for any class that wishes to provide graphical information to the screen that is not a control, it may or may not have a graphical representation that is updated in game time. An example would be a Gauge that displays the current altitude of the aircraft and is updated constantly. Another example could be a background for a menu that is just a static image. Elements that are updated within the game based on the state of other objects should follow a publisher/subscriber model where the publisher in the previous Gauge example would be the aircraft and the subscriber would be the Gauge element. This is more formally known as the Observer pattern. The element should be able to register itself with the aircraft when it wants to receive updated information and unregister itself when it no longer needs information. The aircraft should implement some type of observable interface and any elements that need to receive information should implement some sort of observer interface.
Note, the observer/subscriber code is not provided in the Element class itself because it is not inclusive to the class, elements encapsulating static images have no need for this code and objects that are not Elements might need it as well. The reason I put this information here is because this design will occur in a lot of the concrete classes of Element.
In the ui package there is a UserInterface abstract class which is the basis for any user interfaces that are displayed to the user throughout the life cycle of the application. A user interface is simply a screen with one or more controls and zero or more elements that is displayed and can interact with the user. The general model for implementing this concept is to have each UserInterface object contain one or more UserInterface objects that have been registered with a control. These controls are held within the current object and are updated of screen activities. If a control indicates to a UserInterface that it has been pressed, the UserInterface will mark itself as active and when the current UserInterface sweeps through the collection of UserInterfaces and sees that it has been marked as active, it will do a context switch and allow that UserInterface to take control. The old UserInterface could be stored externally if desired and reloaded if the user wishes to go back. The new UserInterface will construct it's graphical elements and the process will repeat.