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 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
.(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’s proposal also requires that an IllegalStateException be thrown when MIDlets labeled MIDP 3 call these methods. Is it necessary that these methods throw an exception, possibly introducing instability in applications that have been “upgraded” to use some other MIDP3 APIs? Is it sufficient for notifyPaused and resumeRequest to simply return without doing anything? As these were only hints anyway, simply ignoring them is an option.

pauseApp's abstract qualifier will be removed so that developers no longer need to include an empty pauseApp method in their MIDlet class.

Why do some of us want to get rid of pauseApp?

This opportunity to eliminate pauseApp is an opportunity to decrease platform fragmentation. EG members seem to prefer to be rid of pauseApp and all the baggage it carries, regardless of what MIDP version a MIDlet is written for. Deprecating pauseApp for ALL MIDlets running on MIDP3 platforms would accelerate the elimination of this point of fragmentation. But it could break some existing apps. Is the value of eliminating this point of fragmentation greater the cost of rewriting some (how many?) applications that may be broken by this change (in other words, to paraphrase the great Spock, are the needs of the many greater than the needs of the few?)

What is the impact to VM/platform implementers?

Actually, because of the wide range of behaviors for present implementations, this is the key area where the EG wants to get feedback.

One aspect under debate is whether or not deprecation should apply to all MIDlets, or only those labeled as MIDP-3.0 MIDlets. For example, at least one implementation contains an LOC (Licensee Open Class - aka OEM class or proprietary API) that depends on the present pauseApp functionality. As explained to the EG, this implementation requires MIDlets to release resources provided by the LOC when pauseApp is called. This is consistent with the definition of pauseApp. Deprecating pauseApp only for MIDlets labeled MIDP3 would allow these implementations to retain this behavior for MIDP 2 content.

However, there is nothing preventing an implementer from ignoring this legacy behavior anyway. While the present proposal requires that MIDP 1 & 2 applications “continue to function as before", it’s impractical, if not impossible, to build a TCK test that can verify this. In fact, an implementation that formerly called pauseApp for MIDP2 implementations, when moving to MIDP3, could cease calling pauseApp altogether, and would still pass the TCK and be fully MIDPx compliant. Calls to notifyPaused and resumeRequest could simply do nothing, if these implementations never call pauseApp.

What is the impact to developers?

The EG seems to feel that the impact to developers will generally be positive. Many developers already have to deal with different implementations of pauseApp, and this change is simplifying.

Developers who are writing apps for many devices are probably leveraging porting layers. Whenever a new handset appears on their radar, a porting team adapts the porting layer to accommodate it. The porting teams should find the elimination of calls to pauseApp simplifying. (Question to porting teams: is this simplifying?)

Apps that may be most impacted are those written for devices that were hand chosen for a particular set of capabilities. A subset of these will depend on pauseApp to be called for some device-specific reason or another, that the EG is not aware of. The EG would like these developers to speak up and let us know how they are impacted.

For example, a recurring theme that I saw on the iDEN platform, was that some developers wanted to see their application return promptly to the display after a phone call completed. On iDEN platforms, these applications were using pauseApp as a signal that they were losing the display, and employed strategies such as repeatedly calling resumeRequest in order to get their application surfaced again when the call ended. This was a very device-dependent solution, enabled by this particular interpretation/implementation of pauseApp and resumeRequest.

Another example is that some developers use notifyPaused as a means of telling the implementation that they no longer need the display. However, this functionality is not defined nor guaranteed by the MIDP1/2 specifications, and in fact does not work in all devices. The lcdui package in MIDP3 will better define how applications can indicate that they no longer need a display.

What is the question the EG has for developers?

The question to developers is, how are you impacted, and would you prefer reducing fragmentation by

  • deprecating pauseApp only for MIDP3-labeled apps
  • deprecating pauseApp regardless of version, or
  • not deprecating pauseApp?

and why?

What are your opinions? What other impacts have we forgotten?


Roger Riggs' pauseApp deprecation proposal:

The function of MIDlet.pauseApp has been the source of confusion to developers and implementors and seems to have
limited value. Further its use by the AMS has been a cause of fragmentation across implementations.

On several occasions it has been suggested to deprecate use of pauseApp.

In order to more fully evaluate the changes and the impact the attachment contains javadoc with the updates needed to
MIDlet class and package documentation and diffs between the proposed javadoc and the previous javadoc. Please read and

For convenience the proposal is:

  • For backward compatibility with MIDP 2.0, the function of pauseApp cannot be removed completely. MIDP 2.0 applications
    must continue to function as before.
  • Changes (for MIDP 3.0 MIDlet suites only):
    • The pauseApp method MUST not be called.
    • The pauseApp method will be changed to remove the “abstract” qualifier so MIDlet suites do not need to provide an
      empty pauseApp method.
    • The notifyPaused and resumeRequest methods are modified throw IllegalStateException (only for MIDP 3.0 MIDlets)
    • However, the package documentation must retain a complete description of the PAUSED state and required behavior for
      MIDP 2.0 MIDlet suites.
    • Also included in the diffs; deprecate of the MIDlet.checkPermission method in favor of AccessController.
      checkPermission (for MIDP 3.0 MIDlet suites only).
Related Topics >>