Why is startApp() used instead of the constructor in Java ME applications?

Question

A lot of Java ME tutorials use the startApp() method for creating and initializing objects and the constructor is left blank. However, the startApp() method is also invoked when the MIDlet resumes from a paused state. This causes all the objects to be re-initialized and any changes made are lost.

I have also noticed that the netbeans IDE, in its auto-generated code, uses many if(object==null) statements in startApp() to check if the object was created earlier.

Would it not make sense to simply do all the object creation and initialization in the constructor itself? Is there any reason for not doing this?

Answer 1

This is in part about understanding the MIDP threading model.

What thread the MIDlet constructor is called in depends on who developed the Java Virtual Machine on the phone.

Developers have a tendency to rely only on what the MIDP specification says in that area, which is how startApp, pauseApp and lcdui event handling should behave.

However there are only a few cases where this is important.

The second aspect to this issue is software developers trying to free as much resources (memory, file handles, sockets...) as possible when the MIDlet is paused.

Again, there are cases when MIDlets should hang on to some resources even when paused but you really need to think about what you're doing (and understand it better than casually) when coding that kind of behavior.

It is also worth remembering that some phones always keep the JVM process running. When they also have a JVM that doesn't support class unloading (as is usual in a J2ME world), this means that static variables can remain in memory even after the MIDlet has been completely destroyed.