Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
08-09-2010 12:25 AM
I am playing around with data persistence on th BB (4.2+) APIs and have a general question regarding the best/recommended way to use it, performance-wise amongst the following two options for the scenario:
SCENARIO: My app manages about 4 entities ("models", if you will in MVC-talk) of information.
Option 1: Create a class for each model (extending Vector) with a PersistentObject and keyfor each .
Option 2: Create a single Hashtable or Vector, which will be a single instance of PersistenObject, and it will have the 4 references to the models/entities.
Maybe this is not a big deal, but I'd like to know which of these two approaches is better. Or is there a third?
What happens if the scenario involves the models growing to a few thousand entries each?
Solved! Go to Solution.
08-09-2010 01:18 AM
There is no major difference, I'd probably go with second approach (less PersistentObject, less code for attaching to them)
What data do you keep inside the "models" ?
08-09-2010 09:32 AM
They are normal domain-based clases like
private Integer id;
private String fullName;
private Long dateOfBirth; // Long as Date
private Integer heightInInches;
private Integer weightInPounds;
private String gender;
My curiosity comes from not knowing how the .commit() method goes about persisting the objects.
Does it traverse ALL references every time? Or does it keep a list of "uncommited" objects?
If it's the former, then having one PO per model is mode efficient as only the modified container would be traversed. Otherwise, #2 is more practical.
08-09-2010 09:52 AM
Here is my understanding about PersistentObjects.
Once you have "attached" and commited an object to PersistentObject, this object and all other objects that are referred by it will automatically become persistent.
i.e. once you have done this:
Hashtable conf = new Hashtable();
PersistentObject po = PersistentStore.getPersistentObject(Constants.GUID
all calls to hash.put() will automatically persist the new data - there is no need for subsequent calls to .commit()
Internally there is some copying of changed data between two different Flash memories (or something like that - I have never had need to find out what's happening behind the scene) - but IMO it will be the same overhead no matter if you use several separate Persistent objects, or just one.
08-09-2010 09:54 AM
ok, I found a bookmark that you may consider interesting. It also contains links to a couple of KB articles
Persistent objects are stored in flash memory. When you update a persistent object, it is copied to RAM, updated and wrote back to flash. Once it has been successfully stored the flash memory allocated by the original persistent object (that you "overwrote") is made available for garbage collection.
If your object will be frequently updated you may want to consider breaking it up into multiple smaller objects. I also recommend having a look at object grouping. Please refer to the "Low memory management in the BlackBerry Java Development Environment" and "Garbage collection in the BlackBerry Java Development Environment" white papers found here:
08-09-2010 02:41 PM
Couple of things.
1) I believe this comment from Plato to be incorrect:
"all calls to hash.put() will automatically persist the new data - there is no need for subsequent calls to.commit()"
It is my understanding, that because the object is shared, it looks like this happens, but in fact, unless you do a commit, you can't be 100% sure that the data has been written to flash. However, when a commit is performed, the processing will commit all outstanding data, so your data could be committed by another application's commit (and vice versa).
2) In answer this this comment:
"Does it traverse ALL references every time? Or does it keep a list of "uncommitted" objects? "
My understanding and experience suggests that only uncommitted objects are committed. For example, I have tested with a Vector containing a large number of elements. If I update one element, and then commit, the commit is extremely quick. If I update a lot, then commit, the commit takes longer.
One final point, I agree with Simon, I would go with a single Hashtable or Vector. One other consideration is synchronization, you may wish to break this up to make synchronization easier, if you have multiple Threads that need to synchronize on different parts of this one Object.