12-19-2008 06:18 AM
Having read the API docs and manuals, I understand the basic examples laid out on the use of the persistent store.
However, in designing a real world program, I now wonder:
If I have a "game" which wants to persist three different "objects", i.e. Game, HighScores, & Options, I would then make each of those classes Persistable, but would I then setup three(3) independent persistent objects (i.e. each having it's own KEY)? Or, would I create one application-level persistent object (a so called root object)?
It seems to me that using a single root object means that I would then have to use a data structure (like the example Vector) to then add the above three objects to the store, and keep track of which object was at what index of the Vector, right?
If I create 3 persistent objects, then their persistence is more easily encapsulated within the objects persisting.
Does this understanding sound correct? Can this, in fact, be done either way? Is one way "better" than the other?
It also seems that I could have one Persistent Object, and just getContent() based on the KEY thus reduce memory requirements.
12-19-2008 06:39 AM - edited 12-19-2008 06:40 AM
12-19-2008 08:14 AM
I finally went with a few hashtables leading to a couple of keys/app but good flexibility.
Obviously, initial size can be important on memory waste but I'm a bit confused about the comment
in the best practices document on initial size leading to extra object handles as it
sounds like it calls Object() for each "empty" slot but I thought these were null
and the implementation would be somehting like an array of pointers.
Maybe I should check my usage in a simulator but if I had to replace hashtable,
I'd probably go with an Object