Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Rewriting Records into RecordStore

 
dave taubler
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am trying to do something that should be simple, but am having the damnedest time finding an elegant way to get it done. In my MIDP application, I simply want to be able to allow a user to set preferences and, if desired, overwrite those preferences with different values later on.

Obviously I'd be using the RecordStore classes to do this. But my problem is that I don't want to *add* a Record everytime the user changes the preferences; I want to overwrite the same Record. This is the only way I can think to do it (let's say I am using "MyApp" as the RecordStore name):

- When user enters values for the preferences and clicks "Save", check to see if the RecordStore for "MyApp" exists.
- If the MyApp RecordStore does not exist, create it, and write the preferences' byte array as the first entry.
- If the MyApp RecordStore exists, use setRecord(0, prefsBytes, 0, prefBytes.length) ... since if the RS exists, I can assume that I've already created a preferences entry, and that said entry is the zeroth entry in the RS.

Is that really the only way I can do this? It seems a bit unelegant--and a bit iffy, since this approach relies on the assumotion that Record 0 (zero) will always be the preferences Record--especially considering that what I am trying to do would seem very common in a J2ME app.
 
Dave Butler
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's what we do - we deserialize preference properties from a specific RecordStore to a Hashtable, and then serialize from the Hashtable when saving (using DataStreams so all the key:value pairs end up in a single record). If the RecordStore doesn't exist - no worries, we just handle the null when trying to read a specific preference from the Hashtable.

We avoid any problems with having more than one record by reserving a specific RecordStore for preferences and using other RecordStores for non-preference data. We haven't yet found the need to specifically assert the presence of only one record...

All of this functionality sits in a small class that only exposes a getProperty(key), a setProperty(key, value) and a save() method, so the rest of the app has no idea there's a RecordStore involved. We initialize the preferences Hashtable when constructing the class during MIDLet startapp(), and make sure the preferences get saved during shutdown.

Hope this helps
 
dave taubler
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Dave (another Dave!),

Thanks for the response. I agree, that seems to be the only/best way to do it. In your case, how do you ensure that you always know where to find the Hashtable containing preferences? For example, do you always ensure that when you create a new RecordStore, the Hashtable always goes in as the zeroth item, or something like that? That's the part that seems a bit risky to me... but I guess it's unavoidable.

Sheesh, you'd think there'd at least be some name-value Property abstraction to use for persistence or something...
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree. It is a pain to replace.

I had a RecordStore that had 5 records in it, and I wanted to replace those, what I ended up doing was to clear out the RecordStore, then put in my new values. This worked fine for me.

I think if you wanted to find a particular record and replace just that one is a bit cumbersome in J2ME. This is because of how you iterate through the RecordStore, because getNextID or getNextRecord automatically move you up in the RecordStore, so you can't do both at the same time. Meaning if you get the next record to see if it is the one you want to replace, then you can't get that record number. You can go next and then previous to get that record number, but that is poor design.

I know that has to be a better way, and I think I had had one before, but can't remember it.

Good Luck

Mark
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic