Exploring WinRT: Windows.Storage namespace overview-(Picture, video, music and document)

http://lunarfrog.com/blog/2011/10/03/winrt-storage-overview/

Exploring WinRT:

1. Windows.Storage namespace overview
2. File and Folder Pickers
3. Storage.AccessCache

Presenting Windows 8, Microsoft put a lot of emphasis on the new UI design and the users experience improvements. But for me, as the productivity and file management tools developer, UI-related changes, changes in the installation process, OS integration and file system access are equally important. In this post and the following posts I’d like to share my findings and thoughts related to these APIs.

As we already know, file system access for the WinRT apps is heavily restricted. The following diagram represents the big picture and was widely discussed during the BUILD sessions.

The full, unrestricted access is enabled for the app’s local folder only, located in

C:\Users\<user_name>\AppData\Local\Packages\<package>

. Within the local folder you can create, modify and delete files and folders without asking user’s permission. Local data access is provided using Windows.Storage.ApplicationData class:

var localFolder = ApplicationData.Current.LocalFolder;
var file = await localFolder.CreateFileAsync("data.txt");

If you are planning to access user’s documents, music, videos or any other data located in one of the system libraries, you have to indicate it through the app’s manifest. If app is trying to access a library item without specifying the corresponding capability in manifest, a runtime exception System.UnauthorizedAccessException will be thrown notifying you that access is denied.

Manifest editing is simple with new manifest designer integrated into Visual Studio 11:

For the Music, Picture and Video libraries you are specifying the features you want in the Capabilities list and you are done. For the Documents Library things are more complicated. In addition to specifying Documents Library Access, you have to specify all the file types you want to be able to access using File Type Association declaration:

The reasons for this implementation are understandable, but it does not mean that I like it. I can imagine multiple scenarios when tools may need an access to the files with an unknown type. Yes, apps can use File Picker to access these files, but it requires interaction with user and in the certain cases prevents tasks automation.

Anyway, when manifest is configured properly, the library files and folders become available to the app with help of Windows.Storage.KnownFolders class:

var pictures = KnownFolders.PicturesLibrary;
var allPictures = pictures.GetFilesAsync();

Do you need a programmatic access to the files outside of the local folder or the libraries? Sorry, there is no API for this. File picker is your best friend here – let your user to choose files for you. There is only one exception – user’s Downloads folder.

To access Downloads folder your app does not need to specify any capabilities in the manifest, but in return it has write-only access to the folder. Windows.Storage.DownloadsFolder class is declared as static and exposes two methods only – CreateFolderAsync and CreateFileAsync. Of course, once your app created a new file (folder) and retrieved StorageFile (StorageFolder) object, it has full access to this item. But as soon as the object is disposed, the newly created files and folders become unavailable for you.

var folder = DownloadsFolder.CreateFolderAsync("New Folder");
// working with the folder ...

And last thing to overview is the application’s installation folder. This folder is located in C:\Users\<user_name>\AppxLayouts\ and, surprisingly, is read/write accessible via Windows.ApplicationModel.Package class:

var installationFolder = Package.Current.InstalledLocation;
var newFolder = await installationFolder.CreateFolderAsync("Setup");

inShare1