Com.MarcusTS.ResponsiveTasks 1.0.15

There is a newer version of this package available.
See the version list below for details.
dotnet add package Com.MarcusTS.ResponsiveTasks --version 1.0.15
NuGet\Install-Package Com.MarcusTS.ResponsiveTasks -Version 1.0.15
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="Com.MarcusTS.ResponsiveTasks" Version="1.0.15" />
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add Com.MarcusTS.ResponsiveTasks --version 1.0.15
#r "nuget: Com.MarcusTS.ResponsiveTasks, 1.0.15"
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install Com.MarcusTS.ResponsiveTasks as a Cake Addin
#addin nuget:?package=Com.MarcusTS.ResponsiveTasks&version=1.0.15

// Install Com.MarcusTS.ResponsiveTasks as a Cake Tool
#tool nuget:?package=Com.MarcusTS.ResponsiveTasks&version=1.0.15

Fixing TPL Using Responsive Tasks:

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:

<pre lang='cs'> // An awaitable task public Task YouCanAwaitMe() { }

// A root where you an await a task public async Task IWillAwait() { await YouCanAwaitMe().WithoutChangingContext(); } </pre>

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:

<pre lang='cs'> public class FalselyRootedView : ContentView { protected override async void OnBindingContextChanged() { base.OnBindingContextChanged();

  // Mega hack -- called from a void method (illegal!)
  await StartUpViewModel().WithoutChangingContext();

}

public virtual Task StartUpViewModel() { return Task.CompletedTask; } }

// Derive and consume the falsely rooted view as if it were valid public class FalseConsumer : FalselyRootedView { pubic override async Task StartUpViewModel() { // Everything seems OK from this perspective, but this task can proceed at any time and // without our control; it was never properly awaited. Anything relying on it will // accelerate into a race condition; variables will not be set on time; nothing can // be relied upon in a predictable order. await SomeOtherTask().WithoutChangingContext(); } } </pre>

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 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:

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:

<pre lang='cs'> public async void IncorrectlyRaiseATaskWithABlockingCall() { await SomeTask.Wait().WithoutChangingContext(); }

</pre>

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:

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:

Part 1 of N: Pages, Views & View Models

Part 2 of N: Events & Messaging

Part 3 of N: Technical Guide

Part 4 of N: Button Pressed: Closing the Final TPL Gaps

Product Compatible and additional computed target framework versions.
.NET net5.0 was computed.  net5.0-windows was computed.  net6.0 was computed.  net6.0-android was computed.  net6.0-ios was computed.  net6.0-maccatalyst was computed.  net6.0-macos was computed.  net6.0-tvos was computed.  net6.0-windows was computed.  net7.0 was computed.  net7.0-android was computed.  net7.0-ios was computed.  net7.0-maccatalyst was computed.  net7.0-macos was computed.  net7.0-tvos was computed.  net7.0-windows was computed.  net8.0 was computed.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed. 
.NET Core netcoreapp3.0 was computed.  netcoreapp3.1 was computed. 
.NET Standard netstandard2.1 is compatible. 
MonoAndroid monoandroid was computed. 
MonoMac monomac was computed. 
MonoTouch monotouch was computed. 
Tizen tizen60 was computed. 
Xamarin.iOS xamarinios was computed. 
Xamarin.Mac xamarinmac was computed. 
Xamarin.TVOS xamarintvos was computed. 
Xamarin.WatchOS xamarinwatchos was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages (2)

Showing the top 2 NuGet packages that depend on Com.MarcusTS.ResponsiveTasks:

Package Downloads
Com.MarcusTS.PlatformIndependentShared

Platform independent utilities for C# development.

Com.MarcusTS.UI.XamForms

Xamarin.Forms abstract classes and utilities to support creating flowable animated apps.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
2.0.5 900 7/30/2022
2.0.4 387 7/29/2022
2.0.3 1,723 10/29/2021
2.0.2 340 10/29/2021
2.0.1 557 10/28/2021
1.0.22 352 10/28/2021
1.0.21 308 8/27/2021
1.0.20 308 8/24/2021
1.0.19 328 8/24/2021
1.0.18 333 8/17/2021
1.0.17 351 8/17/2021
1.0.16 446 8/15/2021
1.0.15 380 8/10/2021
1.0.14 342 8/10/2021
1.0.13 340 8/10/2021
1.0.12 372 7/6/2021
1.0.11 360 7/1/2021
1.0.10 494 6/24/2021
1.0.9 447 6/2/2021
1.0.8 381 5/18/2021
1.0.7 311 5/14/2021
1.0.6 433 5/12/2021
1.0.5 330 5/12/2021
1.0.4 352 4/9/2021
1.0.3 344 4/9/2021
1.0.2 406 4/1/2021
1.0.1 325 4/1/2021
1.0.0 350 2/3/2021