Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Developer
Berrysoft
Posts: 143
Registered: ‎07-14-2008
My Device: Not Specified

Design - Persistent Store Best Practice(s)

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.

 

Comments?  Thoughts?

 

Patrick

 

Please use plain text.
Developer
Posts: 5,339
Registered: ‎09-20-2008
My Device: ***
My Carrier: ***

Re: Design - Persistent Store Best Practice(s)

[ Edited ]

AFAIK, according to one persistence long key a new object created.

 

Check this link

 

 

And there is a Blackberry Memory Best Practices Book

Message Edited by tbilisoft on 19-12-2008 11:40 AM
Please use plain text.
Developer
marchywka
Posts: 1,415
Registered: ‎07-30-2008
My Device: Not Specified

Re: Design - Persistent Store Best Practice(s)

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[]

Please use plain text.