Difference between revisions of "EventThread Pattern"

From Developer Documents
Jump to navigation Jump to search
m (Created page with "__NOTOC__ When designing an event-listener model, the developer has to make three decisions. First, should notifations use listeners or events. Second, should notifications be pr...")
 
m
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
When designing an event-listener model, the developer has to make three decisions. First, should notifations use listeners or events. Second, should notifications be processed immediately or queued for later handling. Third, should notifications be handled in the very current thread or some other. ''EventThread'' coding pattern addresses the second and the third question. Not only are both cases solved with a simple implementation, but also - the caller of the function can decide which model to use. Here goes.
+
When designing an event-listener model, the developer has to make three decisions. First, should notifications use listeners or events. Second, should notifications be processed immediately or queued for later handling. Third, should notifications be handled in the very current thread or some other. ''EventThread'' coding pattern addresses the second and the third question. Not only are both cases solved with a simple implementation, but also - the caller of the function can decide which model to use. Here goes.
  
 
====Event Thread====
 
====Event Thread====

Revision as of 11:30, 7 January 2011

When designing an event-listener model, the developer has to make three decisions. First, should notifications use listeners or events. Second, should notifications be processed immediately or queued for later handling. Third, should notifications be handled in the very current thread or some other. EventThread coding pattern addresses the second and the third question. Not only are both cases solved with a simple implementation, but also - the caller of the function can decide which model to use. Here goes.

Event Thread

In EventThread pattern, the Listener/Observer interface has a function that allows the implementation decide executing environment of the event. Java Executor implementation

<syntaxhighlight lang="java"> public interface MyListener {

void onEvent(Object sender, Object event);

/** * Get the executor environment where the event will be handled. * * @return executor */ Executor getExecutor();

} </syntaxhighlight>

Null is default

For syncronous object, you can also design your interface so that null value denotes current thread. It is more convenient to use and you can optimize the implementation by one Runnable object.

<syntaxhighlight lang="java"> public interface MyListener {


void onEvent(Object sender, Object event);

/** * Get the executor environment where the event will be handled. * null value denotes that the events is handled immediately * and in the caller's thread. * * @return executor or null */ Executor getExecutor();

} </syntaxhighlight>



CURRENT_THREAD

Create a static field CURRENT_THREAD that the implementations can use when they want to have the event handled immediately and in current thread. This is the most typical case

<syntaxhighlight lang="java"> public static Executor CURRENT_THREAD = new Executor() { public void execute(Runnable command) { command.run(); } };

{ obj.addListener( myListener, CURRENT_THREAD ); } </syntaxhighlight>


Adapter

Some listeners have default implementation called adapter. With this pattern it is a good idea to add implementation that provides current thread as default executor.

<syntaxhighlight lang="java"> public abstract class MyAdapter implements MyListener {

public Executor getExecutor() { return CURRENT_THREAD; } }


{ MyObservable o = ... ; o.addListener( new MyAdapter() { @Override public void onEvent(Object sender, Object event) { ... } } ); }

</syntaxhighlight>


--

Toni Kalajainen