Recently I encountered strange and inconsistent behavior in exceptions being thrown by different file operations in WinRT. Let’s start with a snippet:

Although there is a file named Text.txt in Assets folder of the application package, the above code throws an exception. If you were paying close attention while reading the code you might have even noticed the problem. There’s no exception thrown in the first line, though. Instead the second line throws an ArgumentException: Value does not fall within the expected range. Strange, isn’t it?

Let’s take a closer look by putting a breakpoint on the second line. The problem lies in the value of file.Path property: C:\Users\Username\Documents\Visual Studio 2012\Projects\SlnName\ProjName\bin\Debug\AppX\\Assets\Text.txt. Did you notice the two backslashes before the Assets folder? They’re causing the problem. CopyAsync method can’t find the file because of it and throws the non-descriptive exception which doesn’t really help pinpointing its cause. Calling ReadTextAsync on the file instead would’ve make it much easier:

In this case the second line throws FileNotFoundException: The filename, directory name, or volume label syntax is incorrect. Definitely much clearer. Too bad, CopyAsync doesn’t throw the same exception. It would have made troubleshooting the original issue much easier.

That’s not all, though. I still think the exception should already be thrown in the first line. If we replace the filename with a non-existent one (e.g. Text1.txt), it does throw FileNotFoundException as expected: The system cannot find the file specified. It seems that for some reason GetFileAsync can handle paths with double backslashes. It even sets file.DateCreated correctly, so there can be no doubt about that. The other methods don’t seem to support this same syntax. That’s not a problem per se, but in my opinion all methods should behave the same to avoid confusion: either support the syntax or not. Until that happens, I’ll keep in mind the described anomaly, just in case I stumble upon it again.

Task-based asynchronous pattern has many advantages over other asynchronous patterns introduced in the past, most of them boiling down to the fact that it’s really easy to get into and start using it. Like any other technology, it does have its pitfalls and there are many details to know about once you get into more advanced scenarios.

One of the first issues you’ll very probably stumble upon, is the viral nature of asynchronous methods, meaning that as soon as a method calls one asynchronous method, it becomes asynchronous as well. In most cases that’s not really a problem: you just change method signatures by adding the async keyword and changing the return value (T to Task<T> and void to Task) up the call stack until you reach the originating call, usually an event handler. You just make it async void and you’re done.

The problem arises when you’re trying to call such an asynchronous method from a class constructor: you can’t use the await keyword inside the constructor. As long as you’re only using methods which don’t return a value, you can get away with it by just calling them without await, but that’s not the right way to do it. That’s why the compiler issues a warning in this case: Because this call is not awaited, execution of the current method continues before the call is completed. Consider applying the 'await' operator to the result of the call.

Of course, there are ways to properly get around this limitation. Most of the time you don’t care when the asynchronous part of the constructor is going to be completed. This happens in view models, for example. You start loading data in the constructor and when its loaded, the values get assigned to public properties implementing INotifyPropertyChanged interface and in turn cause the UI to refresh. In this case all asynchronous calls can be grouped in a single async void asynchronous method which can be called from the constructor:

You can expand on that same idea by adding a bool Initialized property to your view model. By setting it to true at the end of Init(), you can use it to display a different view (e.g. an indeterminate progress indicator) until the initialization is complete (I added a short delay to make the effect easier to notice):

The next improvement on the idea would be providing progress report during initial loading. Since everything is being processed inside the same view model class, this could be achieved in many ways, but lets take the IProgress<T> approach as defined by the task-based asynchronous pattern (again I’m using delays to simulate loading times):

If you don’t want a loading view but need to check whether initialization is complete at a later time you can change Init() to return a task and store a reference to it:

Using one of the techniques above you should be able to call any asynchronous method in a class constructor and handle it appropriately. As always modify the implementation details to your actual needs.

On the final day of NT Conference 2013 I had my last session. This time I was speaking about my experiences with building LOB (line of business) applications for Windows Store. As always, slides and samples are available here and from the conference web site.

