Discussion Board

Results 1 to 4 of 4
  1. #1
    Regular Contributor WildHeart's Avatar
    Join Date
    Sep 2009
    Posts
    84
    Hello. Been a while. I wrote a new small app that involves the use of an rms. upon confirming user's identity, app moves from login.java to contacts.java. this file represents my contacts screen. in its constructor, the fields, commands, etc are initialized and at the end, populateList() is called. populateList() accesses the rms and displays all its records on that screen. say a list of names. i have other screens that perform functions like add and search. these have BACK buttons. pressing back takes me to contacts.java screen again where its constructor is called and hence populateList() is called leading to rms being accessed and a list displayed. this didnt feel right to me. having to access the rms everytime i wanted to go to my main screen.

    my friend told me that i can just access the rms ONCE and store the contents in a vector for example. then everytime i press back, i just display contents of the vector. this helps with search and sort. but if i do add, delete, update, then ill need to access the rms and vector for sure and change them according to what happens in these three methods.

    MY QUESTION IS (yes finally): which is better, his way or my way? assume the worst like 200 records with images too and 6 back buttons! :P i know that it's TO EACH HIS OWN when it comes to implementing functions and approaching a problem. but surely there's a standard regarding handling the rms itself. is it normal to constantly call the rms for data or not? should it b limited like he said? there has to be some recommended list or policy or rules of communicating with an rms. right?

    SECOND QUESTION: deleting a record in rms means no longer being able to use the id of that record since rms auto generates the IDs. regardless of the ID, it does look ugly (and possibly inefficient?) when the current ID is 200 yet there are only in fact 100 records. something needs to be done about the space in between yes? so my friend suggested we use vectors again. we copy contents of current store. delete the store. create a new one with the same name and store the contents there. this of course will be time consuming and possibly requires some processing power like my previous scenario. so i told him ill just have this 'clearing' method donet every 500 records. is this a good idea or i shouldnt care aout clearing/cleaning it up?
    Last edited by WildHeart; 2010-12-28 at 10:25.

  2. #2
    Nokia Developer Champion njzk2's Avatar
    Join Date
    Mar 2005
    Location
    Paris
    Posts
    814
    first answer :
    - separate your views and logic. have a separated unique class to handle your contacts that you call to create, retreive, update and delete your contacts. all your rms calls must be centralized there. once you have this, a good optimisation is indeed to load all your contacts once in a list, and then add and delete elements at the same time in your vector and in the rms. a different optimisation would be to store the elements that you display on the list screen in a separated record store that contains only the necesary parts and a reference to another record containing the rest to be displayed on the details screen. however, note that the optimisation must be done only if your performances tests shows that it is necessary.
    second answer :
    - don't worry about record ids.

  3. #3
    Regular Contributor WildHeart's Avatar
    Join Date
    Sep 2009
    Posts
    84
    hey njzk2 thnx for the reply. i already did the seperate class thing. my rms manager class handles all the functions of the rms: add search sort delete read write. when i press a command on a screen, it calls one of these methods which are in the rmsmanager class file. unless ur instructions are different. sorry if i got confused
    so you do agree with my friend. one question tho: when i use vectors, i get a yellow line indicating that vectors class is an obsolete class ever since the relase of jdk 1.x <= if it is obsolete then there has to be some newly added datastructure that replaced vectors. else why would they call it obsolete?
    thnx for thes econd method too. tell me something, when u say performance testing, u mean my own testing? like writing 50 records and testing then adding 50 more and so on? or sending my app to b java verified? i haventtried their site but i think they handle testing. it's like an ISO logo u no.

  4. #4
    Nokia Developer Champion njzk2's Avatar
    Join Date
    Mar 2005
    Location
    Paris
    Posts
    814
    The vector is the only list structure that exists in midp, so your IDE must be misconfigured, it should not tell you it is obsolete (also check the properies of your project for the source and build compatibility)
    as for the performance, yes, i mean your own testing.
    take the lowest end device you wish to run your application on, define an acceptable maximum quantity of data (a few hundred contacts is probably a good start), and run your application with that much data. Then it is up to you to see if you consider your application to be fast and reactive enough on each action performed by the user (launching, accessing a contact detail, coming back to the list). If you consider your application to be too slow, identify what process causes the lag, and find a way to make it faster.

Similar Threads

  1. Best practice for packing Flash Lite
    By TurfStudios in forum [Archived] Flash Lite on Nokia Devices
    Replies: 4
    Last Post: 2008-04-28, 12:40
  2. How can I put my application into practice?
    By samcqc in forum General Development Questions
    Replies: 1
    Last Post: 2008-01-10, 11:54
  3. XHTML common practice ?
    By nitsan1 in forum Browsing and Mark-ups
    Replies: 1
    Last Post: 2006-03-03, 10:24
  4. better practice for pushin and popping?
    By advocatee in forum Symbian C++
    Replies: 1
    Last Post: 2003-07-02, 04:24
  5. About the practice of AT Comands
    By li_xru in forum General Messaging
    Replies: 2
    Last Post: 2003-03-07, 18:42

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Nokia Developer aims to help you create apps and publish them so you can connect with users around the world.

京ICP备05048969号  © Copyright Nokia 2013 All rights reserved