Welcome at » A few facts about PasswordKeeper

A few facts about PasswordKeeper

We were thinking about which application seamed the best choice for creating the Quick Start Guide and the sample application.

It should be not too big, but useful, and make use of a good deal of the platform.

It should also be helpful to compare the effort needed to create an application from scratch and using our framework.

So we finally choose PasswordKeeper, a KeePass like application that has J2ME version at source forge (KeePass for J2ME).

Here are a few quick facts about the size of the project, that I think that speak aloud:

UPDATE: the table above represents some statistics about the SOURCE code of both applications, not the final .jar size of the application itself. We are trying to picture the development effort.

PasswordKeeper KeePass for J2ME
Number of files 20 (5 java, 1 XML for the views, the rest resources) 71
Size in Kb (approx) 94 (includes images) 237
Lines of code 2326 (807) 6835

The number of 807 between parenthesis is the approximate number of lines of code that are actually part of the application and not of the template, so the ones that you really create.

Have some comments?

BlogLines Digg Facebook Google Google Reader Yahoo! MyWeb Newsgator Newsvine reddit SlashDot StumbleUpon Technorati

10 Responses

  1. elisoj

    I have a question about the table above. It states that PasswordKeeper is about 94 kb, but the .jar is 248 kb. KeeSafe.jar again is 124 kb, not 237.
    Could it be you accidentally changed the two numbers?

  2. Narciso Cerezo

    Hi elisoj,
    I have edited the article to make it more clear.
    We are talking about source code size, not application size.
    The point is measuring the development effort.
    At some point we will perform another round of code size optimization, but we are not very concerned by that.
    Everything has a price, having a J2ME relational database is great, but might not be the solution for everything.
    Phones that have enough RMS memory usually have a maximum jar size of 512Kb, 1Mb or unlimited. So there’s no point for OpenBaseMovil applications to be very concerned about the 128Kb limit.
    The purpose of PasswordKeeper is to show how to create an application, and the development effort it requires compared to “traditional” J2ME application.

  3. elisoj

    I see. Right now, I think that a J2ME database is quite handy, I am thinking about an application that needs an n:m database model and I was wondering whether to
    a) use files with JSR 75 to accomplish this
    b) write some sort of “database” to operate on RMS
    c) don’t do it

    Now, c) has been substituted with your framework :-) I have to get up to speed with your template and then I will give it a shot. Sadly, my phone seems to have only 1 MB of space for applications (then I have to move some to SD Card) and RMS can only hold 144 kB. But with compression in RMS, maybe it will work anyway.

  4. Narciso Cerezo

    Well, according to the device specs at Forum Nokia your phone has 70Mb of internal memory and a SD slot for up to 2Gb.
    As I told you, I tested back a while a 6131, which is basically the same model internally (in fact if you take a look at the table of devices at the Java Verified program, the Nokia 6131 is the head model for others that include the 6233 (so if it works in a 6131 one can assume safely that it will work in a 6233).
    The 6131 had the current maximum for S40 devices, 262Kb per RecordStore, and I think that no limit in the total available space for Java applications.
    EDIT: if you manage to get to “tools -> diagnostics -> device information” with PasswordKeeper it will give you the information found by the DeviceInfo class, which includes the detected maximum size for a RecordStore. It can be fake if you just have less than 262Kb available as a whole.
    In your case it will give you up to 70Mb when installed in the phone memory and up to 2Gb when installed in the memory card.
    As it uses compression in this devices, the ratio can vary a lot depending on the circumstances, but I think that it could achieve between 30% and 50% of compression ratio.
    Is I have told, we are planning for the very near future a new version of the storage library that will perform not just record multiplexion but also file splitting to overcome that barrier. In your case it would end up with just a limitation of a maximum RECORD size of 262Kb. It will be absolutely transparent for your application, but that still has to wait a little.
    And take into account that data is stored in binary format, so it occupies less space. You can take a look at the Table class to see how it calculates the maximum size for a row given the table definition.
    I will put a sample report of storage use. In the commercial (hosted) version that has the sync engine, the devices send errors and memory usage reports to the server.
    The following is a list of RecordStores with their size in bytes for a database with about 400 customers, 1400 products, 8000 prices and about 5000 presentation units. As you can see, only the prices and presentation units tables are over 262Kb:
    sys_store_info: 4227
    sys_appstate: 2967
    sys_devinfo: 451
    sys_preferences: 1189
    rix_language: 94522
    sys_compiled_views: 18103
    sys_login_info: 511
    preventa_db: 10955
    preventa_mix: 473
    taxes: 722
    si_taxes_id: 892
    units: 969
    si_units_id: 1092
    categories: 8139
    si_categories_id: 3816
    ix_cat_parent: 1519
    payment_types: 544
    si_payment_types_id: 872
    customer_categories: 879
    si_customer_categories_id: 972
    routes: 3010
    si_routes_id: 1392
    user_counters: 686
    si_user_counters_id: 892
    order_types: 703
    si_order_types_id: 892
    customers: 49317
    si_customers_id: 5788
    ix_cust_name: 8978
    ix_cust_cust_id: 5971
    ix_cust_route: 1692
    ix_cust_nif: 5379
    ix_cust_fiscal: 9780
    category_discounts: 7498
    ix_catdis_pk: 2802
    si_category_discounts_id: 2592
    products: 199541
    ix_prod_custid: 31932
    ix_prod_catid: 7328
    si_products_id: 36048
    ix_prod_name: 62615
    presentation_units: 290045
    si_presentation_units_id: 107036
    ix_pu_product_id: 45468
    work_sessions: 3210
    si_work_sessions_id: 1552
    cust_p_hist: 136710
    ix_cph_pk: 37465
    si_cust_p_hist_id: 34392
    ix_cph_cid: 8216
    ix_cph_pid: 14648
    prices: 505783
    ix_prices_prod_id: 61324
    ix_prices_prod_custcat: 204206
    si_prices_id: 217308
    payments_tmp: 6413
    si_payments_tmp_id: 1832
    all_routes: 18017
    ix_allroutes_name: 8296
    si_all_routes_id: 8812
    product_discounts: 14440
    si_product_discounts_id: 4656
    ix_proddis_pk: 5048
    orders: 22296
    ix_order_cid: 2728
    ix_order_otid: 1496
    si_orders_id: 5208
    order_items: 101304
    ix_order_id: 6616
    si_order_items_id: 14840
    stocks: 122235
    si_stocks_id: 36480
    ix_stocks_prod_id: 36480
    pend_payments: 8838
    si_pend_payments_id: 2812
    ix_ppay_custid: 1980

    The report is a fresh one, of this morning, of a working device that is processing orders and more with our commercial application bmSales.

  5. elisoj

    Hello Narciso,
    I’ve seen the specification for the 6233 before, but nevertheless: When I wanted to install PasswordKeeper, it told me that no space is left and I will have to delete stuff first (with less than 1 MB in program directory). But since moving applications to SD seems to work, 1 MB of maximum jar size will be enough for one hell of an application :-)
    Device Information of Password Keeper told me yesterday of 144 kb for a RecordStore, which is exactly what my own test said. But, as you mentioned, this could be faked. I will change my test to see how much space is available with RMS multiplexing.

  6. Narciso Cerezo

    That message means that you are using almost your 70Mb of storage with other things (mp3, photos, etc).
    Using the SD makes things a bit slower, at least with S60 phones, but it has plenty of space available.
    And with 1Mb you can create really complex applications, to give you an idea, our sales force automation commercial application bmSales is about 450Kb in size. And it has a LOT of functionalities and is rather complex.

  7. elisoj

    Hi Narciso,
    strange thing: When it asks me to delete stuff, it gives me options where to delete from. All of them, together with apps, themes and messages, are 4,5 MB in total. All mp3 and photos are already on the SD, so I don’t know where to delete from.
    But forget that, I found something more interesting: I can have multiple record stores (number depends on the amount of memory left, so no limit in the number yet), but each store will always only hold 142 kB. That’s a possible way to test for size limits and make sure it’s not because of memory shortages:

    1) If I can have at least 2 RecordStores where the first one has size x, it is likely that x is the limitation for the size of one record store.

    2)If I can have only one record store, this is
    a) because this one has unlimited size until memory is full OR
    b) it is limited, but free memory is below this limit.

    This way, a test class should be able to make real statements about case 1) and maybe some guessings about case 2).

    P.S. Don’t know if you wanted to read that boring stuff, but I wanted to let you know anyway ;-)

  8. Narciso Cerezo

    Hi elisoj,
    It’s not boring, we appreciate very much all your feedback.
    You can try to reset the phone to the factory defaults (make a backup first of contacts, calendar, etc) it may release memory that is now “lost”. That kind of things happen.
    With S60 phones there are some useful codes and tricks to perform soft and hard resets, formats, etc. I don’t know if there’s something similar for S40, but there must be a “reset to factory settings” option somewhere in the phone menu.
    As for the detection of record store sizes and so on, take a look at the source code of DeviceInfo. It makes many things to detect max sizes and also a bug that I long reported to Nokia (a flash memory leak). But it is not perfect.
    In fact, today I have changed my E70 for a E90 (what a phone! or I should say ultra-portable computer). I’ve tested PasswordKeeper with the E90 and it works fine, but the DeviceInfo class reports that memory management is bogus and that it does not have the memory leak bug (that might not be the case as it says that it is bogus).
    One thing that happens from time to time is that it would detect a size limit, even a big one like 128Mb, and if you use the “force” memory info that calculates everything again it will report that there are no limits (the right answer for S60 phones).
    Please, feel free to play with the DeviceInfo class, and if you get a better result with your phone we can test it with other models and include it in future releases.

  9. mkamthan


    I am using Netbeans 6.0 IDE for running the PasswordKeeper application.
    It compiles properly and when I run it, it launches the emulator but on launching the application the error it displays is:
    Unable to create MIDlet main.passkeep.PasswordKeeper
    java.lang.ClassNotFoundException: main/passkeep/PasswordKeeper
    at com.sun.midp.midlet.MIDletState.createMIDlet(

    Can anybody please help me out.


  10. Narciso Cerezo

    Hi mkamthan,
    You should post support requests at the forums.
    It seems to me that you are trying to run it from the jad file, but it is not pointing correctly to the jar file.
    The jad and jar should be in the same folder, and the jad should just contain the name of the jar, without any path.
    It could also be that you are applying obfuscation to the jar but it is not properly set and it is also obfuscating the midlet (changing the class name). To check that you can open the jar with any zip manager such as winzip or file-roller and check if the folder main/passkeep exists and contains PasswordKeeper.class.

Leave a Reply

You must be logged in to post a comment.