The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
I like to randomise it on every load to keep people on their toes.
Seriously though, where I need to I roll my own - XML file normally to save the data, then my own class on top so that I can make sure it's strongly typed. Probably not the most efficient possible, but if I can add XML comments to my settings class the intellisense saves me a load of frustration trying to remember stuff.
Previously I have stored the applications state is a custom rolled Configuration class that reads/writes the settings to an xml file. The reasons for this approach was I had previously had "issues" using the AppSettings and got tired of them. However, lately I used AppSettings again, probably evolution of the .Net framework have sorted out the "issues" I had experienced.
I store settings and preferences (that can be safely recreated if missing) in an XML file. I store application data that I don't want a user to be able to edit (and therefore corrupt) in a binary serialized Gzip'd file.
Marc Clifton wrote:
do you even save the user's preferences / state of the UI?
Yes (as much as I can). It's one of my personal criteria for a "polished" app.
Dang Marc, have you been reading my hard drive again?
I have a data class that contains named value pairs and supports String, Integer, Double, Date and Boolean values. These can be read from file in a simple format and used to persist state. The data class is also used for passing between services. It is my general throw around format.
I need to work out an article for just this as I have 3-4 more that all use it so the DataSet becomes a pre-requisite article to write.
Reality is an illusion caused by a lack of alcohol
Dang Marc, have you been reading my hard drive again?
Nagy Vilmos wrote:
I need to work out an article for just this
That would be great. The impetus, partly, for my survey'ish question is because I've been adding state/configuration persistence to an app, and I was wondering what sort of "best practices" there might be out there. The .NET class seems not configurable enough - I'd like to leave it open to the developer as to how to persist the state information. On the other hand, it also seems to closely coupled to "the Microsoft way", what with all the binding support, not that one needs to use it.
At the moment, I've decided to go for an interface-less, more functional approach, resulting in this raw usage example:
Program.AppState.Register("Form", () =>
new State("X", View.Location.X),
new State("Y", View.Location.Y),
new State("W", View.Size.Width),
new State("H", View.Size.Height),
new State("WindowState", View.WindowState.ToString()),
// Silently handle exceptions for when we add state items that are part of the state file until we // save the state. This allows me to add new state information without crashing the app on startup.
Program.Try(() => View.Location = new Point(state.Single(t => t.Key == "X").Value.to_i(), state.Single(t => t.Key == "Y").Value.to_i()));
Program.Try(() => View.Size = new Size(state.Single(t => t.Key == "W").Value.to_i(), state.Single(t => t.Key == "H").Value.to_i()));
Program.Try(() => View.WindowState = state.Single(t => t.Key == "WindowState").Value.ToEnum<FormWindowState>());
App option specific stuff locally on the machine of the client. If there is a server everything else goes there into a database. Else I use depending on the amount of data a SQLite DB or XML/CSV files located in the AppData for everything.
For more complex data I try to stick to DB-like data, with SqlCE files or XML if I want human readable.
I also have a encryption class which has a file option for more secure data - but the data I serialise to that is normally XML.
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
Back when I was a teenager, I thought saving UI State was all the rage but I soon gave it up. The massive amount of code required to store and manage it and make it all perfect just wasn't worth it. Heck, even today, I have a problem when I load firefox at home. You see I have a laptop hooked up to another monitor. However, that monitor is also wired to another machine. When the other machine is on, Windows on the laptop works fine but when I open something that was previously opened on the second monitor guess where it opens?
If Windows and Firefox can't manage to get UI saving settings right why even bother? Plus, if you make an infinitely configurable UI, power users will complain that they can't configure X and that is so obvious or worse an upgrade will wipe their settings and lose you a customer.
So, long story short, only save the bare essentials that make the app usable. The rest, don't make configurable unless they ask.
IMHO, this is a generic problem: i.e. restoring potentially invalid state. Whenever I restore state (almost always from an editable XML file), my code validates and auto-corrects the data being read. Other examples of this are selecting a tree node that may no longer exist, etc. The bottom line is, it's the developer's responsibility to handle all possible use cases.
All this takes additional work and time. And your users will love you for it.
I have been a developer for many years now,
and I support this message to the fullest.
So should YOU!
Seriously, settings are such a hassle.
The 'Appconfig' likes to forget them.
If you roll your own you have to be backward compatible.
Even VS has a 'reset to defaults button' for the interface because
it can get stuck in a bad layout you can not manually correct anymore.
If you provide too many options your application becomes 'too difficult'
Fortunately I was able to convince my coworkers of this.
Our application remembers the sizes of the screens,
when a screen is shown, it checks if the position is a valid
desktop position (making multi-monitor compatible even if you remove a monitor).
Whenever a customer ask for more setting, we say:
Tell us exactly what settings you want.
For which screens?
How should remember them?
Is it ok to break it with future changes.
But before you do this, remember that each setting cost 1 hour to develop,
1 hour to deploy, 1 hour to test.
Plus the square root (in hours) of all settings combined for additional testing where settings may interfere with each other.
Then multiply that with out hourly wage and ask yourself this question:
"Do you really want that setting?"
Maybe, one day, one of our clients will say yes...
Then we'll slap them with a 200% 'we really do not want to do this' bonus fee.