×

Discussion Board

Results 1 to 9 of 9
  1. #1
    Registered User
    Join Date
    Oct 2003
    Posts
    22

    New bee quest: Persistent Storage and Record Store

    Hi, Please guide me how to feed the Record store in MIDP?.
    I means how to create the content for Database but don't have to use the addRcord methods calling from the MIDlet code. This is a tedious way for a DB have thounsands items and it means we embed the content of the Database on the code already. Moreover, the source of the Database shold be created some where outside the MIDlet suite by another application .

  2. #2
    Registered User
    Join Date
    Jul 2003
    Location
    Finland, Tampere
    Posts
    1,113
    There is no other way.

    If you want it to have some "initially filled" data, you'll have to supply it either in your code, or JAR file resource, which will be loaded by your code, or with web resource, that your code will read. Also you can get it by Bluetooth.

    At the first app launch you can get the data and populate the database.

    P.S.
    RMS DB has quite limited size if you think of some huge amount of data

  3. #3
    Registered User
    Join Date
    Oct 2003
    Posts
    22

    New bee quests

    Thank, junior member.
    Embed the DB in code is may be the best way because MIDlet suite size is up to 64 kB while Record Store size is 20kB, for my Nokia 6610. The point is how to reduce the amount memory consumption of the remainning code.

  4. #4
    Registered User
    Join Date
    Jul 2003
    Location
    Finland, Tampere
    Posts
    1,113
    If you don't need to update data, you don't really need RMS, just use JAR file resource(s) as a database.

  5. #5
    Registered User
    Join Date
    Oct 2003
    Posts
    22
    Hi, doctordwart,
    I wonder between 2 choices as you mentioned: embedding data in code or storing it as resource in JAR file.
    Let's say we need to store a text data: "abcscs" for some purpose.
    With the first choice, I will declare an array directly in my code:
    String[] A={"A", "B", "C","S","C","S"};
    With the second choice I will copy this string to a foo.txt file and store it as resource the in JAR file. Of course, later I will retrieve it out and may copy to a new array in program.
    The second choice is obviously slower in access, however my question is which way will save the size of MIDlet suite in total ? Or they are still the same because eventually, they are baked by the obsfucator ?
    Bests,

  6. #6
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395
    The problem with something like:
    Code:
    String[] A={"A", "B", "C","S","C","S"};
    is that the compiler expands it to:
    Code:
    String [] A = new String [6];
    A [0] = "A";
    A [1] = "B";
    A [2] = "C";
    A [3] = "S";
    A [4] = "C";
    A [5] = "S";
    For six strings this is probably not a big deal, but if you had, say, 100, it's a lot of code! At that point, storing the text in a file becomes worthwhile. You need to be saving enough space to cover the code required to read the strings from the JAR.

    Graham.

  7. #7
    Registered User
    Join Date
    May 2003
    Posts
    4

    Use a HTTP connection.

    When the app is first started, you could make a http connection to a server somewhere, and populate your database this way....

    Bear in mind that the size of the database must be <=20K, so storing 1000's of records may be out of the question.

  8. #8
    Registered User
    Join Date
    Oct 2003
    Posts
    22
    Thanks, my friends,
    I am totally stick to the solution of storing data as resource files in JAR. RS is a decoration for Http session, game marking so on.
    I am implementing techs to process every kind of data just in byte[]. Searching is the most frustrating thing . Sometime I can not load all resource into 1 array then do Quick Sort because the constrain of Heap.
    Why MIDP can not implement RandomAccessFile class? In the situation right now, I 've only 1 choice of sequential searching plus some naive Hashing.

  9. #9
    Registered User
    Join Date
    Jul 2003
    Location
    Finland, Tampere
    Posts
    1,113
    Byte records probably are the most simple to implement.

    Have a look at RecordComparator, and RecordFilter interfaces. They can make RMS do sorting for you. Probably in some not very naive manner

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×