Is it possible to read(or locate) a RMS file written by a Midlet application? Also, how can I determine where the record store will be saved??
Is it possible to read(or locate) a RMS file written by a Midlet application? Also, how can I determine where the record store will be saved??
Yes, if you know name of the RMS created by one midlet, you can write another midlet to access it; if the AUTHMODE_PRIVATE is not set by the midlet that created it i.e. if AUTHMODE_ANY is set..... see the javax.microedition.rms.RecordStore API documentation for more details.
Record stores are created in platform-dependent locations, which are not exposed to the MIDlets. The naming space for record stores is controlled at the MIDlet suite granularity. MIDlets within a MIDlet suite are allowed to create multiple record stores, as long as they are each given different names. When a MIDlet suite is removed from a platform all the record stores associated with its MIDlets will also be removed. MIDlets within a MIDlet suite can access each other's record stores directly. New APIs in MIDP 2.0 allow for the explicit sharing of record stores if the MIDlet creating the RecordStore chooses to give such permission.
thanks,
~Amitabh
read developers.sun.com/mobility/midp/articles/databaserms/
thanks,
~Amitabh
Thanks a lot that link will help me , one thing i want to know is can i atleast make a list of all the RMS that exists in the device (phone or memory )(not only the RMS cretaed by my application , RMS created by other applictaion can i know those RMS names ) ???
if yes please guide me how to do that ???
You cannot get the list or names of the RMS files stored on the device, because its not present in the open filesystem as it is.
Check Appdb folder of your emulator you will see somefile names they still have sometype of realtion with the RMS name given by j2me app... but on real device these are stored in System's private path and may not be accessable.
thanks,
~Amitabh
From J2me we dont have control on the path where RMS is craeted as per default implementation of MIDP RMS..... workaround could be to create your own RMS implementation using (file's) FCA JSR-75 and then you can place the files in any desired path which is reachable by J2me.... you can even name all the your rms db files with extention of .rms
thanks,
~Amitabh
This can be done, only if you develop your own implementation of rms using FCA API JSR-75 and do not use rms implementation of MIDP i.e. do not use - javax.microedition.rms.* package.Once you have your own implementation you can play around it as you wish... to add new features of auto-backup etc.So .rms is a valid extension right?? so that we can create a new RMS in our desired path with the name along with the extension .rms and transfer the data of old rms we can do this right???
thanks,
~Amitabh
Simple... give a data backup feature in your app; that reads your RMS record by record.... store it line by line in a flat text file on the open filesystem of the device.
Also provide a data restore option in your app; that can read the lines of text from your backup files (from open filesystem) and store them in RMS as records.
thanks,
~Amitabh
Yes you can store RMS records in filesystem after encrypting it and encoding it in base64 so that you can seperate each record by \n or the next line characher (if you cross the limit of max amount of data or lines in the text file) you can create 1 more backupfile and name it like backup001,backup002.... and so on (and takecare of all of them in restore process),
or
if you may try can export all data over network connection to your server side database and restore it from there.
thanks,
~Amitabh
thanks a lot for all the information i will try based on information that u have given me an again thanks a lot if i get a dout i will agin put a question here ok
by the way how to encrypt the string and also retrive taht de-encrypt the data if u have any related code please provide me .
but thanks a lot for all these information it helped me a lot many douts i had u haev cleared me most of it thanks alot.