OpenTok.DirectDispatcher Class Reference

Implementation of IDispatcher that doesn't schedule events at all. It uses the same thread used by the lower layer to deliver events. Available for all presentation frameworks (WinForms, WPF, etc.). Delivery order is guaranteed. Since this is a No-Op IDispatcher, it doesn't matter whether the same DirectDispatcher is always used or a new one is created every time. CPU-intensive or long-running tasks should not be executed in the event handlers, as they would block the native API main thread and affect performance or responsiveness. Also, calling the otkit API functions directly from the event handlers can result in interlocking, so if that's required, first re-scheduled the execution to a different thread. UI can't be manipulated directly in the event handlers. If this is required, events must be scheduled first to the UI thread. IMPORTANT: This type of IDispatcher leaves a lot of responsibility to the application which must not block the calling thread and cannot make any calls to the API directly, requiring a re-scheduling first. At the same time, it provides much more control on how the application handles the callbacks, avoiding re-scheduling where not needed or managing priorities for different types of events. This can result in better performance for the application. More...

Inherits OpenTok.IDispatcher.

Public Member Functions
void	DispatchEvent (object sender, EventHandler handler)
	Schedules a parameterless event. More...
void	DispatchEvent< T > (object sender, EventHandler< T > handler, T args)
	Schedules a typed parameter event. More...
void	DispatchEvent (object sender, EventHandler handler)
	Schedules a parameterless event. More...
void	DispatchEvent< T > (object sender, EventHandler< T > handler, T args)
	Schedules a typed parameter event. More...

Detailed Description

Implementation of IDispatcher that doesn't schedule events at all. It uses the same thread used by the lower layer to deliver events. Available for all presentation frameworks (WinForms, WPF, etc.). Delivery order is guaranteed. Since this is a No-Op IDispatcher, it doesn't matter whether the same DirectDispatcher is always used or a new one is created every time. CPU-intensive or long-running tasks should not be executed in the event handlers, as they would block the native API main thread and affect performance or responsiveness. Also, calling the otkit API functions directly from the event handlers can result in interlocking, so if that's required, first re-scheduled the execution to a different thread. UI can't be manipulated directly in the event handlers. If this is required, events must be scheduled first to the UI thread. IMPORTANT: This type of IDispatcher leaves a lot of responsibility to the application which must not block the calling thread and cannot make any calls to the API directly, requiring a re-scheduling first. At the same time, it provides much more control on how the application handles the callbacks, avoiding re-scheduling where not needed or managing priorities for different types of events. This can result in better performance for the application.

Member Function Documentation

DispatchEvent()

void OpenTok.DirectDispatcher.DispatchEvent	(	object	sender,
		EventHandler	handler
	)

Schedules a parameterless event.

Parameters

sender	Originator of the event.
handler	Method to call after scheduling to the new thread.

Implements OpenTok.IDispatcher.

DispatchEvent< T >()

void OpenTok.DirectDispatcher.DispatchEvent< T >	(	object	sender,
		EventHandler< T >	handler,
		T	args
	)

Schedules a typed parameter event.

Template Parameters

T	The type of the parameter

Parameters

sender	Originator of the event.
handler	Method to call after scheduling to the new thread.
args	Parameter to pass to the handler.

Implements OpenTok.IDispatcher.

Type Constraints

T

:

EventArgs

---