-
Notifications
You must be signed in to change notification settings - Fork 0
View Model
GameViewPresenter
implements the interface GameViewInput
, which defines several input operations used to perform interactions with the UI.
The first four operations playClicked
, pauseClicked
, undoClicked
and redoClicked
are event-handlers for clicking on buttons.
Further, the input operation speedChanged()
is used to change the delay, which is inserted between game commands.
GameViewPresenter
implements these operations by delegating to the GamePerformance
class.
Finally, there is a close()
input, which indicates that the user wants to close the application.
Besides derived input operations from GameViewInput
, the presenter defines a bind()
operation.
This operation contains most of the UI logic, since it picks the relevant parts of the core model and adds observers to them.
Using these observers, the view-model will be updated accordingly.
For common UI logic, the mpw simulator framework includes a GameViewPresenterBase
class derived from GameViewPresenter
, which can be derived by concrete presenter classes.
The view-model itself is defined by the class GameViewModel
, which provides any information used to control the visible state of the UI.
It defines four boolean properties playButtonEnabled
, pauseButtonEnabled
, undoButtonEnabled
and redoButtonEnabled
, which each define if the related button shall be enabled.
The speed
property can be used to display the current speed value, e.g. by a slider-control.
The helper operation getCellAt()
is used to return the related ViewModelCell
object for a given row and column position.
With init()
, the GameViewModel
takes a Size
and creates the given amount of ViewModelRow
and ViewModelCell
objects.
Further, it stores the dimensions in the property size
.
The main content of the view-model is defined by the ViewModelRow
references.
Each ViewModelRow
is representing a row of the stage.
While a row of a stage consists of Tile
objects, in the view-model ViewModelCell
objects are used, which are stored in the cells
containment reference.
Therefore, each ViewModelRow
has to contain one ViewModelCell
for each column of the stage.
The contents of each cell in the view-model are defined by objects of type ViewModelCellLayer
.
Typically TileContent
objects are mapped to these layers, which are ordered and represent images to be rendered.
Since the view-model has a clear focus on the information to be rendered on screen, it contains a logical name of the target image in the attribute imageName
.
Further, it defines the rotation in degrees and a boolean flag, indicating if the layer shall be hidden or visible.
Since these information details are filled by the presenter, the UI framework specific part has no special logic regarding rotation, ordering or selecting the images for a cell.
Besides rows, cells and layers, the view-model also defines the list of log entries.
They are stored in the containment reference logEntries
and are represented by objects of type ViewModelLogEntry
, which defines a message
and a color
.
These entries are intended to be displayed in a list of strings, which can be colorized to indicate further information like which hamster has done the relating action.
Defines the input interface for the view. On the one side it defines the "Controller" input methods. On the other side it provides the ViewModel
.
Implements the ViewInput
interface and processes the UI-logic. It contains the ViewModel
to present information for the view.
A observable data structure which contains all relevant information which is displayed on the screen (from the UI-logic point of view).