ResponsiveTasks_5.md

August 17, 2021 · View on GitHub

The Proof is in the Output

This is a digested Debug output from the demo 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:

LocationTask TypeFirst/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 demo. Everything is orderly now. Every process is stateful and predictable:

LocationTask TypeFirst/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  
------------------------------------  ------------------------------  -------