Looking back to understand the future: OpenFileDialog vs. FileOpenPicker

Most of us are familiar with the standard .NET OpenFileDialog object. With the introduction of Windows 8 Store apps the OpenFileDialog has gotten a facelift, a simplified API and yet somehow it’s still not quite the same. The new FileOpenPicker (or Picker) has been the subject of much mystery and confusion on the MSDN forums. What helped me get my head in the game was to compare and contrast the new and old. In this article I’m going to try and do just that.

I’m not going to talk about the various other classic file dialogs (IFileOpenDialog, GetOpenFileName, CFileDialog etc.). All of these APIs are very similar in functionality (keep in mind that all of these classic APIs are just incremental improvements over the file dialog box we had in Windows 3.1). So for simplicity I am going to stick with comparing the widely used OpenFileDialog object with the new FileOpenPicker.

File Open Dialog

File Picker

Similarities:
• They both enable a common UI to allow users to navigate their file storage space and select a specific item(s).
• They both allow filtering to limit the types of items.

Differences:
• The OpenFileDialog allows for UI customization. The FileOpenPicker does not.
• The OpenFileDialog returns a canonical path that represents the file that was selected.
• The FileOpenPicker returns a StorageFile object that represents the resource that was selected.

The key takeaway here is that both the FileOpenPicker and the OpenFileDialog accomplish similar tasks (i.e. allow the user to select something). The big difference is what gets returned.

When the FileOpenPicker returns, it hands you a StorageFile object. Unlike the standard file path we all know and love, the StorageFile object isn’t a pointer to a file. The StorageFile object is a pointer to a broker that points to some resource.
 
A broker is a software agent that is able to access a system resource on the behalf of the user. In other words, the user gives permission to the broker to access the resource via the FileOpenPicker. The broker then hands you a StorageFile object that represents the resource.

A resource can represent any digital data and can be located locally or remotely. In other words, a resource represents a data stream that could be located anywhere. It could even be generated. Just to try and drive this home; the standard canonical file path that we expect from our file open APIs doesn’t really exist in the Picker paradigm.

API mapping:

You can follow me @DevDailey and my team’s hashtag is #WSDevSol. Talk with you in the forums.