I've altered the subject line for this discussions since I (ahem)
messed up and replied to the wrong thread about four messages
ago.
----- Original Message -----
From: "Logan Shaw" <[EMAIL PROTECTED]>
> Chris Tutty wrote:
> > Does anyone out there have a good example of multi-version
> > preference handling that includes upgrading prior preference
> > versions?
>
> I can tell you how I do it. I just have a struct, and when I need
> to add fields, I add them to the end. I have revision numbers for
> the struct, and an integer storing the revision number is part of
> the (earliest version of) the struct.
>
> Then I have a list of all revision numbers that ever occurred, and
> a big function that sets default values for all the fields added
> in a revision.
>
(snip)
> switch (revision)
> {
> case 20050101:
> prefsdata->oldfield1 = 42;
> prefsdata->oldfield2 = 99;
> break;
>
> case 20050203:
> prefsdata->newfield1 = 86;
> prefsdata->newfield2 = 77;
> break;
> }
>
Yup, looks familiar (my problem with passing code out is that
most of the reference code I've got is tied up in nasty NDAs).
I thought it might be useful to work on an open-source
example that would be useful to everyone because I've seen
a few projects where someone alters the preference structure
without realising the side-effects and it's only been caught
when (good) the test group mentions the crash after upgrading
or (bad) clients reporting crashes after upgrading.
> This system works OK, but every time I update it I worry that
> I'll make a careless error (like not adding a revision to
> gAllRevisions[]) and then I'm gonna have users out in the
> field with uninitialized fields in their preferences.
>
I had only intended to produce a good working example
but you're right, it would be good to find something efficient
that wasn't as fragile. It's just too easy for someone to look
at the prefs structure and say "Hey, that should be an Int32,
not an Int16" and boomb.
> I think if I were starting from scratch, I would write preferences
> out as a symbol table. Then at app start time, I'd read that
>
Hmm, do you mean an array with a coded symbol id followed
by a value? Or something different? Actually saving the whole
thing as a string in property=value;property=value;... format
with a read and write function would be safer, but a little
space hungry.
> Oh yeah, a totally different approach: just save each new
> piece of the preferences data in a separate preferences
> record. First piece is record 0, second piece is record 1,
> etc. Down side to this is that you'll end up with lots of
> records with just one field in them.
>
Interesting alternative. That means that you never upgrade
a version structure - if you leave it at that you'd also have
to reference the preference variables by which version
they belong to, or you have a single prefs structure that's
loaded from the multiple records.
I guess if you use a GetPref(), SetPref() pair of functions
the implementation gets a lot easier to hide. But that means
preference codes and having a lookup to return the value,
although I guess preference lookup isn't something you do
inside tight loops so robustness is worth more than speed here.
Chris Tutty.
--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/support/forums/
