GUI and event-driven programming

This week A-Track (with B-Track to follow later) students will start using one important Java technology hidden in special object communications and behaviors provided with Java – GUI. GUI is not just a graphical interface but a whole different concept of communications and program logic. It makes threads of interactions with chains of questions obsolete and instead creates a set of windows and controls (buttons for now) that offer the user a choice of how to interact. GUI runs some internal loops waiting for various user actions and responds to any of such actions (mouseover, buttonpress, mouse down, etc.). For example instead of asking if the player wants to play again in a loop that you had to program manually – there is a rich choice of communication controls that user can initiate (like the button “Play Game” as one example) with event (like buttonpress) being passed to the listener waiting behind the scene.

Another important aspect to notice is that you are starting “event-driven” programming when code is executed not when you write your java command on console and even not when logic of one object calls method code to be executed from another object, but when some interface event happens that is passed to the listener object AND TRIGGERS its execution. AWT, that you include in the beginning of the program supports such event driven mechanism allowing various listener objects to subscribe for notification about some possible events happening to certain controls (text boxes, buttons, check boxes, radio buttons, etc.). When the event that the listener subscribed for occurs – Java “notifies” the listener by sending an event class with rich information about the event and allowing to trigger the code execution.

This shifted the method of program communication with the user from program-initiated one, with lots of loops polling the user for required information forcing to write complex logic fitting this loops in special sequences and nesting constructions, to user-controlled or event driven as described above. The benefit of MVC model and previous separation of Account and GameMachine classes from the Interface is that the new changes to GUI are done ONLY in the Interface class (if you PROPERLY separated it). If not – it is time to move the remaining game and accounting and possible other supporting actions into the Model section, which can consist of several classes interacting with each other or with Control components (listeners). In this case it is also good to clear the Application class with main() method from everything else just letting it start the Interface Window and instantiate the Interface class, which in turn will instantiate other necessary classes. It is not necessary to such clean-up of the Application class now but this is what you be doing later. In your first GUI driven program is important just to get rid of all user polling and allow for necessary windows and buttons to be properly placed on the main Window