I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as well.
In my last post in this series I discussed the Windows Phone Application Bar. In this post I’ll take a look at Isolated Storage.
Isolated storage allows Windows Phone applications to create and maintain device based storage. Now, before we get into the details of the isolated storage API’s let’s take a minute get an understanding of how isolated storage is implemented architecturally on Windows Phone.
At the foundation of isolated storage is the physical file system residing on the disk of the hardware. At the very top is the space where our applications resides.
Sitting between our applications and the physical file system is a virtual file system. This is isolated storage. It gives us an abstraction for working with files and folders without having to be dependent on the physical disk. The advantage here is that if Microsoft changes the OS and how the physical file system is implemented, we don’t need to worry about our applications breaking as were only dependent on the abstraction, not the implementation.
To get a better understanding of how our applications interact with interact with the virtualized file system, let’s say we have three applications (A, B, and C). Each application will have its own root in the virtualized store. Which it can then use to create and access files and folders. Now, you may be tempted to think, that, since you have all of these virtual roots, you can have an app that access the virtual stores of other applications This is not permitted. An application can only access its own store.
When working with isolated storage, there are three classes you need to be familiar with. All of which reside in the System.IO.IsolatedStorage namespace The first class is the IsolatedStorageFile class. This class represents a virtualized file system, that can contain directories and files for use by your application. You can use this class to determine how much space is available for use by isolated storage as well for creating and iterating folders and files in the virtualized space. The next class is the IsolatedStorageSettings class. This gives a quick way to store user specific data in isolated storage via in key-value pairs. Examples of such data might be whether or not to let the application run under the lock screen, whether or not to enable push notifications, etc. The last class is the IsolatedStorageFileStream class. You can leverage this class to work with a single file in isolated storage. In a typically stream fashion, this class gives you the ability to read and write data to a file, with the exception being that the file, in this case, is stored in the virtualized environment of isolated storage.
Now that you know the mechanics of working with isolated storage, I’ll spend the remainder of this post looking at when and where it is appropriate to use.
When working with isolated storage it’s important to know when it’s appropriate to both persist data to and load data from this virtualized store as there is latency when performing reads and write with isolated storage. You may be tempted to use the Application_Launching and Application_Activated methods that are part of the generated App class to load data from isolated storage when your application first starts up or is activated after being tombstoned. Similarly, you may be tempted to use the Application_Deactivated and Application_Closing methods that are part of the generated App class to save to isolated storage before your application is closed or tombstoned. However, if you’re going to do this there are some timing restrictions you need to be aware of and make sure your application doesn’t violate:
- When your application launches, it must render the first screen within 5 seconds.
- The application must be responsive to user input with 20 seconds regardless of if the application is launching for first time or being activated after being tombstoned.
- When the application is being activated or deactivated the event handlers must complete their actions within 10 seconds.
Failure to meet these requirements will result in your application failing certification requirements and not be accepted into the marketplace. I bring these timing restrictions up because loading/saving data from/to isolated storage can be time intensive. The best approach to take is to either load data either on page-by-page (as opposed to overall application) basis or on a background thread. Similarly, with regards to saving data, a good approach is save data at points in time throughout the usage of your application as opposed to waiting until the user is done with the application before saving.
Previous posts in this series