Exploring WinRT: Storage.AccessCache

October 10, 2011
C# File System Windows 8 WinRT
 

Exploring WinRT:

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

Let’s imagine that we are creating a Metro style text editor. With help of the pickers users are able to open and save files at any location. But what if the user wants to reopen a file he or she edited last week? Do we need to show the picker and ask him to open file again? It will be nice to have a list of the recently used documents and provide a way to reopen them with one click.

Fortunately, WinRT architects thought about this scenario and introduced several classes grouped together within Windows.Storage.AccessCache namespace:

...
StorageFile file = await filePicker.PickSingleFileAsync();
string token = StorageApplicationPermissions.FutureAccessList.Add(file, “metadata”);

If you have an object of StorageFile or StorageFolder type and you want to keep it accessible, class StorageItemAccessList provides you a way. Method Add() will add your file system object to the list and return a string token (GUID) that can be used in the future to get the object back. All the added objects stay accessible even after application restart and can be easily retrieved without interacting with the user:

if (StorageApplicationPermissions.FutureAccessList.ContainsItem(folderID))
{
   StorageFolder folder = 
         await StorageApplicationPermissions.FutureAccessList.GetFolderAsync(folderID);
   ...
}

where StorageApplicationPermissions is a static class declared in Windows.Storage.AccessCache.

If you want to provide your own token, there is an alternative to Add() method:

StorageApplicationPermissions.FutureAccessList.AddOrReplace(“LastUsedFile”, file, “metadata”);

This method adds a new item to the access list, or replaces the specified item if it already exists in the list. The last parameter for both Add() and AddOrReplece() is an optional metadata to associate and store with the file system object. There is no special methods to access the metadata, it is only accessible through Entries collection:

...
AccessListEntry item = StorageApplicationPermissions.MostRecentlyUsedList.Entries[n];
string metadata = item.Metadata;
...

The same tokens are used to remove the items from the access list, using Remove(). Or you can use Clear() method to wipe out the list completely. These methods are important because the list is not boundless – the maximum number of the items in the list is indicated by MaximumItemsAllowed and for me it is equal to 25. Yes, just 25 items can be saved simultaneously, so goodbye an idea to track all the files ever used.

It is very common situation, when your app is trying to open a previously used file but the file does not exist because it is already renamed or moved. Good news: FutureAccessList tracks this situation automatically. Even if the file or folder moved, it is still associated with the same token and will be returned to you when you need it.

In addition to FutureAccessList, StorageApplicationPermissions includes MostRecentlyUsedList property of StorageItemMostRecentlyUsedList class. This is an independent list that implements the same functionality as FutureAccessList and can keeps up to 25 storage items. The only difference is an ItemRemoved event, implemented by StorageItemMostRecentlyUsedList, but I was not able to trigger it – Remove() and Clear() do not fire this event. It is not clear why do we need both classes and my best guess that MRU list will be used by system somehow, but in the Developer Preview version these interactions are not implemented yet.

blog comments powered by Disqus