At NT conference 2013 I opened the Windows 8 and Windows Phone 8 Developer Tales from the Tranches PreCon track with a session on Building Connected Apps. I addressed all aspects of network communications, focusing on available APIs but also spending some time on the expectations for mobile applications in respect to network usage.

Although the session materials are already on the conference web site, I’m also publishing them here to keep them available after the conference site is closed down: both slides and samples.

Today our local Microsoft DPE team organized ReBuild, a one day recap of the recent Build conference which was taking place in Redmond a little over a month ago. I had the last session of the day and focused on Windows Store apps: what they were and how to develop them.

As always I’m publically sharing the resources from the session: slide deck and sample source code.

This weekend a worldwide hackathon for Windows is taking place in over 100 locations. Among them is Ljubljana where the event started with my 3 hour Windows Store app development workshop. I split it in two parts:

• In the first half I focused on the basics of Windows Store apps, their features, development tools and the APIs available.
• In the second half I live coded a simple RSS reader app based on the grid app template featuring support for settings, share and search charms.

I less than an hour the developers are about to start their 24 hour development marathon. I wish each and every one of them good luck and lots of success.

To make their life a little bit easier here are the links to my slide deck and app source code.

The 5th Bleeding Edge conference was taking place in Laško. For my session I decided to take a different approach to the development of Windows Store apps: instead of talking about the design or the available APIs in WinRT, I focused on architectural best practices when using C#, XAML and the MVVM pattern.

The slides from the session are on SlideShare as always:

You can download the final sources for the demo application here or even better: access the Git repository with a separate branch for each demo from the session.

If you've tried accessing an OData feed from a Windows Store apps you've already come across WCF Data Services Tools for Windows Store Apps. It's a downloadable package which extends the Add Service Reference functionality in Visual Studio 2012 to support OData feeds. Without it OData feeds can't be added as services references to a Windows Store app project.

The interesting thing about this installer is that it doesn't add the required references (Microsoft.Data.OData.WindowsStore and Microsoft.Data.Services.Client.WindowsStore) to the project directly but as NuGet packages instead. As it is also mentioned on the download page, this will make it possible to update the packages directly via NuGet. Unfortunately this approach also has a downside: at the time of writing these two packages are not available on NuGet atall. This is not a problem when you're working on the project from a single machine only, but it will make building the project a challenge on another machine if you're retrieving it from a source control system with NuGet package restore enabled. In this case the required references will not be present in the packages subfolder of the solution and NuGet will fail to restore them since it won't find them in the default package source.

The best way to make this work is to add another package source to NuGet, pointing to your local folder where the downloaded installer has put the packages, i.e. c:\Program Files (x86)\Microsoft WCF Data Services\5.0\bin\NuGet. I suggest you define it as the secondary package source, so that after the packages are available directly from NuGet, they will be retrieved from there instead from your local disk.

You can add the package source either through Package Manager Settings in Visual Studio Options window:

Or by modifying the NuGet.config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="NuGet official package source" 
        value="https://go.microsoft.com/fwlink/?LinkID=206669" />
    <add key="WCF Data Services Package Source" 
        value="c:\Program Files (x86)\Microsoft WCF Data Services\5.0\bin\NuGet\" />
  </packageSources>
  <activePackageSource>
    <add key="All" value="(Aggregate source)" />
  </activePackageSource>
</configuration>

One of the important aspects of Windows Store application development is the application lifecycle. While at first it might seem a minor detail that can be taken care of late in the application development process, it can affect the application architecture quite profoundly. Therefore it's a good idea to address it soon enough to avoid unplanned refactoring when the application is almost complete.

Since the basics of Windows Store application lifecycle are well documented, I'm not going to repeat them here. Rather, I'm going to focus on a single aspect of it: the transition between the running and the suspended state. During this transition the Application.Suspending event is called to allow the application to save its state to local storage which can be used to resume the application in case it gets terminated.

If you base your application on correct templates for Windows Store applications which are included with Visual Studio 2012 this will already be mostly taken care of for you. Both Grid App and Split App templates include a SuspensionManager class in their Common folder and also call it at all the appropriate spots in the application. This class can save the application state to the local storage into a file named _sessionState.xml and later reload it. It includes the complete frame navigation history consisting of the loaded pages and the parameters they were loaded with. As long as you only need this parameter to completely restore the state of the page, you don't have to do anything extra.

