Asynchronous Metro style app-simple but not simple asynchronous

Metro style appAsynchronous-simple but not simple asynchronous

 

Simple asynchronous

In Win8, Asynchronization is greatly enhanced and accounts for a considerable proportion of code. We recommend that you use Asynchronization for any operation that takes more than seconds. Fortunately. net 4.5 asynchronous development is quite simple

 

(Bright class libraries all indicate asynchronous operations. How important is this)

 

 

View code

1      private bool test()
2 
3         {          
4 
5            Method()
6 
7             return true;
8 
9         }

 

This is the most primitive method. When method () is executed for a long time, it will block the UI thread. We may have a variety of methods to solve this problem before, but in. net 4.5, which is greatly simplified.

You only need to add the async and await keywords where you need them. async must be before the method name and return type.

Await is required for async, And the return type of asynchronous methods must be task <t>. That is, to return a bool type, the method declaration is required.

    private async Task<bool> test()

        {          

            await Method()

return true;

        }

Copy code

 

Note that the method returns true only after the method is executed, but the difference is that the UI thread can control the UI element in the test () method, and the UI will not be suspended. You need to note that this is not a magic syntax, but it is just a bit of syntactic sugar and a sharp compiler.

 

Note that async cannot be used for attributes, constructor,

 

Asynchronous quagmire

For Asynchronous in Win8, I like to use the word quagmire in the beginner stage, you may fall into some strange asynchronous problems, because in some cases it is not always run in the way you think, there may be deadlocks, and there may be a lot more to execute without waiting for the method to complete ...... Here are some personal suggestions

1. If there is a void method that requires asynchronous execution, change void to task.

View code

 1     public async void btnWrite_Click(object sender, Windows.UI.Xaml.RoutedEventArgs e)
 2 
 3         {
 4 
 5             WriteData ();
 6 
 7             savedate();
 8 
 9         }
10 
11  
12 
13             private async void WriteData()
14 
15         {          
16 
17              await Method()        
18 
19         }

 

When we execute this btnwrite_click Asynchronous Method, it will first enter writedata (). As mentioned above, we should wait until the writedata execution is complete before executing the savedate method, but unfortunately, it will not wait until the writedata execution is complete and then execute savedate. This is because although writedata is an asynchronous method, this Asynchronous Method is for method (), writedata is essentially an asynchronous method but does not need to wait, but we need a waiting asynchronous...

View code

        public async void btnWrite_Click(object sender, Windows.UI.Xaml.RoutedEventArgs e)

        {

           await WriteData ();

            savedate();

        }



private async Task WriteData()

        {          

            await Method()        

        }

 

When void is changed to task, the writedata is clearly defined as an Asynchronous Method that needs to be waited. In this way, btnwrite_click will wait until the writedata execution is complete as we imagined before savedate is executed.

 

1. Use configureawait (false) to avoid deadlock

Let's improve the reading and writing of our files. When the writing fails, we may need to log in

public async void btnWrite_Click(object sender, Windows.UI.Xaml.RoutedEventArgs e)

        {

try

            {

                await WriteData();

                btnWrite.Content = "ok";

            }

catch (Exception)

            {

                  WriteLog();      

            }

        }

private async Task WriteData()

        {          

           await Method()        

        }

private async Task WriteLog ()

        {          

               await Method2()        

        }

Copy code

Unfortunately, we cannot use the await keyword in catch. Since await cannot be used, we can call writelog () for asynchronous methods (). start (), but we cannot ensure when the writelog () is executed. Maybe the program is closed and the log is still being written. this is clearly not what we expected, or we can try writelog (). getawaiter (); this is a good idea, but when we are running, we will find the program deadlocked. It should be in writelog (). getawaiter ();

The UI thread will be blocked and wait until the writelog method is executed and return control. Within writelog, the control will be returned after method2 () is executed. the idea is that method2 is executed in other threads (from the thread pool), but writelog is executed in the UI thread... The UI thread has been blocked and the deadlock occurs after method2 is executed. Fortunately, we still have a solution.

We can explain the following in writelog (). configureawait (false) msdn:

 

• Task. configureawait (bool continueoncapturedcontext)
  • True(Default)
    • Post continuation back to the current context/Scheduler
    • False
      • If possible, continue executing where awaited task completes

I personally think it is similar to task. Yield (); but task. Yield (); there is uncertainty and await support is required.

Source Address