Introducing the .NET Isolated Storage API
,The .NET isolated storage API uses the same stream-based model that is present in .NET for the desktop. The isolated storage API is located in the System.IO.IsolatedStorage namespace.
The IsolatedStorageFile class allows access to the virtual file system for reading and writing files, creating and deleting directories, and listing directory contents. The IsolatedStorageFile for an application can be retrieved using the static GetUserStoreForApplication method, as shown in the following example:
using (IsolatedStorageFile storageFile
= IsolatedStorageFile.GetUserStoreForApplication())
{
...
}
IsolatedStorageFile implements IDisposable and should therefore be disposed of when it is no longer needed. Placing it within a using block is a convenient way of disposing of the object.
The class IsolatedStorageFile has a misleading name, because rather than representing a single file in isolated storage, it represents the virtual file system. The public members of the IsolatedStorageFile class are presented in Table 28.1.
Reading and Writing Data to Isolated Storage
Chapter 7, “Employing Media and Web Elements,” discussed storing web content to isolated storage. The following (slimmed down) example taken from that chapter tests for the existence of a directory called WebContent. If it does not exist, it is created. We then create a file named Webpage.html. If the file already exists, it is overwritten. We then write some HTML to the file, as shown:
using (IsolatedStorageFile isolatedStorageFile
= IsolatedStorageFile.GetUserStoreForApplication())
{
if (!isolatedStorageFile.DirectoryExists("WebContent"))
{
isolatedStorageFile.CreateDirectory("WebContent");
}
using (IsolatedStorageFileStream isolatedStorageFileStream
= isolatedStorageFile.OpenFile(
@"WebContentWebpage.html", FileMode.Create))
{
using (StreamWriter streamWriter
= new StreamWriter(isolatedStorageFileStream))
{
streamWriter.Write(@"<html><head></head><body>
<h2>Stored in Isolated Storage</h2></body></html>");
}
}
}
Using FileMode.Create in an OpenFile call is equivalent to requesting that if the file does not exist, FileMode.CreateNew should be used; otherwise, FileMode.Truncate should be used.
Note
The file system used by Windows Phone is TexFat and supports filenames that are no longer than 247 characters. Files placed into isolated storage sit in the apps install directory, which has a path resembling the following:
APPLICATIONSINSTALL45DC3711-8AF7-42BF-A749-6C491F2B427FINSTALL
The length of this path minus the native path to this directory leaves approximately 161 characters. If you attempt to write a file whose path is longer, an IsolatedStorageException is raised.
After the file is written to isolated storage, it can be retrieved, as shown in the following example:
string html;
using (IsolatedStorageFile isolatedStorageFile
= IsolatedStorageFile.GetUserStoreForApplication())
{
using (IsolatedStorageFileStream isolatedStorageFileStream
= isolatedStorageFile.OpenFile(
@"WebContentWebpage.html", FileMode.Open))
{
using (StreamReader streamReader
= new StreamReader(isolatedStorageFileStream))
{
html = streamReader.ReadToEnd();
}
}
}
Note
Attempting to open a file using a FileMode.Open argument raises an exception if the file does not exist. FileMode.OpenOrCreate specifies that the operating system should open a file if it exists; otherwise, a new file should be created.
Serialization Performance Implications
When your app is transitioning from a nonrunning state to a running state, and vice versa, it is important that it completes all activities as quickly as possible. Being slow at startup or shutdown can make your app appear sluggish and poorly engineered. Furthermore, there is a limit of 10 seconds before an app’s process is terminated when it is being closed or deactivated.
To improve performance, consider favoring binary serialization over other types of serialization, such as XML or JSON serialization.
Unlike interacting with the user interface, there is no requirement to perform isolated storage activities on the main thread. When loading state at startup, or while performing arbitrary CRUD operations, the use of a background thread can improve the responsiveness of your app during long-running storage operations.
To prevent locking the UI unnecessarily, if a storage operation takes more than 100 milliseconds to complete, move the operation to a background thread or switch to the WinPRT Windows Storage API, which provides awaitable methods for most IO operations.