There's a function in Visual Studio that makes it easy to test that, it's just hidden in its default configuration. To access it you first need to show the Debug Location toolbar. There is a dropdown menu on it which is enabled only when the application is running. It contains three items: Suspend, Resume, and Suspend and shutdown. The last one is your friend when you want to test how your application resumes after it has been terminated: just run the application, navigate to the page you want to test and invoke the Suspend and shutdown action. The next time you run the application, it should resume with the same state.

Unfortunately you can easily break suspending and resuming in your application if you pass a custom class as the page parameter. Try it out! For example you can replace the UniqueId that's being passed between the GroupedItemsPage and GroupDetailPage in the Grid App template with a complete instance of SampleDataGroup. If you now Suspend and shutdown your application, the SuspensionManager.SaveAsync method will throw a non-descriptive SuspensionManagerException: "SuspensionManager failed". Investigating the call stack reveals that the failing method was actually Frame.GetNavigationState which has thrown an easier to comprehend COMException (It sounds like an oxymoron, doesn't it?): "WinRT information: GetNavigationState doesn't support serialization of a parameter type which was passed to Frame.Navigate.".

What can we do about it? As it turns out, not much. According to this Connect issue, it's a limitation of the platform that the Frame object can't serialize complex objects. The workaround is to only pass around the unique identifiers as it is demonstrated in both above mentioned Visual Studio templates. If you don't mind reloading your data every time a new page is loaded, that's not a problem. Otherwise you need to cache your data in memory.

Both templates contain only sample data and cache it in a static member. Unfortunately static members don't lend themselves well to the MVVM pattern and testing therefore it's a better idea to inject the application state into the view models. I like the following approach using the view model locator pattern:

public class ViewModelLocator
{
    private static ApplicationState applicationState;

    static ViewModelLocator()
    {
        applicationState = new ApplicationState();
    }

    public ViewModel ViewModel
    {
        get
        {
            return new ViewModel(applicationState);
        }
    }
}

The code can be improved further by using an IoC container which will ensure a single instance of the application state even without having a static reference to it in the view model locator as long as you scope it properly. But that's already a subject for another post.

The lifecycle of Metro style apps requires them to save their state when they are being suspended by the OS to prevent the potential loss of their state if they are restarted instead of resumed because they were inactive for two long.

The basic pattern of doing this is pretty simple. When the app is being suspended an event is raised by its Application class. The application state can be saved inside the event handler attached to it:

sealed partial class App : Application
{
    public App()
    {
        this.InitializeComponent();
        this.Suspending += OnSuspending;
    }

    private async void OnSuspending(object sender, SuspendingEventArgs e)
    {
        // do your work here
    }
}

By inspecting the SuspendingEventArgs passed to the handler you can see there’s a deadline for completing the operation. The following snippet can be used to see how much time you actually have available:

private async void OnSuspending(object sender, SuspendingEventArgs e)
{
    Debug.WriteLine(e.SuspendingOperation.Deadline - DateTime.Now);
}

The output will constantly be approximately 5 seconds. That’s the amount of time the OS gives the application to save its state before it forcibly stops the process. If you try running the following piece of code you might be in for a surprise, though:

private async void OnSuspending(object sender, SuspendingEventArgs e)
{
    await Task.Delay(1000);
    Debug.WriteLine("Done");
}

There will be no output in this case. It turns out that if you want to take advantage of all the time available, you need to tell that to the OS otherwise it will stop you well before the time runs out. There’s only a minor modification of the code above required:

private async void OnSuspending(object sender, SuspendingEventArgs e)
{
    var deferral = e.SuspendingOperation.GetDeferral();
    try
    {
        await Task.Delay(1000);
        Debug.WriteLine("Done");
    }
    finally
    {
        deferral.Complete();
    }
}

Of course, you still need to be done before reaching the deadline, otherwise the OS will step in anyway.