Morse Coder Part 6 : Handling Application Settings – Explicitly Typed and Blendable

In Universal Apps the ApplicationData.LocalSettings Property in the Windows.Storage namespace can be used to persist Application Settings. It stores your data into an ApplicationDataContainer, which ultimately provides a wrapper around a Dictionary<string, object> and manages the persistence around the application lifecycle for you.

Outcome

It can be helpful to be able to reference your Application Settings without needing to cast them from the object stored in the dictionary to the relevant type before consumption every time. We’ll look at wrapping an interface around our Application Settings, giving us the object types, along with the ability to be able to use application settings in our UI at design time.

Prerequisites

Implementation

Let’s start with the interface we previously created to allow reference to our settings.

namespace MorseCoder.Interfaces
{
public interface IMorseCoderSettings
{
string Input {get;set; }

TranslationDirection Direction {get;set; }
}
}

We’ll expand on our concrete implementation of this in the MorseCoderSettings class to persist our settings…

public class MorseCoderSettings : IMorseCoderSettings
{
private const string _inputKey ="Input";
private const string _directionKey ="Direction";

private const string _inputDefault ="Type your Morse Code Text Here!";
private const TranslationDirection _directionDefault = TranslationDirection.AlphabetToMorse;

ApplicationDataContainer localSettings = ApplicationData.Current.LocalSettings;

public string Input
{
get
{
if (localSettings.Values.ContainsKey(_inputKey))
{
return (string)localSettings.Values[_inputKey];
}
return _inputDefault;
}
set
{
localSettings.Values[_inputKey] = value;
}
}

public TranslationDirection Direction
{
get
{
if (localSettings.Values.ContainsKey(_directionKey))
{
return (TranslationDirection)localSettings.Values[_directionKey];
}
return _directionDefault;
}
set
{
localSettings.Values[_directionKey] = value;
}
}
}

There’s a few things to note there:

  • Key Constants to provide a consistent key for use with our Dictionary of Key Value Pairs;
  • Default Value definitions to allow attempts to retrieve values out of the Dictionary which haven’t been initialised;
  • Getter methods, checking for a key in the dictionary and retrieving it, else returning previously defined default values’
  • Setting methods, creating or updating the dictionary entry.

There’s a bit of duplication within the setter methods there, we’ll revisit this in a later post.

We can now persist data to the application’s LocalSettings store via our interface, meaning that we can call…

_morseCoderSettings.Input ="I'M GOING TO BE PERSISTED";

…from our View Model to “save” our setting, meaning that we can now sustain the translation input between application lifecycles.

Summary

We now have a persistent store for storage of application settings and small pieces of data available through Properties on an interface, the same Blend experience is still offered through the use of the DesignMorseCoderSettings class previously created, with our MorseCoderSettings class now being functional.

3 thoughts on “Morse Coder Part 6 : Handling Application Settings – Explicitly Typed and Blendable”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s