Persistent Settings in Desktop Applications

What is a Persistent Setting?

In desktop applications, or applications generally, when you modify a high level setting you expect that setting to persist across application instances or that that setting sticks and is applied the same no matter how many times you close and reopen the application until you change it again.

This is what I refer to as a persistent setting.

An example of this type of setting might be the application window size and position such that when you open an application it will be in the same place and be the same size as it was when it was last closed.

Any setting that is comparatively temporary is what I would call a transient setting.

Persistent vs Transient, How to Choose?

In most cases the nature of the setting itself will determine whether or not it should be persistent.

Persistent settings will generally be higher level application settings whereas transient settings would more likely be related to smaller subsections.

You can also think about it temporally, if you want the setting to last for ever make it persistent, if you want it to apply just this one time make it transient.

Transient settings are not too interesting as they live most probably as just a regular variables in volatile memory.

Persistent settings also live in variables in that same memory while the application is running  but their state needs to be tracked even when the application is not running.

How can you achieve this?

How to Implement?

Non-volatile memory.

With a little bit of initialization and cleanup(closing, destructor) code, you can achieve persistent settings by just, for example, reading the setting from a file when the application starts and write the value back when its closed.

I typically do this either using an actual config file that lives in the normal file system, or by using OS provided memory locations for example the registry on Windows. Once you choose where you want to save the value, all you need to code to read the value when that application starts and write the value back either when ever the value is changed of just when the application closes.

Issues I have Come Across and How to Address Them

Persistent settings are great from the users perspective, but, from the developer perspective, they introduce many interesting side effects.

Initial values

With the addition of persistent setting in an application, you should remember that there is now a difference between just starting an application and starting an application for the first time ever on a new machine. When doing release testing, I always use a clean virtual machine just for this purpose so I can make sure that the true first time install experience is working as expected.

Differences between versions

You might change the way you use or store a particular setting in a new version of the application. You should account for the case that you will have settings stored from one version used in a later version - in the case that the user has just upgraded to a new version. This could be avoided by changing the name or location of settings whose purposed has changed version to version.

Crash loop

If you change a persistent setting and it causes a crash, maybe due to some edge you were not checking for, there is a good chance that when you try and restart the application it will just crash again since it will read back the same value that made it crash in the first place. This is a bit tricky to protect against, your best bet is to just test against all of the valid range of the settings and validate the settings are in that tested range when read on application start.

Handling un-graceful exits

You might have chosen to achieve persistent setting by saving the setting state to non-volatile memory one when the application closes. If you take this approach, then if for any reason your application does not exit properly, your values will not be saved. This might happen if there is a sudden power loss for example. To work around this, you should save the setting whenever it is actually changed. This way, no matter what happens, the correct value will be read on the next application start. Avoid this solution if your setting store code is expensive and runs frequently or the settings change often. In this case you could find a middle ground and periodically(on a schedule) save the settings in batches.

Vulnerabilities

Both the registry and file non-volatile memory options for persistent setting storage open the application up to attack from a nefarious user. This user can now directly insert what ever they want directly into your application by modifying the memory that you decided to store you settings in. You might protect against this attach by encrypting your settings before you store them, this will slightly complicate your read/write functions.

Final Thoughts

When developing with persistent settings, you have to keep in mind the range of what could have possibly happened before the application starts. Validate settings as they are read in, protect anything sensitive, make sure your old version data will not break your latest version.