Can async / await be used for user input?

Question

I'm trying to wrap my brain around using async, await, and Tasks in C# and Unity. Here's the scenario:

1. A user clicks a button.
2. Its script (ex: MyScene.ButtonOnClick()) spawns a (custom) dialog box and enters a waiting pattern for the user's response.
3. The user then chooses from three options (ex: enum DBResponse { Yes, No, Cancel }) by clicking on one of three buttons.
4. The result is returned to the script behind the original button click.
5. The original script resumes executing code using the response.

It seems like async, await, and Task<TResult> (that is, a "Task-based Asynchronous Pattern", or TAP ) would be the modern-day answer to this problem, rather than using events and listeners or Unity's Coroutines, but the only examples I can find have to do with computationally expensive routines or for reading/writing, not for user input.

Am I trying to use the wrong tool here? If not, then what can I put in the three buttons' OnClick() methods to get the user's response back to the original script? I'm struggling with flagging an async-in-progress that there's been an update and that it has the all-clear to proceed (which sounds an awful lot like listening for an event, which is also a weak spot for me).

In earlier times, I would use a static event manager and a series of listeners and invokers as the triggers. Most recently, I used a coroutine, but because that doesn't return a value, I stashed the response as a public static value, which seems very wrong.

This seems like such a simple and fundamental problem, but I haven't been able to crack it yet. I have a feeling that if this is the right tool, there's some basic usage of Task's methods and properties that I am lacking.

Pointers to additional reading would be very helpful!

Answer 1

It seems like async, await, and Task (that is, a "Task-based Asynchronous Pattern", or TAP ) would be the modern-day answer to this problem

It's deceiving you. While it appears that would be a good use-case, it's not. The major advantage of using async/await pattern is to return threads that would normally wait for an IO result (Network, Hard Drive, etc) back to being available for other tasks. This is not that scenario.

I'd highly recommend watching Lucian Wischik take on wrapping an event to expose async/await

Lucian Wischik was/is on VB/C# language design team at Microsoft and at release one of the most knowledgeable guys at Microsoft regarding async/await.

So this is a very very rough example of how to wrap events for await consumption. After looking at it, you can decide if it's easier to read and easier to maintain instead of using events directly.

public async Task<DBResponse> ShowDialogAsync() 
{
  var tcs = new TaskCompletionSource<DBResponse>();
  EventHandler<object> lamda = (s,e) => tsc.TrySetResult(MyDialog.Result);

  try 
  {
    MyDialog.OnClose += lambda;
    MyDialog.Show();
    var result = await tcs.Task;
    return result;
  }
  finally
  {
    MyDialog.OnClose += lambda;
  }
}

So to be absolutely clear, this does not provide an alternative as you suggested in your question, because it's still using events.

It seems like async, await, and Task (that is, a "Task-based Asynchronous Pattern", or TAP ) would be the modern-day answer to this problem, rather than using events