How much RAM would a typical Form object uses up?
Should i always free most of the gui components to release ram when my midlet is put into "paused" state?
Lots of thanks.
Message was edited by: dextml
The form object doesn't use a great deal of ram, it's what you put on it that might. :)
If you have a form that has several components that take a while to build, such as a choicegroup which needs to build it's selection list from RMS, it might be good to leave that component constructed due to the time it will take to rebuild on resuming your midlet.
Which brings me to the real concerns you should look at, construction time on startup.
While there is a special pause method that is called, there is not a resume method, only the startApp method. So if your construction time for your screen is not that long you can reduce the amount of logic in your startApp method by just rebuilding everything.
What you have to do if you need to keep complex or slow gui components around for startup, is rebuild what you need and make sure that the event/command hooks are re-established. Some devices can cause issues if you leave the command and event listeners, intact when the midlet is in pause mode, so these should be removed in pause and rebuilt in startApp, to avoid your midlet missing actions or dropping the ability to respond to keystrokes.
thanks for your info. it's helpful.
I really don't need to care alot about thee memory issue? consider nowadays cellphones vary a lot from one user to another. And,... the cell phones also take great discrenpancy amongst different countries. J2ME is a good platform, but sometimes some mobile phones does not give FULL support to every documented apis which further narrows j2me's ability.
how u think about this?
True memory is becoming less of an issue. However as you point out every phone, country, and provide inflict different restrictions on JavaME, and thus you could end up on a device that had a lot of memory (storage) but not a great deal of memory (ram). So unless you are doing SVG, or Image /graphics intensive apps, or need to load up large DOMs to parse through, memory can drop down a notch in importance.
- climbs onto soapbox -
As for my opinion (which is all it is, my opinion) that phone companies / manufacturers are ruining the JavaME market with their unrealistic restrictions, and faulty implementations of the JSRs and Java APIs, and we need Sun or some 3rd party body to have the power to bring in all of these incompatibilities into line. Also the issue that Sun has not made companies publish in more detail what JSRs and even the fact that Java is on the device is ridiculous. You don't see Windows Mobile devices keeping quiet about what device, level and .net support they have, but yet I can not go to a Wireless phone service provider site and find out if a phone has Java or will support the WMA JSR-120 or 205. Not to mention even if the phone does support it, there is no guarantee that the service provide will allow that support to be active.
Without JavaME getting some major support soon, I fear it will get eclipsed by other technologies.
Sun should take lessons from Palm, who was the undisputed leader in PDAs, and is now struggling to stay in the game. Without innovation and a plan to stay up with the market you fail.
- steps down from soapbox -
Thanks a Mega :)
I'm not experienced with mobile development, so i care about every step i made.
PS. actually, there IS some site provides search on devices base on the Java feature they support. Example is the nokia forum.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.