• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Few questions related with MIDlet API

 
Faisal Ahmad
Ranch Hand
Posts: 355
Chrome Java Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!
I have few questions related with MIDlet interface.
The API documentation says that:
startApp(), pauseApp() and destroyApp() along with notifyDestroyed(), notifyPaused() and resumeRequest() are methods that handle MIDlet's state changes. Further, it also says that the state change is not considered complete until the state change method has returned. That means, for eg. the until the startApp() method is returned we can't be sure that MIDlet has entered the Active state. Is the same principle applicable to notification methods as well? How can we know that these methods are 'returned'? What does 'method return' actually means?
Awaiting an early reply. Many thanks for your help!
Cheers!
 
Sathya Srinivasan
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Faisal Mohammed:

startApp(), pauseApp() and destroyApp() along with notifyDestroyed(), notifyPaused() and resumeRequest() are methods that handle MIDlet's state changes. Further, it also says that the state change is not considered complete until the state change method has returned. That means, for eg. the until the startApp() method is returned we can't be sure that MIDlet has entered the Active state. Is the same principle applicable to notification methods as well? How can we know that these methods are 'returned'? What does 'method return' actually means?



A quick correction. From the API (page 439 in MIDP 2.0 spec):
Active: The MIDlet is functioning normally. This state is entered just prior to the AMS calling the MIDlet.startApp() method.


That said, start, pause, and destroy methods are called by the AMS. This would happen when the AMS decides that the application should start, stop, or pause (possibly because a call came through).

On the other hand, notify methods are ways for the application to let the AMS know that it is going to another state. The most common scenario is when the user clicks on the "Quit" option within the application. In such a case, the "Quit" command within the app would clean up all its resources and then notify the AMS that it is ready to be killed by sending the notifyDestroyed() method. This way, there is a clear communication from the app to the AMS.

Notify methods are essentially calls that would be processed by the AMS as soon as it can get to it. In most cases, it's instantaneous.
 
Faisal Ahmad
Ranch Hand
Posts: 355
Chrome Java Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Satya, many thanks for your reply!
Still I'm a bit confused. See below the statements:

From MIDlet package summary:
Active state. This state is entered just prior to the AMS calling the MIDlet.startApp() method.
That means, the MIDlet has entered the Active state even before AMS calling the startApp() method.
Now look at this statement from the MIDlet package summary:
The application management software has decided that it is an appropriate time for the MIDlet to run, so it calls the MIDlet.startApp method for it to enter the Active state.
Which means, unless startApp() is called by AMS, a midlet can't enter the Active state. So, did you see the difference?
And now comes another statement from MIDlet class summary:
The methods on this interface signal state changes. The state change is not considered complete until the state change method has returned. It is intended that these methods return quickly.
Which means, the MIDlet is not said to be Active unless its startApp() method is returned/completed. Again, difference?!
And here is another one from the MIDlet class summary:
startApp() Signals the MIDlet that it has entered the Active state.
Here, it should have been written: Upon successful completion of this method the midlet enters the Active state.

After reading the above statements from API documentation, my question is - When exactly does a midlet enters Active state?

Many thanks in advance for clarifying my queries.
[ November 17, 2008: Message edited by: Faisal Mohammed ]
 
Faisal Ahmad
Ranch Hand
Posts: 355
Chrome Java Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another question after reading the API docs:
notifyPaused() method is used by the midlet and it Notifies the application management software that the MIDlet does not want to be active and has entered the Paused state.

My conclusion after reading the above sentence:
The midlet has entered the Paused state by itself. And it is informing the AMS that it has entered the Paused state.

My question:
The midlet has entered into Paused state but I don't want the midlet to inform AMS that it has entered into Paused state. Can I skip calling notifyPaused()?
If notifyPaused() just notifies/informs the AMS about the current state of midlet then in what way midlet has entered Paused state?

Reply appreciated.
 
Faisal Ahmad
Ranch Hand
Posts: 355
Chrome Java Redhat
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, here I understand a little more after some playing with code...

notifyPaused() does 2 things for a midlet:
1. gives up the resources used by midlet, makes the midlet quiet and places it in Paused state.
2. informs/notifies the AMS the state change of the midlet.

Similarly, notifyDestroyed() does 2 things for a midlet:
1. Cleans up and releases all the resources that are being used by midlet and places the midlet in Destroyed state.
2. informs/notifies the AMS the state change of the midlet.

And above all, unless these methods successfully return/complete there is no guarantee of the state change. Usually, these methods will return/complete successfully. Finally, these methods are 'final'. So, their functionality (discussed above) can't be substituted by our logic.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic