Handling file/folder pickers and the web authentication broker in universal Windows apps

Hi, this is Jeffrey Richter. I was very excited when Microsoft announced universal apps for Windows Store and Windows Phone apps. One reason is that I can now use my existing C#/CLR/WinRT skill set to build phone apps. Another reason is because it means my Windows Runtime via C# book now has a new audience. In fact, the book’s content is entirely applicable for Windows Phone 8.1 developers except for the few differences described in this earlier blog post, “Windows Phone updates for Windows Runtime via C#.” I’ve already converted all the book’s code samples to universal apps, and I have them running on both Windows and Windows Phone. You can download this code from the book’s catalog page in the new Microsoft Press Store (via the Downloads tab).

Of course, the main reason to use universal apps is because it allows you to create different user interfaces for Windows Store, Windows Phone, and XBOX apps while sharing your business logic between them. Specifically, universal apps allow your common business logic to exist in a shared project while your platform-specific user interface code resides in platform-specific projects. However, while I was converting my book’s samples to universal apps, the toughest thing I ran into is the difference in how Windows Store and Windows Phone apps handle file pickers, folder pickers, and the web authentication broker. Because phone devices typically have small amounts of RAM (some with just 512MB), after your app displays a picker or web authentication broker, the system suspends your app and possibly terminates it. This frees up memory, giving the user a better experience with the picker/broker. Then, after the user has completed using the picker/broker, the system activates your app again, calling your App class’s virtual OnActivatedmethod. You must override this method to get the result of the user’s interaction with the picker/broker. For Windows Store apps, your app just continues to run while the user is interacting with a picker/broker. These two models are pretty different from one another, so the code you must write to handle these two models is also pretty different.

I didn’t like this, so I set out on a mission to come up with simple and reusable helper classes, allowing me to write code once and have it work for both Windows Store and Windows Phone apps. In addition, my classes simplify the code necessary to handle the continuation. Even if you care only about Windows Phone apps, my helper classes simplify the code necessary to work with a picker/broker. With my helper classes the code to show a picker looks like this:

The GetContinuationData method is an extension method available via my helper class. This method allows you to add, remove, or examine continuation data that you can associate with the picker. The PickSingleFileAndContinue method is another of my extension methods. It displays the displays the picker and indicates which method should be invoked when the user is finished using the picker. The code in this callback method should look similar to this:

In a Windows Store app, my PickSingleFileAndContinue extension method invokes your GetFileContinuation method after the user dismisses the picker. In a Windows Phone app, Windows will activate the app calling your App class’s OnActivated method. Your code must override this method and call another extension method (OnActivatedForContinuation) provided by my helper class. My method will, in turn, invoke your GetFileContinuation callback method. My OnActivatedForContinuation method does nothing when called in a Windows Store app. Here’s what your App class’s OnActivated method should look like:

The pattern I show in this blog post works for all the file and folder pickers. I have a similar pattern that works with the web authentication broker. I encourage you to download the sample code for Windows Runtime via C# to get my helper classes and to see examples of how to use them with the file pickers and the web authentication broker.

While working on this code and understanding the motivation for Microsoft’s Windows Phone team to implement the pickers/broker with this continuation mechanism, I came to a very important realization: you must design Windows Store and Windows Phone apps to conserve as much memory as possible. The small amount of RAM on phones is what led Microsoft to design the pickers/broker with this continuation model. And, as tablets and portable computers become more commonplace, the machines our apps run on are likely to have less memory than what we as developers have become used to. This requires that we design our apps to conserve as much memory as possible. Let me give you an example.

In the past, I might design a Windows Store app so that every time the user launched my app due to a file association, I’d add a new page to my frame, allowing the user to work on this new file. But I’d also allow the user to navigate backward and forward through all the files he or she had sent to my app. The problem with this design is that my app might have multiple files in memory simultaneously. These days, realizing how limited memory is, I’d design my app differently. Whenever the user launched my app via a new file, I’d save the current file and allow its content to be freed from memory, thereby making room for the new file’s data. This way, my app would never be working on more than one file at a time, conserving memory and probably simplifying the user experience too.