Consuming Events
To consume an event in an application, you must provide an event handler (an event-handling method) that executes program logic in response to the event and register the event handler with the event source. This process is referred to as event wiring.
This topic describes the general pattern of handling events.
The Event Pattern
A class that owns an event named
EventNamehas the following member:public final Event<EventNameEventArgs> eventName = new Event<>(EventNameEventArgs.class);The event listener for the
EventNameevent is constructed as follows:Event.Listener<EventNameEventArgs> onEventName = new Event.Listener<EventNameEventArgs>() { @Override public void onTrigger(Object sender, EventNameEventArgs args) { ... } };
When an event does not have any associated data, it uses EventArgs for the event data. Events that have associated data use classes that derive from EventArgs for the event data type. For example, if you want to handle a TouchUp event, the event data class is TouchEventArgs. Note that several touch events use a common class for event data, so the naming scheme does not exactly match the convention described above. For the touch events, your subclass must override following methods:
protected void onTouchDown(Object sender, TouchEventArgs e) {}
protected void onTouchMove(Object sender, TouchEventArgs e) {}
protected void onTouchUp(Object sender, TouchEventArgs e) {}
The sender and event argument parameters supply additional details about the touch event to the event handler. The sender object indicates what raised the event. The TouchEventArgs parameter provides details on the touch movement that raised the event. Many event sources provide additional data for the event, and many event handlers use the event-specific data in processing the event.
Note: Events also arise outside the context of user interfaces (UIs), and, in fact, the InAiR Framework includes many non-UI classes that raise events. However, all events follow the pattern described here.