This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.
Last week, I described the settings infrastructure that I’m building for Time Tortoise. This week: implementation details.
Settings and ISettings
One of my design goals for settings is that individual settings should be accessible as properties. For example, to retrieve the idle timeout setting, I could use this code:
if (duration.TotalSeconds >= _settings.IdleTimeoutSeconds)
The goal is for settings to be type-safe (not all strings), and visible to the programmer at design-time. Type
_settings. in a C# file in Visual Studio, and all available settings are shown in a list.
_settings is of type
ISettings, and it contains one property per setting. This does mean that when I add a new setting, I have to update the class and its interface. I can’t just add it to the settings text file and have it picked up automatically at runtime. But I don’t think that’s much of a disadvantage.
Settings implements an interface, unit tests can use mock settings. This allows each unit test to returns a custom value for each settings, based on the scenario being tested. No settings text file is necessary in this case.
SettingsUtility and ISettingsUtility
SettingsUtility class takes care of reading from the settings text file, updating an instance of the
Settings class, and exposing the
Settings class as a property.
Reading the settings file using YamlDotNet is simple:
var input = File.ReadAllText(_settingsFileName); var deserializer = new Deserializer(); Settings = deserializer.Deserialize<Settings>(input);
Line 1 reads a text file into a string. Line 2 creates the YAML deserializer. Line 3 deserializes the YAML string into the
Settings object. Now we have an object full of settings.
The YAML format is as simple as a text file can be. If the
Settings class has a property called
IdleTimeoutSeconds, then this line in the YAML file will be deserialized into that property:
The string-to-integer conversion happens automatically.
SettingsUtility implements the
ISettingsUtility interface, unit tests can provide a mock utility class that doesn’t actually read a text file from disk, and just exposes a mock
Settings class with the appropriate settings values.
Notice that I haven’t mentioned any utility functions for updating settings. That’s because my text file UI design relies on a text editor to do the updates. That saves time on app UI that I can use for other features. And the target audience for this app is expected to be comfortable with a text editor. In my case, even as a user, I would rather edit settings in a text editor than fiddle with the app UI.
View Model Changes
SettingsUtility reads a file from disk, I decided the best place for it was in the Model. When a View Model class needs access to settings, it accepts a
SettingsUtility instance in its constructor (the dependency injection pattern). This allows unit tests that are testing that view model class to mock the settings classes.
Once a view model has the settings dependency available, it can use it to retrieve the settings values that it needs.
(Image credit: Didriks)