A case of settings separation – NSUserDefaults to app and user settings

The work of a software developer can be fun, but can also be very monotonous.

This iPhone game-app that I’m developing has its glorious moments, like when I finally got the first sound effects in and they gave a whole new level of excitement.

Then there are days like the last couple weeks when I’ve been designing and building the game menus.  These moments are full of dark, frustrating moments, with the odd ray of sunshine.

A few minutes ago I felt one of those sunshine rays!

The moment came when I created a single new property of my project’s main class.  Until this moment, I had an object called userDefaults, being an  NSMutableDictionary.  I had been using this with the iPhone SDK’s NSUserDefaults shared instance (standardUserDefaults message).  Thus I had named my object “userDefaults”.

Yet I was feeling uncomfortable with this, because I have various levels of information that I want to save when the user ends a game-play session/level/round, etc… and also when a user quits the app.

Now I believe there are methods to use NSUserDefaults with great efficiency.  I haven’t gone through the guides and experimented.  Right now, I’m more interested in Core Data for information management.  But, I haven’t gone through Core Data either.  There are many different ways to store data, and I’m not going to devote any more time, beyond what I’ve spent already, to learning better ways before I launch my app, because I’m not working on something with thousands of values, that need to be accessed quickly or changed in complicated ways.  So loading and saving property list files seems sufficient for this development time.

All I have are my trusty methods I’ve written that load, save and delete structures to property-list files.

But it came to the point of being unsure how to organize the values into dictionaries or arrays, and if the information for one player files should be saved in a file separate to another file for another player, or combine the player data into a single file for one set of information.  That’s a bit abstract… sorry.  What I mean is, … I got confused.

So I went through the code for managing the game settings, and somehow just thought up this idea:  app settings.   Up until now, I’ve been calling all settings under the umbrella-term “user defaults” or “user settings”.

Now when I see the two words “app settings”, I was able to understand a new level of separation.  Simple, it seems so obvious now, why didn’t I think of it before?  I suppose because a lot of problems are solved by coming up with new, better names for things.  Going into a paint store and asking for a can of blue paint could lead to a thousand different choices.  Asking for cobalt blue really helps.

All my settings that are not user-specific will be called app settings, and the user specific settings … are going to be saved as files separated by player account.  That gives me a LOT of mental clarity for the next few hours of work.