After exposing to Windows App Store development for a month, I begin to feel tha

Question

After exposing to Windows App Store development for a month, I begin to feel that async / await programming model does more harm than good. It makes simple thing complicated.

Take an example, folder creation. In Java or Desktop .NET, I can simply do

Java

public Constructor()
{
    new File("c:\folder").mkdirs();
    System.out.println("I am pretty sure c:\folder is ready now");
}
Desktop .NET

Constructor()
{
    System.IO.Directory.CreateDirectory("c:\folder");
    Console.WriteLine("I am pretty sure c:\folder is ready now");
}
But when comes to

Windows App Store .NET

Constructor()
{
    // Damm it! Another async function? I don't need aysnc!
    Windows.Storage.ApplicationData.Current.LocalFolder.CreateFolderAsync("c:\folder", CreationCollisionOption.OpenIfExists);
    // I am not sure c:\folder is ready right now!
    // OK. I know I can use ContinueWith. No no no. I don't want.
    // Why I have to use ContinueWith with such a simple operation?
}
So, my question is, do you find the newly introduced async / await programming model in Windows App Store,

Improve your productivity?
Make programming life easier?
For me, I don't! Perhaps I have been missing out certain useful techniques.

I know, Microsoft says, it helps us to write responsive UI code.

But I would say, No thanks! Hey look, my code is already in non-UI code!

Most of my current operation code is fast enough and doesn't block UI. When my operation code is not fast enough, I am pretty comfortable in making those slow operation code run in separate Thread/ Task.

Forcing me to use async / await which I do not need, only makes my code more complicated.

Message to Microsoft : May I beg to you, besides async functions, can you provide a same set of non-async functions, please? I already build up my habit of running code in non-UI thread. I promise I will continue make your Windows App perform as smooth as iOS :)

Explanation / Answer

You're probably holding it wrong (just some context for the statement).

Unfortunately I haven't had a chance to play with Win8 yet, but based on code examples I've seen, your code should look more like

Constructor()
{
// Damm it! Another async function? I don't need aysnc!
var result = await Windows.Storage.ApplicationData.Current.LocalFolder.CreateFolderAsync("c:\folder", CreationCollisionOption.OpenIfExists);
// by the time your code gets to this line, the folder will have been created
}
The other option (if you can't make your method async) is to block the thread until async opertation completes by calling GetResults. Probably something along the lines of

Constructor()
{
// Damm it! Another async function? I don't need aysnc!
var result = Windows.Storage.ApplicationData.Current.LocalFolder.CreateFolderAsync("c:\folder", CreationCollisionOption.OpenIfExists);
result.GetResults();
result.Close(); // According to documentation, you should call this when done
// Voila,
}
Though it looks like you're doing file IO inside a constructor and you probably can't have async constructors, so the first option is out. I assume this this is just some contrived example and not representative of your code, but my feeling is if you find yourself doing IO inside a constructor and you're not writing a framework class (like FileInfo), you should take a second look at your design. I generally don't expect newing up a class to start creating/locking system resources.

There are a couple of related questions on StackOverflow regarding constructors and async

Can constructors be async
start async method within object constructor - bad practice?

Related Questions

Navigate

• Browse (All)
• Browse A
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.