Chapter 10 ■ User InterfaCe DesIgn InteraCtIvIty: event hanDlIng anD ImagIng effeCts
specific features in the new embedded devices marketplace. These input event classes support advanced
touchscreen device features, such as gestures, page swiping, touchscreen input handling, and multitouch
display features, such as two-finger “pinching” or “spreading” touch input, for instance, for zooming in and
out of the content on the screen, respectively.
We will be covering the more “universal” input types in this book, which are supported across both
personal computers (desktops, laptops, notebooks, netbooks, and the newer “pro” tablets, such as the
Surface Pro 4) and embedded devices, including smartphones, tablets, e-readers, iTV sets, game consoles,
home media centers, set-top boxes (STBs), and so forth. These devices will also process these more
widespread (in their implementation) KeyEvent and MouseEvent types of input events, as mouse events
and key events will always be supported for legacy software packages. For example, mouse click events are
supported by touchscreens, but touchscreen events are not supported with positioning devices (mouse,
trackball, controller, DPAD, etc.). So if you can, use keyboard and mouse events!
It is interesting to note that a touchscreen display will “handle” mouse events as well as touch events,
which is quite convenient as far as making sure that your game works across as many different platforms
as possible. I often use this approach of using mouse event handling in my Android books so that both the
touchscreen and a DPAD center (click) button can be used by the user to generate a mouse click event,
without having to specifically use touch events. Another advantage of using mouse (click) events, when
possible, for touchscreen users is that if you use touch events, you cannot go in the other direction. That is,
your game application will only work on touchscreen devices and not on devices (such as iTV sets, laptops,
desktops, netbooks, and the like) that feature mouse hardware of some type.
This same principle applies to key events, especially the arrow keys developers use for their games, as
these keys can be found on the arrow keypad on keyboards and remote controls, on game controllers, and
on the DPAD on most smartphones. I will also show you how to include alternate key mappings so that
your player can decide which input method they prefer to use to play your pro Java 9 game. Let’s take a look
at KeyCode and KeyEvent classes next.
The KeyCode Class: Using Enum Constants to Define Keys Players Use
for Game
Since a lot of games use the arrow keypad for navigation (usually the A, S, D, and W keys) and sometimes
use alternate mappings for these to the game controller’s GAME_A, GAME_B, GAME_C, and GAME_D
buttons, let’s take a closer look at the JavaFX KeyCode class first. This class is a public Enum class, which
holds enumerated constant values for keys that are evaluated when a key is pressed or released. This class
is where the KeyEvent class goes to get the keycode constant values that it uses (processes) to determine
which key was used by the player for any particular key event invocation. The Java and JavaFX class
hierarchy for the KeyCode class will look like the following:
java.lang.Object
java.lang.Enum
javafx.scene.input.KeyCode
The constant values contained in the KeyCode class use capital letters and are named after the key that
the keycode supports. For instance, a, s, w, and d keycodes are A, S, W, and D. The arrow keypad keycodes
are UP, DOWN, LEFT, and RIGHT, and the game controller button keycodes are GAME_A, GAME_B,
GAME_C, and GAME_D.
You will be implementing KeyCode constants along with the KeyEvent object in an EventHandler object
later in this book, so I am covering these event-related packages and classes for input event handling here.
As you’ll see, this is done in much the same way that an ActionEvent is set up to be handled. Your KeyEvents
can also be coded using the Java 7 inner class approach or via Java 8 lambda expressions. Your KeyEvent
object handling should be done in a modular fashion so your KeyCode evaluation structure sets Boolean