This section documents the runtime event processing callback api and behaviour taking an imperative approach to using
Fluxtion.
Three steps to using Fluxtion
1 - Create user classes and mark event handling methods with Fluxtion annotations
2 - Build the event processor using fluxtion compiler utility
3 - Integrate the event processor in the app and feed it events
In this section we are covering the first of these Create user classes and
mark event handling methods with Fluxtion annotations using an imperative approach.
User classes bound into an EventProcessor register for event callbacks with annotations. The generated EventProcessor
implements the StaticEventProcessor, with the onEvent method acting as
a bridge between external event streams and bound processing logic. User code reads the event streams calling onEvent
with each new event received, the event processor then notifies annotated callback methods according to the dispatch rules.
Examples
The source project for the examples can be found here
To process an event stream correctly the following requirements must be met:
Call EventProcessor.init() before first use
EventProcessors are not thread safe a single event should be processed at one time.
Handle event input
Sends an incoming even to the EventProcessor to trigger a new stream calculation. Any method annotated with
@OnEvent receives the event from the event processor
Output
Handle multiple event types
An event handler class can handle multiple event types. Add as many handler methods as required and annotate each method
with an @OnEvent annotation.
Output
Filtering events
User events can implement Event, which provides an optional filtering
field. Event handlers can specify the filter value, so they only see events with matching filters
Output
Filter variables
The filter value on the event handler method can be extracted from an instance field in the class. Annotate the event
handler method with an attribute that points to the filter variable @OnEventHandler(filterVariable = "[class variable]")
Output
Handling unknown event types
An unknown event handler can be registered at runtime with the event processor, to catch any event types that are not handled
by the processor. Register the unKnownEventHandler with:
Event notification is propagated to child instances of event handlers. The notification is sent to any method that is
annotated with an @OnTrigger annotation. Trigger propagation is in topological order.
Output
Conditional triggering children
Event notification is propagated to child instances of event handlers if the event handler method returns a true value.
A false return value will cause the event processor to swallow the triggering notification.
Output
Identify triggering parent
It is possible to identify the parent that has triggered a change by adding an @OnParentUpdate annotation to a child
instance. The method must accept a single parameter of the type of the parent to observe. The OnParent callback gives
granular detail of which parent has changed, whereas OnTrigger callbacks signify that at least one parent is triggering.
The OnParent callbacks are guaranteed to be received before the OnTrigger callback.
Output
Identifying parent by name
When a child has multiple parents of the same type then name resolution can be used to identify the parent that has
triggered the update. Add the variable name to the @OnParentyUpdate annotation to enforce name and type resolution.
The OnParent callback is invoked according to the same rules as conditional triggering.
Output
After event callback
Register for a post event method callback with the @AfterEvent annotation. The callback will be executed whenever
any event is sent to the event processor. Unlike the @AfterTrigger which is only called if the containing instance has
been triggered.
Output
After trigger callback
Register for a post trigger method callback with the @AfterTrigger annotation. The callback will only be executed if
this class has been triggered on tby an incoming event. Unlike the @AfterEvent which is always called on any event.
Output
Push trigger
Invert the trigger order so the instance holding the reference receives the event notification before the reference target
and can push data into the target. Annotate the reference to be a push target with the @PushReference annotation.
The normal order is to trigger the target first, which can perform internal calculations if required. Then the instance
holding the reference is triggered so it can pull calculated data from the target reference.
Output
No propagate event handler
An event handler method can prevent its method triggering a notification by setting the propagate attribute to false
on any event handler annotation, @OnEventHandler(propagate = false)
Output
No trigger reference
A child can isolate itself from a parent’s event notification by marking the reference with a @NoTriggerReference
annotation. This will stop the onTrigger method from firing even when the parent has triggered.
Output
Override trigger reference
A child can force only a single parent to fire its trigger, all other parents will be treated as if they were annotated with
@NoTriggerReference and removed from the event notification triggers for this class.
Output
Non-dirty triggering
The condition that causes a trigger callback to fire can be inverted so that an indication of no change from the parent
will cause the trigger to fire.
Output
Collection support
Collections or arrays of references are supported, if any element in the collection fires a change notification the
trigger method will be called. The trigger method is invoked only once per event cycle whatever the number of
parent’s updating.
Parent change identity can be tracked using the @OnParentUpdate annotation.
Output
Forking concurrent trigger methods
Forking trigger methods is supported. If multiple trigger methods are fired from a single parent they can be forked to
run in parallel using the fork join pool. Only when all the forked trigger methods have completed will an event notification
be propagated to their children.
To for a trigger callback use @OnTrigger(parallelExecution = true) annotation on the callback method.
Output
Batch support
Batch callbacks are supported through the BatchHandler interface that the generated EventHandler implements. Any methods
that are annotated with, @OnBatchPause or @OnBatchEnd will receive calls from the matching BatchHandler method.