Chapter 7 ■ IntroduCtIon to JavaFX 9: overvIew oF the JavaFX new MedIa engIne
JavaFX Input Control for Games: Using the javafx.event Classes
Since games are interactive by their very nature, let’s take a look at the javafx.event package next, since it
provides us with the Event superclass and its ActionEvent subclass for handling ACTION events like UI
elements use or animation KeyFrame processing events use, for instance. Since you are going to be using
ActionEvent in pro Java 9 games (or IoT applications), I am going to look at its cross-package (Java to JavaFX)
class inheritance hierachy here, as that will also show you the origin of the JavaFX Event class. This is
possible because JavaFX API is part of (underneath) the Java API.
Java.lang.Object
java.util.EventObject
javafx.event.Event
javafx.event.ActionEvent
The JavaFXGame application is already using this ActionEvent class (object) with the EventHandler
interface and its .handle() method, which you’ll implement in order to tell the Java application what to do
to handle that Event, which is an ActionEvent once it has occurred (the programming term is fired). This
.handle() method then “catches” the fired event and processes it, according to the Java 9 programming logic
inside of the “body” of this .handle() method.
As you know from Chapter 5 , a Java interface is a type that provides empty methods that are declared
for use but do not yet contain any Java constructs. The unimplemented methods will, at the time of their
use, need to be implemented by you, the Java programmer. This Java interface defines only which methods
need to be implemented; in this case, it’s a single method that will “handle” the ActionEvent so that this
event gets processed in some fashion.
It is important to note that the Java interface defines a method that needs to be coded but does not
write the method code for you, so it is a “road map” of what you must do to complete, or interface with,
the programming structure that is in place. In this case, this is a Java programming structure for handling
ActionEvent objects, or, more accurately, a programming structure for handling ActionEvents once they have
been fired.
As with everything else covered in this JavaFX new media engine overview chapter, you will soon be
getting deeper into the details of how to use these packages, classes, nested classes, interfaces, methods,
constants, and data fields (variables) during the course of this pro Java 9 games and IoT applications
development book as you apply these JavaFX 9 programming structures, JavaFX scene graph construction,
and new media asset design concepts.
JavaFX UI Elements: Using the javafx.scene.control Classes
The javafx.scene.control package, along with the javafx.scene.chart package, which we will cover next, is in
the javafx.controls module. This package contains all the user interface control (they are called “widgets”
in Android, and I like to call them UI “elements”) classes, like Alert, Button, Cell, CheckBox, ChoiceDialog,
ContextMenu, Control, DatePicker, ColorPicker, Label, ProgressBar, Slider, Label, RadioButton, ScrollBar,
and TextField. Since there are more than 100 classes in javafx.scene.control, I am not even going to attempt
to cover them all here, as an entire book could be written about this one Java 9 module. If you wanted to
review these classes, simply reference javafx.control module using Google, or on the Oracle Java web site,
and you can peruse what these classes can do for days on end. For this module, “reference” is the key word,
as you will want to reference this package, and its classes, individually, at the time you need to implement
a given UI element. I will be attempting to create the i3D game in this book (eventually) using my own 3D
UI elements and code so that I do not have to include this javafx.controls module in the distribution, saving
the overhead of having to include more than 100 control classes (not to mention well over a dozen charting
classes) in the distribution that are not even utilized.