EventThread Pattern - Revision history

Toni Kalajainen at 08:45, 14 January 2011

2011-01-14T08:45:23Z

← Older revision		Revision as of 08:45, 14 January 2011
Line 61:		Line 61:
	=====Implementation=====		=====Implementation=====

	The penalty in the example is that a new Runnable is ~~craeted~~ for every event invocation. If firing frequency is high, this can be reduced with some ugly tricks. Current thread can be detected and event ran directly, runnable can be embedded in event (like AWT), runnable recycled. Note also, foreach listeners produces unnecessary iterator object, but this is implementation details.		The penalty in the example is that a new Runnable is created for every event invocation. If firing frequency is high, this can be reduced with some ugly tricks. Current thread can be detected and event ran directly, runnable can be embedded in event (like AWT), runnable recycled. Note also, foreach listeners produces unnecessary iterator object, but this is implementation details.

	<syntaxhighlight lang="java">		<syntaxhighlight lang="java">
Line 68:		Line 68:
	CopyOnWriteArrayList<MyListenerEntry> listeners = new CopyOnWriteArrayList<MyListenerEntry>();		CopyOnWriteArrayList<MyListenerEntry> listeners = new CopyOnWriteArrayList<MyListenerEntry>();

	~~public~~ void addListener(MyListener listener, Executor executor) {		void addListener(MyListener listener, Executor executor) {
	MyListenerEntry entry = new MyListenerEntry();		MyListenerEntry entry = new MyListenerEntry();
	entry.listener = listener;		entry.listener = listener;

Toni Kalajainen at 08:43, 14 January 2011

2011-01-14T08:43:42Z

← Older revision		Revision as of 08:43, 14 January 2011
Line 60:		Line 60:

	=====Implementation=====		=====Implementation=====

			The penalty in the example is that a new Runnable is craeted for every event invocation. If firing frequency is high, this can be reduced with some ugly tricks. Current thread can be detected and event ran directly, runnable can be embedded in event (like AWT), runnable recycled. Note also, foreach listeners produces unnecessary iterator object, but this is implementation details.

	<syntaxhighlight lang="java">		<syntaxhighlight lang="java">
	public class MyObservableObject {		public class MyObservableObject {
Line 88:		Line 91:
	}		}
	</syntaxhighlight>		</syntaxhighlight>

	The penalty in the example is that a new Runnable is craeted for every event invocation. If firing frequency is high, this can be reduced with some ugly tricks. Current thread can be detected and event ran directly, runnable can be embedded in event (like AWT), runnable can be recycled. Also, foreach listeners produces unnecessary iterator object, but this is implementation details.

	====Listener Adapter====		====Listener Adapter====

Toni Kalajainen at 08:43, 14 January 2011

2011-01-14T08:43:01Z

← Older revision		Revision as of 08:43, 14 January 2011
Line 89:		Line 89:
	</syntaxhighlight>		</syntaxhighlight>

	~~For sake of simplicity,~~ the example ~~creates~~ new Runnable ~~object~~ for every event. If ~~event~~ firing is in high ~~frequency~~, this can be ~~avoided~~ with ~~various~~ tricks. Current thread can be detected and event ran directly, runnable can be embedded in event (like AWT), runnable can be recycled. Also, foreach listeners produces unnecessary iterator object, but this is implementation details.		The penalty in the example is that a new Runnable is craeted for every event invocation. If firing frequency is high, this can be reduced with some ugly tricks. Current thread can be detected and event ran directly, runnable can be embedded in event (like AWT), runnable can be recycled. Also, foreach listeners produces unnecessary iterator object, but this is implementation details.

	====Listener Adapter====		====Listener Adapter====

Toni Kalajainen at 08:41, 14 January 2011

2011-01-14T08:41:53Z

@@ Line 58: / Line 58: @@
 </syntaxhighlight>
 ====Listener Adapter====
@@ Line 79: / Line 111: @@
 	} );
 </syntaxhighlight>
 ====Utils====

Toni Kalajainen at 08:37, 14 January 2011

2011-01-14T08:37:10Z

← Older revision		Revision as of 08:37, 14 January 2011
Line 1:		Line 1:
	When desining 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 observable's executing thread or some other. ''Event Thread'' pattern addresses the second and the third question. Not only is the solution simple, but also versatile. One implementation, many models can be solved: ''Run in current thread'', ''Collects events'', ''Run in UI Thread", "Run in Worker". Here goes.		When desining 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 observable's executing thread or some other. ''Event Thread'' pattern addresses the second and the third question. Not only is the solution simple, but also versatile. One implementation, many models can be solved: ''Run in current thread'', ''Collects events'', ''Run in UI Thread'', ''Run in Worker''. Here goes.

	====Event Thread Pattern====		====Event Thread Pattern====

Toni Kalajainen at 08:36, 14 January 2011

2011-01-14T08:36:04Z

← Older revision		Revision as of 08:36, 14 January 2011
Line 128:		Line 128:

	// Sync executor blocks the call until the command is ran and finished in AWT Thread		// Sync executor blocks the call until the command is ran and finished in AWT Thread
			// for MyObservableObject, this is effectively same as CallBack - wait for all listeners
	public static Executor AWT_EDT_SYNC = new AWTExecutorSync();		public static Executor AWT_EDT_SYNC = new AWTExecutorSync();

