Skip to main content

Message from MIDP3: Goodbye pauseApp!

Posted by sean_sheedy on June 13, 2007 at 9:13 PM PDT

[Clarification and developer bias: The EG is providing finer grained notification functionality such as DisplayListener (see the EDR javadoc) that will move some of the platform-dependent functionality overloaded into pauseApp (and NOT defined in the MIDP specification), into platform-independent APIs whose behavior IS defined by the specification. In other words, if the capability provided by pauseApp is better provided elsewhere, isn't the natural result that can we reduce the confusion and fragmentation around pauseApp by making it a no-op (as implementations like Nokia's already do today?)

So the question to developers could be, what platform-specific stuff are developers doing with pauseApp that MIDP3 may need to accommodate if pauseApp is never called?

And if that capability is provided elsewhere, pauseApp's remaining function is to allow the environment to notify the MIDlet that the MIDlet is about to lose CPU time. Do we, as developers really implementations be able to "pause" us, to stop our threads, given that today's platforms are powerful enough to allow them to get at least some CPU time? What reasons might we want to keep the Paused state around? ]

To help reduce fragmentation, the MIDP3 expert group wishes to deprecate MIDlet.pauseApp, and wants your input - especially if you are negatively impacted. The idea is not to remove the API, but simply require that implementations never call it, and eliminate the need for developers to provide an empty pauseApp method.

There are several questions that the expert group would like the community to weigh in on. They are:

  1. Are there any VM/platform providers who will be severely impacted by this change? That is, is pauseApp woven into their implementations so deeply, or required by the nature of their platforms, that not being able to signal a MIDlet with pauseApp would create fundamental issues?
  2. Are there any software developers whose applications would require fundamental and expensive changes in order to run in an environment where pauseApp is never called?
  3. Are there any other impacts the EG should consider?
  4. Should this apply regardless of whether or not the MIDlet is designated MIDP3? That is, should platforms be permitted to provide legacy pauseApp functionality to MIDlets indicating MicroEdition-Profile less than MIDP-3.0?

I suppose we're not expecting a huge outcry of opinion on this, but if you have something to say about it or are impacted, definitely say so. You can leave a comment here and/or email the MIDP3 EG at jsr-271-comments@jcp.org. This post is rather long, so if something jumps out at you, comment on it; don't feel you need to read or understand the whole thing before doing so.

A copy of the proposed API javadoc can be found at
http://seansheedy.com/standards/midp3/pauseApp/MIDlet.html
.(You can scroll to the bottom of this post for the deprecation proposal from Roger Riggs as posted in the MIDP3 artifacts tracker.)

Why does pauseApp exist in the first place?

One of the reasons this API exists is to provide a tool to help applications deal with platforms that cannot concurrently run MIDlets and handle key native events such as phone calls. By calling pauseApp, an environment informs the MIDlet about entry into the PAUSED state. What the platform requires of a MIDlet is not defined in MIDP and is platform dependent. In the PAUSED state, a platform may deny a MIDlet all CPU time, or require that it give up resources so that the platform can do other things - or none of these. pauseApp was designed to give early implementers one less excuse for not including MIDP in those early mobile devices!

Why is pauseApp no longer considered technically necessary?

As Moore's Law has made devices more sophisticated, the need for this accommodation has diminished. Platforms are able to perform multiple tasks without completely shutting down MIDlets. The possibility of errant MIDlets forced designers to place the responsibility of releasing resources on the implementation, not the application. APIs now provide listeners to help MIDlets learn about and manage the acquisition and loss of resources. MIDlets are expected to register listeners for notification of events that impact them. Essentially, pauseApp is no longer needed in MIDP 3.0. However, this dialog arises out of the MIDP3 EG's concern about backwards compatibility issues.

How do various platforms handle pauseApp today?

pauseApp has been a source of confusion and misinterpretation for both implementers and developers. The implementations of pauseApp are quite varied. On some devices, pauseApp signals that the MIDlet has a limited amount of time to release resources before losing all CPU time. In others, pauseApp is called when the system is about to lose the display and keypad to some other process like an incoming call, but all threads created by the MIDlet continue to execute. Finally, some implementations never call pauseApp throughout the life of the MIDlet!

What else is impacted?

The deprecation includes resumeRequest, which is defined as merely a hint from the application that it be resumed from a paused state. resumeRequest also has varied implementations and generally cannot be relied upon across platforms - sometimes it does nothing, and sometimes it is obtrusive. With pauseApp eliminated, resumeRequest is no longer necessary. notifyPaused also has little meaning.

Roger

Related Topics >>