This blog post was authored by Douglas Laudenschlager, a Senior Content Developer on the Windows Phone Developer Content team.
Windows Phone 8 introduces new APIs for file handling that are convergent with the APIs in Windows Store apps. These APIs are in the Windows.Storage and Windows.Storage.Streams namespaces. You can use them in place of the APIs from the System.IO.IsolatedStorage namespace that might be familiar to a Windows Phone 7 developer. When you switch to the Windows.Storage APIs, it’ll be easier to port your Windows Phone app to the Windows Store, and easier to upgrade your app to future versions of the Windows Phone operating system.
You can see all the methods and properties of these new namespaces here:
Many of the methods in these namespaces are asynchronous methods that require you to use the async and await keywords. For more info, see Asynchronous Programming with Async and Await (C# and Visual Basic).
The Windows Phone SDK documentation team recently published the Basic Storage Recipes sample. Download the sample to see working examples of the programming tasks described in this blog post.
Here’s the list of tasks demonstrated in the Basic Storage Recipes sample:
In addition to showing you how to work with files, the Basic Storage Recipes sample also demonstrates the following tasks:
In Windows Phone 8, the isolated area of storage reserved for each app is called the local folder. Only the app itself (and the operating system) can access the files you store in this folder. Here’s how you retrieve the local folder using the Windows.Storage APIs:
Here’s how you previously retrieved the local folder using the IsolatedStorage APIs:
To create a new subfolder in the local folder, call the StorageFolder.CreateFolderAsync method.
To create a new file in the local folder, call the StorageFolder.CreateFileAsync method.
Use these methods to write a new text file in the local folder:
The sample method returns the path of the new text file. The sample app uses this return value to maintain a list of all the files it creates so it can delete them later.
Use these methods to read the contents of a text file in the local folder:
The sample method returns the contents of the text file as a string. The sample app uses this return value to display the output on a new page.
Use these methods to create a new binary file from the stream returned by the PhotoChooserTask or the CameraCaptureTask.
The sample method returns the path of the new binary file. The sample app uses this return value to maintain a list of all the files it creates so it can delete them later.
The Basic Storage Recipes sample displays the contents of the app’s local folder after you run each task.
To build the directory tree recursively, the sample app uses the following two methods, which are contained in a static helper class. These methods store the directory tree in a StringBuilder named folderContents.
If you call an async method directly to persist state in the Application_Deactivated event handler, the method never finishes its work. The trick is to run the task on a separate thread and wait for its completion. The following routine calls two helper methods that save the lists of folders and files created by the sample app when it’s deactivated. When the user activates the app again, the list of temporary files is still available for the Cleanup method.
The Basic Storage Recipes sample app we refer to in this blog post contains several methods and properties from the System.IO namespace that are still useful:
We hope you’ll find the Basic Storage Recipes sample useful as you adopt the Windows.Storage APIs in your apps for Windows Phone 8.
I'm a little stuck as to what guidelines to go by, when deciding whether to use the windows file storage api, or to use an actual DB, and thus Linq, for your app. I'm wondering if you know of a channel9 video or article on that.
My app will be storing many to-do task type objects, and these objects will have many properties.
I was reading Shawn Wildermuth's WP8 book, and he was mentioning that having a database is pretty resource-intensive, versus the Windows Storage, but wouldn't want to use file storage for something that it isn't equipped for.