C＃将通用Windows应用程序转换为异步

Question

I am new to windows and I am making a hobby project using universal app. A few days down the road I found that the only way to hook up a serial port it to use async methods from and related to SerialDevice class.

I liked generic advise on the topic: once you got to use one serial api it will be much easier to covert whole app to async starting right from 'Main' ( http://blog.stephencleary.com/2012/02/async-and-await.html ) than deal with issues related to sync calls to async methods.

However, universal application created by VS2015 contains ton of generated non-async code that is not intended to be comprehensible. I suppose there is a general pattern somewhere do deal with this issue but I could not find any trace of it. So what should I do?

Answer 1

I suppose there is a general pattern somewhere do deal with this issue but I could not find any trace of it. So what should I do?

My recommendation always goes like this:

1. Start with the "leaves" and identify naturally-asynchronous operations. In your case, this is easy, because in the Windows Universal platform, naturally-asynchronous operations only have asynchronous APIs.
2. Call the asynchronous APIs with await .
3. The presence of await will require the calling method to be async (and you should change its return type from void to Task or from T to Task<T> ).
4. This transformation makes the calling method asynchronous, so go back to step (2) for it's callers.
5. Repeat until you reach a "root" method - in a Windows Universal app, this is often an event handler, which must be async void (they're not allowed to be async Task ).

You may run into various problems as the async "grows" through your code base - eg, you can't use await in property getters or constructors. I have a series of posts on my blog describing techniques to work around these problems .

Answer 2

Universal apps aren't separated by " this app is asynchronous ", and " this app isn't asynchronous ", creating async methods does not mean you have to change absolutely everything in order to use them.

One of the benefits of async and await allows you to execute long running operations without the freezing the UI.

Stephen Cleary's pattern of " async all of the things " is totally unnecessary, and it is abusing the purpose of asynchronous methods.

Most code does not need to be wrapped in asynchronous methods, synchronous methods will handle almost all things just fine. However for long-running processes , like requesting data from a web service for example, would be best suited to an asynchronous method simply because it takes a long time.

It's important that you don't get consumed in the unusual pattern of creating millions of async methods, figure out what needs to be asynchronous and implement this functionality accordingly.

The reason why some of the UWP API is async is because some processes are not instantaneous, you have to remember that when calling an async API method, you are asking the operating system to perform actions on your behalf. The truth is, the operating system might not be ready , or may be overloaded and may not be able to serve your request instantaneously, therefore these methods are asynchronous, which ensures that your application does not hang on a request.

I would recommend reading up on this here .

Answer 3

This was a result of confusion by novice.

A. Term 'async function' has three meanings:

A.1. Function that has 'async' term in the signature. The only significance of this term is that compiler would NOT treat 'await' in the function body as a variable, but it will treat it as await statement. It does not change signature in any other way and it is here strictly for backward compatibility.

A.2. Function of type Task that could be awaited.

A.3. Function of type Task that also have await statement in the body.

B. UI processing is not blocked by await statement: if one callback from UI infrastructure is waiting on await statement, UI message processing is still performed.

So in order to call async function(A.2) from UI method:

(a) Add 'async' term to UI function signature (A.1).

(b) Use await statement inside this function to call asynchronous library functions (A.2)

(c) Handle result of asynchronous execution one way or another.

Answer 4

The biggest confusion that arises from the async-await pattern is that the pattern does nothing more than wrap a function in a Task, run it and return the running Task (this is really important to understand, because you don't always want your Task to be started automatically ... ).

Once you do realise this, it should also be less of a stretch to understand that any async call can easily be wrapped by a Task like this.

    public void PersistChanges()
    {
        var saveTask = new Task(() => PersistChangesAsync());
        saveTask.Start();
    }

Of course, as was mentioned elsewhere, you will want to make sure that you run async calls as much async as possible, so that for instance if you were to have a Save button in your application, you'd have that event picked up asynchronously and then call the asynchronous PersistChangesAsync.

But at the startup of my application, I may not want to have anything happen before the basic settings have been loaded, user has been validated or whatever, and then you could even use saveTask.RunSynchronously() (though obviously you can still run several subtasks asynchronously and then await the results (if any, or define a continuation task when everything is complete)