Toni Kalajainen at 08:35, 14 January 2011

2011-01-14T08:35:13Z

← Older revision		Revision as of 08:35, 14 January 2011
Line 1:		Line 1:
	When desining 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 observable's executing thread or some other. ''~~EventThread~~'' ~~coding~~ pattern addresses the second and the third question. Not only is the solution simple, but also versatile. One implementation, ~~three~~ models solved: ''Run ~~runnent~~ thread'', ''Collects events'', ''Run in UI Thread ~~/ worker''~~. Here goes.		When desining 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 observable's executing thread or some other. ''Event Thread'' pattern addresses the second and the third question. Not only is the solution simple, but also versatile. One implementation, many models can be solved: ''Run in current thread'', ''Collects events'', ''Run in UI Thread", "Run in Worker". Here goes.

	====Event Thread Pattern====		====Event Thread Pattern====
Line 80:		Line 80:
	</syntaxhighlight>		</syntaxhighlight>

	====Implementation ~~Example~~====		====Implementation====
	Example for the [[#Variation]].		Example for the [[#Variation]].

Line 111:		Line 111:
	}		}
	</syntaxhighlight>		</syntaxhighlight>

			For sake of simplicity, the example creates new Runnable object for every event. If event firing is in high frequency, this can be avoided with various tricks. Current thread can be detected and event ran directly, runnable can be embedded in event (like AWT), runnable can be recycled. Also, foreach listeners produces unnecessary iterator object, but this is implementation details.

	====Utils====		====Utils====

Toni Kalajainen at 08:29, 14 January 2011

2011-01-14T08:29:10Z

← Older revision		Revision as of 08:29, 14 January 2011
Line 112:		Line 112:
	</syntaxhighlight>		</syntaxhighlight>

	====~~Executor Implementations~~====		====Utils====
	First, use [http://download.oracle.com/javase/6/docs/api/java/util/concurrent/Executors.html Executors] if possible. If you need to run in UI thread or current thread use the following util.		First, use [http://download.oracle.com/javase/6/docs/api/java/util/concurrent/Executors.html Executors] if possible. If you need to run in UI thread or current thread use the following util.

Toni Kalajainen at 08:28, 14 January 2011

2011-01-14T08:28:53Z

@@ Line 7: / Line 7: @@
 	public class MyObservableObject {
 		...
-		void addListener(MyListener listener);
+		void addListener(MyListener listener) { ... }
+	}
 	public interface MyListener {
@@ Line 44: / Line 44: @@
 	public class MyObservableObject {
 		...
-		void addListener(MyListener listener, Executor executor);
+		void addListener(MyListener listener, Executor executor) { ... }
+	}
 	public interface MyListener {
@@ Line 81: / Line 81: @@
 ====Implementation Example====
-Example implementation
+Example for the [[#Variation]].
 <syntaxhighlight lang="java">
 </syntaxhighlight>
 ====Executor Implementations====

Toni Kalajainen at 08:22, 14 January 2011

2011-01-14T08:22:42Z

← Older revision		Revision as of 08:22, 14 January 2011
Line 1:		Line 1:
	~~__NOTOC__~~		When desining 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 observable's executing thread or some other. ''EventThread'' coding pattern addresses the second and the third question. Not only is the solution simple, but also versatile. One implementation, three models solved: ''Run runnent thread'', ''Collects events'', ''Run in UI Thread / worker''. 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 observable's executing thread or some other. ''EventThread'' coding pattern addresses the second and the third question. Not only ~~are both cases solved with~~ the ~~same~~ simple ~~solution~~, but also ~~- instead of~~ implementation, ~~the~~ ''~~caller~~'' ~~of the object can decide which model to use~~. Here goes.

	====Event Thread Pattern====		====Event Thread Pattern====
Line 60:		Line 59:


	====Adapter====		====Listener Adapter====
	Some listeners have default implementation called ''adapter'' (For example AWT Listeners & Adapters). With this pattern it is a good idea to have a default executor in the adapter.		Some listeners have default implementation called ''adapter'' (For example AWT Listeners & Adapters). With this pattern it is a good idea to have a default executor in the adapter.

Line 80:		Line 79:
	} );		} );
	</syntaxhighlight>		</syntaxhighlight>

			====Implementation Example====
			Example implementation
			<syntaxhighlight lang="java">
			</syntaxhighlight>

			Example implementation for the [[#Variation]]


	====~~Event Dispatch Threads~~====		====Executor Implementations====
	~~There are many thread worlder implementations supported in the~~ [http://download.oracle.com/javase/6/docs/api/java/util/concurrent/Executors.html Executors]~~, on top of that here are few more, one for current thread and few for support GUI Framework~~ to run ~~listeners~~ in ~~EDTs~~.		First, use [http://download.oracle.com/javase/6/docs/api/java/util/concurrent/Executors.html Executors] if possible. If you need to run in UI thread or current thread use the following util.

	<syntaxhighlight lang="java">		<syntaxhighlight lang="java">