Would backing roaming settings with a class be elegant or Rube Goldbergesque?

Question

I am using roaming settings to store state ASAP and restore it JIT, or ALAP (L = Late).

For the possible advantage of using data binding for properties that are accessed/mutated in this way, I'm thinking of creating a class that would mirror the roaming settings, inflating the class during the app's OnLaunched and OnResuming events with the roaming settings.

By doing this, I could bind properties to the class members, rather than have a gazillion lines of code like:

        textBlockPlatypus1.Text = App.roamingSettings.Values["Platypus1"].ToString();

Is this a stroke of genius on my part -- well, a good idea -- or would I just be overcomplicating things by adding this extra layer to something that's pretty simple?

Answer 1

Seems like a reasonable approach. I might suggest just serializing/deserializing whatever class you end up with and writing to a file in RoamingFolder rather than RoamingSettings. It should be pretty easy to store and retrieve in more or less a single line of code (versus individual name/value pairs via RoamingSettings). This is essentially what the SuspensionManager does in some of the C#/XAML templates.

Be mindful or how much you are saving though, there are limits - your goal is to be able to restore the state of the application as the user perceives it, not necessarily save EVERYTHING, particularly if it can be reconstructed 'under the covers' when the application is re-activated.