The IAsyncSupportService is a service that coordinates two threads for one ecospace.
The desired effect is to get loading, saving and any other potentially time-consuming logic to run in the non-UI-thread, also called the AsyncThread, and to keep the UI-thread free from EVERYTHING except responding to UI events – like user input or view redraw refresh.
The goal of this separation is to get an application as responsive as possible for the user.
There are other scenarios when you want to use multiple threads with ECO. The scenario that the IAsyncSupportService solves is the one of “creating responsive applications”.
WECPOF uses IAsyncSupportService internally. When using WECPOF, you need not think a lot about the workings of the IAsyncSupportService.
When you do not use WECPOF, you should follow these rules:
- Do all your business logic in the Async thread (all persistence server communication will be in this thread).
- If you address UI components directly, like bringing up windows, change the value of a textbox by addressing the textbox directly rather than by databind, compiling reports, etc. When you do these kinds of things, always use the UI-thread.
So – simple enough rules – but how do you follow them?
This is one way to make logic execute in the Async thread:
IAsyncSupportService asyn=_RootHandle.EcoSpace.GetEcoService<IAsyncSupportService>();
asyn.PerformTaskNowIfInAsyncThread(() =>
{
// Things here will always be done in the async thread
}
But it is not uncommon that you want to do business logic - then update the textbox or what have you:
IAsyncSupportService asyn=_RootHandle.EcoSpace.GetEcoService<IAsyncSupportService>();
asyn.PerformTaskAsync(() =>
{
// Things here will always be done in the async thread
asyn.DispatchTaskToMainThread(() =>
{ // Things here will always be done in the UI/Main thread
});
}
If you code like this whenever you invoke business logic from the UI-thread (like when you click a button or menu), then your app will be responsive and never lock up – even if there is a network delay from loading a lot of data.
If you turn the IAsyncSupportService off – then the PerformTaskAsync and the DispatchTaskToMainThread will fall through directly and execute directly – so code written like this will work either way – IAsyncSupportService on or off.
Turning it on or off:
public interface IAsyncSupportService {
/// <summary>
/// For Silverlight with Persistence AsyncService MUST BE ON
/// We recommend leaving it on for other NEW WPF and WinForms applications - and executing business logic in AsyncTasks.
/// For ASP.NET the AsyncHandling should be turned off (default off).
/// </summary>
void TurnOnAsyncHandling();
/// <summary>
/// We recommend leaving it on for other NEW WPF and WinForms applications - and executing business logic in AsyncTasks.
/// For ASP.NET the AsyncHandling should be turned off.
/// </summary>
void TurnOffAsyncHandling();
…
Staying Informed
When you have an application that does a lot of stuff in the Async thread, it is a nice and good style to indicate that work is going on to the user because even if the app never locks up, the UI might still be needing more data – data that will show up once all the work is done if the user can patiently wait for it.
The IAsyncServiceHelper exposes some events for this purpose. Use these to show an animation or what you need. WECPOF uses these to light up a “loading” animation and an “Error” icon when appropriate.
/// <summary> /// Implement this event to inform yourself about exceptions in the AsyncThread /// </summary> event EventHandler AsyncExceptionsEvent; /// <summary> /// Implement this event to Start a busy animation /// </summary> event EventHandler AsyncQueueHasFormedEvent; /// <summary> /// Implement this event to Stop a busy animation /// </summary> event EventHandler AsyncQueueDissolvedEvent; /// <summary> /// Implement this event to tick a progress indicator /// </summary> event EventHandler AsyncQueueTickEvent;