Mobile Corner

Storing Windows Phone User Settings

Persisting user settings in Windows Phone is something every mobile developer needs to know how to do. Nick Randolph walks you through the process.

• By Nick Randolph
• 05/08/2012

In this article we're going to look at how you can persist settings for your Windows Phone application. This might appear to be a relatively dry topic, but it's something most applications have to handle at some point.

There are settings required by the marketplace submission process, for example. One of them identifies whether the user has enabled the use of location or push notifications within the application. In addition, your application may have settings that allow the user to customize the application to suit him or her; for example, picking a favorite sporting team or whether the application sends a reminder for task due dates. In this article we're going to look at persisting settings on a single device: the next one will demonstrate how integrating with the cloud can synchronize settings across multiple devices, and even across device types.

Let's start by looking at how you can persist simple values like bool, int and string. These are the types of values you'd expect to find on a settings page within an application. All Windows Phone applications have a dedicated space on the phone into which they can save data: Isolated Storage.

In addition to providing basic APIs for reading and writing to files within Isolated Storage, Silverlight for Windows Phone also provides a wrapper class for reading and writing serializable objects to a key-value pair dictionary. Let's look at the following code example, which writes and subsequently reads back out a string value via the ApplicationSettings property.

IsolatedStorageSettings.ApplicationSettings["EmailAddress"] = "[email protected]";

if (IsolatedStorageSettings.ApplicationSettings.Contains("EmailAddress"))
{
    var email = IsolatedStorageSettings.ApplicationSettings["EmailAddress"];
    Debug.WriteLine(email);
}

One thing to be aware of is that the ApplicationSettings property returns an object that implements IDictionary<string,object>, so you should always check to see if a key exists before attempting to look up the saved value. An alternative would be to use an extension method, like the following:

public static class SettingsHelper
{
    public static object SafeValue(this IDictionary<string,object> settings, string key )
    {
        object outValue = null;
        settings.TryGetValue(key, out outValue);
        return outValue;
    }
}

var email = IsolatedStorageSettings.ApplicationSettings.SafeValue("EmailAddress");
Debug.WriteLine(email);

Within your application you're likely to have a handful of different settings. As such, it makes sense to refactor the reading and writing of these settings into a strongly-typed class. In the following example, the Settings class holds two settings: LocationEnabled and RefreshIntervalInMinutes, which are of type bool and int, respectively. This is reflected in the return type for the two properties exposed by the Settings class, shown in Listing 1.

There are two points worth noting here. The first is that the SafeValue method has been upgraded to a generic method, which will cast the return object to the desired type. If the key isn't found, or the value is of the wrong type, it will return the default value for the type specified, which for all classes will be null.

The second point to note is that the Location and RefreshIntervalInMinutes methods both use string constants to set and retrieve the settings values. While the example illustrates how you can factor out any string literals into constants, it would be nicer to not have the string constants at all. By using a little reflection we can eliminate the string constants, thus giving our code a bit more resilience when things change. See Listing 2 for the code.

The last thing to consider is how you'd use this class within your Windows Phone application. Within the logic of your application, you'd typically access the getters in order to access the current settings values. However, the standard way to permit the user to configure the application settings is via a dedicate settings page. Unlike other platforms where application settings reside alongside system settings, Windows Phone applications are responsible for providing their own interface for settings.

The other point to note about the Windows Phone settings page is that they don't have either a confirm or cancel button. When the user changes a settings value, it takes effect immediately. The user will have to use the Back button to return to the application after adjusting the settings.

So far we've used a static Settings class to read and write settings values. However, this can cause problems when creating a settings page and attempting to set up data binding, as it's not possible to databind directly to the static properties on a static class. To get around this, you'll need to adjust the Settings class as shown in Listing 3.

The simple Settings class introduced here provides a great starting point for storing user settings within your Windows Phone application. In the next article, we'll look at how you can extend this to synchronize settings across different devices via the cloud.