Here we look at: what's wrong with Task Parallel Library, and then do a brief overview of my code, including a digested Debug output from the ResponsiveAppDemo, and discussing how the Responsive Tasks library handles a variety of issues using a thread-safe wait strategy.
IMPORTANT
TPL: The Promise
When Microsoft announced the Task Parallel Library, C# programmers everywhere rejoiced. Simplified threads? Error handling within the library itself? What could possibly go wrong?
Just about everything, as it turns out.
A task requires a root
in order to be properly awaited. For instance:
public Task YouCanAwaitMe() { }
public async Task IWillAwait()
{
await YouCanAwaitMe().WithoutChangingContext();
}
TPL: The Reality
Unfortunately, a Xamarin app doesn't have any valid roots. For instance, not at:
- Constructors
- Content changed
- Binding context changed
- Event handlers
- Global messages
- Overrides
- Property Setters
Any location that fails to provide a Task signature is a false root
. This causes unsafe results:
public class FalselyRootedView : ContentView
{
protected override async void OnBindingContextChanged()
{
base.OnBindingContextChanged();
await StartUpViewModel().WithoutChangingContext();
}
public virtual Task StartUpViewModel()
{
return Task.CompletedTask;
}
}
public class FalseConsumer : FalselyRootedView
{
pubic override async Task StartUpViewModel()
{
await SomeOtherTask().WithoutChangingContext();
}
}
Until Microsoft converts all current code signatures to Tasks, programmers are stuck using these sorts of risky mechanisms.
The Proof is in the Output
This is a digested Debug output from the ResponsiveAppDemo
when I originally created it. The demo called Tasks from all of the forbidden areas, including constructors. It was otherwise well-behaved -- at least according to Microsoft's guidance. So it resembles code that anyone would produce who has done the reading:
Location | Task Type | First/Last |
Views.Subviews.DashboardView | RunPostConstructionTasks | FIRST |
ViewModels.DashboardViewModel | RunPostConstructionTasks | FIRST |
ViewModels.DashboardViewModel | RunPostBindingTasks | FIRST |
Views.Subviews.DashboardView | RunPostBindingTasks | FIRST |
------------------------------- | -------------------------- | ------------ |
Views.Subviews.DashboardView | RunPostConstructionTasks | LAST |
ViewModels.DashboardViewModel | RunPostConstructionTasks | LAST |
ViewModels.DashboardViewModel | RunPostBindingTasks | LAST |
Views.Subviews.DashboardView | RunPostBindingTasks | LAST |
Everything runs immediately and on top of each other. Nothing ever forms properly before something else piles on top and tries to rely on some imagined statefulness. This is what causes programs to hang and to crash.
The Most Obvious Solution is Also the Worst
So how do we achieve atomic completeness for each Task with no overlaps? How about this:
public async void IncorrectlyRaiseATaskWithABlockingCall()
{
await SomeTask.Wait().WithoutChangingContext();
}
Ironically, this solves concurrency issues because it only proceeds after completing a task. But that comes at an enormous cost: 100% of the UI thread. The user immediately senses their keyboard has died. Wait
is a rusty razor blade in the bottom of your tool-belt.
The Right Solution: Responsive Tasks
The Responsive Tasks library handles all of the dilemmas mentioned here using a thread-safe "wait" strategy, plus base classes that support Tasks everywhere. You can easily copy the code samples into your own base views or view models, so this approach is not dogmatic.
Here is the output in the final ResponsiveTasksDemo
. Everything is orderly now. Every process is stateful and predictable:
Location | Task Type | First/Last |
Views.Subviews.DashboardView | RunPostConstructionTasks | FIRST |
Views.Subviews.DashboardView | RunPostConstructionTasks | LAST |
------------------------------- | -------------------------- | ------------ |
ViewModels.DashboardViewModel | RunPostConstructionTasks | FIRST |
ViewModels.DashboardViewModel | RunPostConstructionTasks | LAST |
------------------------------- | -------------------------- | ------------ |
ViewModels.DashboardViewModel | RunPostBindingTasks | FIRST |
ViewModels.DashboardViewModel | RunPostBindingTasks | LAST |
------------------------------- | -------------------------- | ------------ |
Views.Subviews.DashboardView | RunPostBindingTasks | FIRST |
Views.Subviews.DashboardView | RunPostBindingTasks | LAST |
Index
Each page describes a problem and its Responsive solution: