Java GUIs in JavaFX Event-driven Programming, Separation of Concerns, the Observer pattern and the JavaFX Event Infrastructure 1
GUIs process inputs and deliver outputs for a computing system Inputs Click a button to perform an operation Type keys to provide text or set values Move to a new focus (another control) Drag/select visual components Accept different inputs that mean the same Outputs Show a graph of a value over time Display text, graphics, images Present audio Display a system value in various ways 2
JavaFX Event Class Hierarchy A user stimulates the system through the GUI The GUI generates events for the stimulus The GUI forwards those events to handlers 3 Handlers fulfill the system function
javafx.event.eventhandler EventHandler<T extends Event> class The interface for handlers has one method. void handle(t event) It is therefore a functional interface. The class Control allows registering of EventHandlers void addeventhandler( ) We will stick to ActionEvents. setonaction( EventHandler<ActionEvent> eh) For Button, ChoiceBox, TextField,... 4
Adding and Removing a Handler Also Called 'registering' and 'unregistering' Methods are found in javafx.scene.node JavaFX GUI objects interact with each other To add a handler (advanced): addeventhandler( EventType<T> eventtype, EventHandler<? super T> eventhandler) To remove a handler: 5 removeeventhandler( EventType<T> eventtype, EventHandler<? super T> eventhandler)
Division of Responsibility GUI controls accept input stimuli But should a Button do the work to respond? A Button won't then be reusable GUI views display system values/state What decides how to show that state? A value could be shown as text or a graphic or both at different times or for different audiences 6
System Design Divide a system into components Modular design tells us this Assign tasks to components to organize it Divide and conquer! A component should do one thing well Focus like a laser on its job Then make the components communicate That means the GUI must tell other components what the user wants, and display to the user what is happening elsewhere. 7
Separation of Concerns Goal: Keep IO and Operation domains separate External Input/Output Domain Domain of Operation Show Act Upon GUI Component System Component User or other system 8 Events happen between components here Provide support for value displays and input entry And here Provide application response to input and output delivery
Example External Input/Output Domain Domain of Operation See text Press button Button( Take Action ) ok listener or event handler that was added to button EventHandler< ActionEvent> User or other system handle( ActionEvent ) { System.out.println( ok ); } 9
Subject-Observer Pattern Closely related to event handling is the Observer Pattern. A Subject sets itself up to be 'seen' by other objects the Observers that want to view An Observer calls the subject to add itself as a listener for changes to the subject 12 The subject notifies its observers when the subject changes state by calling a standard method update() on its observers Observer's update decides how to respond Decouple the subject from details of observer.
Observer Pattern 13 https://sourcemaking.com/design_patterns/observer [10/2017]
Updates and Notifications We can write Observer code (observer) that is told when a GUI event happens. Button clicked, call the observers (handlers). But remember the GUI has no observable state. The true Observer case is when the state of the actual application (model) changes Change can be internally/externally caused In this case, the Observable (subject) needs to tell the GUI that something changed source? 14 mutating action Application Base Model update GUI Component (observer)
Observer Pattern Java's Observer pattern is in java.util The Observer interface: void update(observable o, Object arg) extra data passed from observable to observers Major methods of the Observable class: 15 void addobserver(observer o) void notifyobservers() void notifyobservers(object arg) void setchanged()...
Model-View-Controller: Decoupling a GUI from its Subject A GUI presents information to the 16 outside world May change at different rate from system A GUI's Input processing feeds data and commands into the system Needs an interface to operate through The Subject system operates on input and produces output Does not want to tie tightly to any one display because there may be different evolving needs Provides an interface for feeding data and commands in and sending results out Evolves separately from the view and the control of input
Model-View-Controller: Decoupling a GUI from its Subject View VIEW Components Major boundary is between the problem domain and the user interface. Model defines the connection points. Physical Action Model uses abstract interfaces. Control should provide visual feedback. For example a button shows a visible response to a click. MODEL Components 17 CONTROL Components Control and View interact with the model through a specific problem interface.
notify Sequence of Calls in CounterGUI Button event handler GUI Application TextField Counter(model) push (inside JavaFX) increment update getcount settext 18 Note that this all happens on one thread!
Java Event Thread The thread that runs the event handling on the previous slide is an event thread created by Application. No other thread may make updates (like settext) on GUI elements created by the Application subclass. If that has to happen, queue up your update by calling JavaFX's runlater method: Platform.runLater( () mylabel.settext( ) ); 19
Model-View-Controller: Choices for implementation Use a classic console interface. Still the best choice for some types of work. Really. Use Swing and AWT event handling This is a legacy approach, still often used. JavaFX: several approaches Java general-utility tools java.util.observer and java.util.observable Javafx tools and approaches EventHandler and EventFilter javafx.beans properties sophisticated, but complicated to learn 20