Time Tortoise: Settings

JSON

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 explained some ways I’ll be using text files in the Time Tortoise app. One example: storing application settings in a text file. That’s the topic of today’s update.

UWP Settings

The UWP guidelines for app settings contain requirements that explain what settings pages should look like and how they should work. For a few reasons, I have decided to ignore these requirements:

  • As I mentioned in Text File User Interface, it takes time to expose functionality through a graphical UI. I’d rather spend my time elsewhere for now.
  • Although I’ll be starting by storing simple settings values in text files, I have some ideas for features that will work better if the user can use a text editor to construct their input, rather than clicking around in a GUI.

Although I’m not planning to use the built-in settings infrastructure, I did try it out by adapting an example from the documentation. Here’s my version:

Windows.Storage.ApplicationDataContainer localSettings =
    Windows.Storage.ApplicationData.Current.LocalSettings;
localSettings.Values["helloSetting"] = "Hello Time Tortoise";

When this code runs, the helloSetting setting is written to a binary file called settings.dat, which is stored in the %LocalAppData%\Packages\[package_name]\Settings directory.

The binary file format that the the built-in settings infrastructure uses is another reason why that infrastructure is not ideal for my text-oriented plans.

Idle Timeout Value and Companion Server URL

As a first scenario for my text-based settings, I’ll be using two settings associated with the idle time feature: the timeout value, and the server URL.

The timeout value represents the number of seconds that must elapse before the user is considered idle. Currently this value is hard-coded to 10 seconds (to make manual testing easier) in MainViewModel. A more realistic number for normal use is 300 seconds (5 minutes). But the user should be able to pick a value that works for them. And unit tests should be able to set their own value, though with the correct use of mock time, the test doesn’t have to wait for even one second.

The server URL is used when Time Tortoise connects with the Time Tortoise Companion (TTC) server to retrieve idle time data. It needs to match the value specified in the TTC code. In cases where two Time Tortoise client/server pairs are running on the same machine — e.g., one in Visual Studio for testing, and another one for activity timing — it is necessary to be able to specify two different server ports.

YAML

To use text files for settings, we need to decide on a text file format. This format must be understandable by the Time Tortoise code, but one reason to use a text file format is so that humans can understand it as well. XML and JSON are two of the most popular data serialization formats, with JSON considered the more human-readable of the two. But even JSON, with its curly brackets, is more code-like than I would prefer for the settings files that I have in mind.

YAML is based on JSON, but like the Python programming language, it uses indentation rather than braces to indicate data structure. I find this approach to be easier to read and edit.

Here’s a simple YAML file that stores the two Time Tortoise configuration values explained above. The # characters indicate comments.

# Time Tortoise settings file

# Number of seconds before a user is considered idle
IdleTimeoutSeconds: 300

# Address and port used to connect
# to a Time Tortoise Companion server
CompanionServerUrl: http://127.0.0.1:8080

Although YAML isn’t as ubiquitous in all environments as JSON is, I found a library called YamlDotNet that is actively being developed. It even has a .NET Core version that will be convenient for use with Time Tortoise libraries.

(Image credit: The public domain JSON logo. YAML, unfortunately, doesn’t have a logo.)