Sean Sheedy's Blog

Message from MIDP3: Goodbye pauseApp!

[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?)

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.

Comments

• Interesting question is if you run the MIDlet in parallel with the phone call, who will be listening the caller's voice and receive keyboard notification (DTMF) - call or MIDlet? Can caller push keys for IVR at the same moment when he is playing MIDlet game? Is it any standard for that?
  

  Posted by: sergev1708 on September 07, 2007 at 06:59 AM

• Hi Sean, thanks for the response.

  I'd agree that being loose in 1.0 and 2.0 helped jme adoption. I don't think we can rely on the Network Operators at all for JVM testing - there just isn't the will there. If things have to be tested it needs to be at the TCK level.

  The screen listener doesn't always work(1.0/2.0) - its a "sort-of" workaround on S/E devices - except if you look at the showScreen/hideScreen messages its not unusual to get 5 or 6 - and then they're not always paired.*

  ... so I guess we need a definite "VM is being suspended" type message - Kim Daniel Arthur (Glu) had a good suggestion on the KVM list - which is to provide the "Suspend VM" but additionaly give a further indication of the level of suspension - or cause.

  *Not looked at the spec for the high-level display listener yet - also not sure how this would apply to Terminate n Stay Resident type of apps.

  Posted by: jb22 on June 15, 2007 at 09:00 AM

• Reply to Sean:
  Thank you for your reply. What strikes me as so bizarre is your mentioning how getting involved is important, and we need to move forward, then you mention MTA. MTA has been around for almost 2 years, is marked as needed for MIDP, and CLDC, however no one implements it.
  JTWI was a good idea, as is MSA, however you can not leave it up to operators nor vendors to pick and choose. This is java, not an a-la-cart dinner. They need to take it all or just don't even try.
  MTA isn't even part of MSA as far as I can tell. How do you have a mobile platform language and not have any support for Telephony service on the device. Sad...truly sad!!

  So what I'm saying is we don't need any more cheerleaders saying how bright the future of ME is, we need thugs, angry mobs with farm tools ready to take down any operator not willing to open up their systems.
  Oh and web2.0 is just a surrender flag. Might as well just throw in the towel. Again can't do anything useful there. The whole iPhone joke of "we don't need an SDK", is just more FUD for "you developers can't write anything important on our system." Sure if I write enough ECMA (I will not call it JS), CSS, and use photoshop you can have a nice looking address book, or sales entry screen...woopi-do. How about a real-time GPS system with map overlays, and SMS waypoint sharing. Or remote system notification and app startup. Oh and I don't want to write anything but Java, can your web2.0 do that...didn't think so.

  I really don't mean to come down on you but I want folks to realize that regardless of if the API changes, it means nothing unless operators start treating ME like a first class citizen, and Sun starts using some muscle to make it happen. That would be one play from the M$ playbook that I wouldn't mind seeing Jonathon pulling on the US operators and phone vendors.

  Oh and FYI...An ME project I'm working on may get nixed because ME just can't do everything WinMoblows, or Brew, and that the only Palm JVM (J9) has been declared unusable.
  Still frustrated
  -Shawn

  Posted by: sfitzjava on June 14, 2007 at 06:44 PM

• (cross-posted to
  Enrique Ortiz's blog)

  I'm concerned that two very important points are being lost here: that MIDP3 is trying to replace the notifications that implementations are overloading with in pauseApp, with better, finer-grained APIs elsewhere (such as DisplayListener). In other words, we're trying NOT to eliminate the platform-dependent functionality pauseApp enables, but to move it to platform-independent APIs.

  The other point I'm concerned about is that we're needlessly defending a lifecycle that at best enables implementers to stops our threads from executing. When you boil off the pauseApp overloads, that's what you're left with.

  I'm not speaking on the part of the EG at this moment, but rather myself (and possibly other developers) that I'd rather see the paused state eliminated and the overloaded functionality moved into to APIs designed specifically to handle them. Deprecating pauseApp is actually the logical fallout of these two points - when you do these, is pauseApp or the paused state of any use to developers?

  My mistake perhaps is that I did not frame the issue in this regard - "here are the ways this functionality is being improved, and by the way, this means pauseApp isn't needed anymore."

  Perhaps I should do that before the world thinks the EG is trying to hobble developers.

  Posted by: sean_sheedy on June 14, 2007 at 08:22 AM

• Hello Enrique (ceo),

  I think what we're getting at here is, if we're moving the functionality that has been overloaded into pauseApp into other APIs such as DisplayListener, then all that leaves pauseApp is with the ability for platforms to be able to deny us CPU time and literally PAUSE us.

  As a developer, I can live with a few cycles, but having a platform arbitrarily keep my threads from executing is something I do not want to continue to add complexity to my application design. And when you boil off all the overloading, that is literally what pauseApp is all about.

  So why not get rid of the Paused state in the lifecycle? Do we really need to keep it around if it really is a hack for an old problem? This is me talking now, I don't remember if we've talked about this in EG, but it will probably come up today, and I know that I'm about to get flamed for it, and someone will provide a very good argument for keeping it, which will cause me to rethink this statement... ;-)

  Posted by: sean_sheedy on June 14, 2007 at 08:00 AM

• Hello Shawn,

  Thanks for speaking up. I think that Java ME is in a position today to do more "forcing" and tighten down specs than it was back in 1999/2000/2001 when the goal was to get it adopted in the first place. Unfortunately we're suffering today from the flexibility that was granted to manufacturers and was required then to allow it to be ported on the greatest number of handsets to gain critical mass. This deprecation thing is part of a larger attempt to tighten down compliance by moving this functionality out of the overloaded pauseApp, and into APIs (such as DisplayListener - see the MIDP3 early draft review) which can provide much finer grained functionality. Instead of deprecating these APIs should we instead simply tighten up the spec and point people (and implementers) to the APIs that are replacing what implementers leveraged pauseApp for?

  Has pauseApp morphed into the (rather coarse-grained) event notification mechanism that complements the rather coarse-grained platformRequest API, just operating in the other direction (manager -> application)?

  Regarding APIs into telephony services, there is MTA 1.0 and the new MTA 2.0 (JSR 304) and the last I spoke to him, the spec lead was dying to get people on board, so join that JSR and get your voice heard!

  So, it is very easy for me to say "go join a JSR" especially when I was working for an operator who paid my way to the EG meetings. Now I am independent and still in MIDP3 and going to the next EG meeting in Europe and about to drop several grand of my own cash for that trip. I am going to represent myself and other like-minded developers. I am carrying your message with me. This is how strongly I feel about the issue. I also would not have offered to surface this issue if I did not feel that the discussion could lead to a vastly improved situation over the overloaded situation pauseApp brings today. Do we, as developers, really want to continue to allow platforms to PAUSE us, when they have enough capability to let us continue to run and have resources?

  Scripting engine... take a look at where from u-locate. Incidentally, if Java ME does not provide such a thing, the scripting engine you're talking about is coming anyway: mobile web 2.0 potentially as defined by the iPhone. If this flies, the current browser vendors will conceivably push similar solutions that are more web-like than mobile-like. Is this a bad thing? From the developer's perspective, not at all!!! Without the mobile learning curve, developers could flock to these solutions, and operators, seeing money being made, and seeing a real working example on how it is done right (presuming Apple gets it right, which is not a terribly large leap) could eventually require their existence in platforms. If web services is used to provide access to handset functionality, caching is used to make these apps available and load quickly, and a means to put an idle screen icon is provided, where does this leave Java ME? MSA and the JCP needs to focus on how Java ME can play with, and not get sideswiped by AJAX. I'm going pretty far out on limb here because JSR-290 is addressing this, and I have not paid attention to it recently enough to know whether or not it will adequately bridge AJAX and Java ME.

  So I believe it is hugely important to get the fragmentation issue solved and it may require some pain on everyone's part for the benefit of having a more predictable environment. You are hitting on topics that are brought up at every EG meeting (not just MIDP3) and which demand a practice of "fragmentation management" and onboarding and partnering with all the players so that issues (like the certification issue you've mentioned) are addressed.

  Posted by: sean_sheedy on June 14, 2007 at 07:52 AM

• jb22,

  You make some very good points. About the TCK not being able to catch the pauseApp fragmentation - I'm afraid that the current (MIDP 2) spec for pauseApp is so loose that an implementer could pretty much do anything with it, thus it is practically impossible to write a meaningful TCK test around it. So the spec needs to address the issue.

  JDTS provides a lot more tests, and operators may run these tests and make their implementations dependent on the outcome. However, this is not the same as the TCK and requires that the operator actually invest some time and energy in JDTS. Additionally, the operators, who arguably could define a more fine-grained test set that the implementers must conform to, and do so outside the scope of the TCK, are not talking to each other outside of the expert groups, nor is the competitive environment conducive towards that kind of collaboration. The operators I've talked to all want to solve the problem but are constrained by the competitive environment, resources, legal reasons, etc...

  At the same time, you do not want to standardize too much, or you will either have one platform built for the lowest common denominator or one platform that appeals to too few parties. By "standardize" I mean make hard requirements and eliminate flexibility. I am starting to get into what can be a VERY long discussion that is actually overdue. Personally, I promote the concept of "fragmentation management" being a practice and requiring processes that requires as much diplomacy and management as it does engineering. I'm afraid that I'm touching the "third rail" in Java ME, but I'm also convinced that this third rail is the byproduct of MIDP/CLDC being loose enough to allow an extremely diverse set of target platforms. The "third rail" in Java ME exists because it powers innovation (otherwise we'd not have well over a billion ME devices today.) Compare this to any other handset platform - Palm - Windows Mobile - BREW - for which the worldwide adoption of these environments is a fraction of Java ME. The only other handset environment that is deployed wider is the mobile browser. Sorry about getting obvious here.

  Addressing the need to be notified when losing the display - you can register for a display listener that can provide this info, for both the high and low level APIs - the high level listener is new in MIDP3 and can be found in the early draft review - look for DisplayListener which is in the javadoc.

  So I think that this listener is what you are looking for when you say "parallel functionality"?

  I think what we're trying to say is that we think we're trying to provide more specific functionality in MIDP3 that replaces what implementers have "overloaded" pauseApp with. pauseApp, notifyPaused and resumeRequest, from a technical standpoint, can legally be no-ops (Nokia's implementation is this way) so by tightening up pauseApp to be, essentially, a no-op, we're driving towards standardizing away from overloading pauseApp and towards the use of listeners.

  Perhaps the question we should be asking is, what are all the different ways that pauseApp is being used today, and are we providing new APIs that replace that functionality in an improved and more targeted way?

  Posted by: sean_sheedy on June 14, 2007 at 07:10 AM

• @sean:

  
  From the MIDP spec:

  "The application management software wants the MIDlet to significantly reduce the amount of resources it is consuming, so that they may temporarily be used by other functions on the device such as a phone call or running another MIDlet. The AMS will signal this request to the MIDlet by calling the MIDlet.pauseApp method. The MIDlet should then reduce its resource consumption as much as possible."

  The source of fragmentation or confusion is not the method itself, or the life-cycle state-machine definition, but the issue is that certain implementations are overloading the original intention with inconsistent behaviors... Note that not calling the pauseApp() method at all is a valid behavior, because not always there is a need to reduce the use of resources... But we can't assume that no implementation might not require to ask MIDlets to release resources and go passive.

  The method pauseApp() is a life-cycle signal, and it should be treated as such (as described above). No need to deprecate it; a MIDlet enters the active state (startApp), the passive state (pauseApp), and destroyed state (destroyApp). This has nothing to do with Moore's Law and devices becoming more sophisticated; it is more trivial than that.

  A added a little survey to my blog to measure opinions on this matter... check it out. Thanks your your article on this... it is very good.

  ceo

  Posted by: eortiz on June 14, 2007 at 06:44 AM

• If you want to decrease fragmentation then I say you force manufacturers to build a compliant VM!!!
  Yes this will impact my code!!!
  Since you don't provide decent APIs into the Telephony services to Java I need some way to know that a call or other activity has been requested. Sure there are bigger and more expensive phones coming out every day, but there are also MIDP1.0 phones still on the market. MIDP3.0 is only meaningful if you can push it out to the market, and it is quickly deployed onto new AND older devices. As it stands it will be 2 or more years before 3.0 will matter, speed up the process.
  Be more sympathetic to the developers, and put more heat on to the vendors and operators to make it EASY for JavaME development....and more than just games!!!
  Put a scripting engine into ME, do something meaningful instead of removing features that might allow me to actually look like I can do something useful on phones.
  Be more like MicroSoft and beat the operators and manufactures into supporting the full spec to the Nth degree, and then provide a signing certificate program that doesn't cost me an arm and a leg. If RIM can do it for a one time $100 fee then you can do it for the entire market.
  Frustrated
  -Shawn

  Posted by: sfitzjava on June 14, 2007 at 06:18 AM

• Maybe I'm missing the point somewhere.

  1. I can see that fragmentation in the implementations of pauseApp are a bad thing ... but that is really an issue for Sun when they pass the j2me implementation in their TCK.

  2. From the perspective of a games developer/publisher - we don't really care about machine resource usage (well we do but not in this context) - what we do care about is being notified that the user is doing something else (taking a call) and thus that critical moment in the game shouldn't be lost.

  e.g. Take the example of our game Connexions - or perhaps Tetris - you're about to win through to the next level - call comes in VM is suspended - we're ok up to this point - but the user hangs up and the VM is restarted - but because the user has context switched they miss the vital completion moment of the game and get sent back to the beginning.

  In the presence of "pauseApp" we have had a notification that the user has context switched - and THUS can put the game in a paused state where the user can resume the game when they are ready - without frustratingly being sent back to the start again.

  
  So I guess my question is - if you deprecate pauseApp how will the phone OS notify my application to change its state accordingly ? I still need this - but my big bugbear is I need it to work consistently.

  
  Aside: when I helped compile the developer's MIDP3.0 reqs list from the KVM group the one feature that really stood out is that Sun need toughen up the TCK's such that features such as pauseApp work consistently - THAT is the issue that needs to be addressed, not the willy-nilly deprecation of functionality that is actually useful - unless of course you can provide parallel functionality which will be guaranteed to work consistently across implementations.

  IMHO MIDP3.0's biggest goal should be the tough standardisation of the jme implementations, s.t. there is no need to specifically port for a VM's architecture (features!). Of course there will always be porting issues involved with different render sizes.

  [sean: edited to restore line formatting]

  Posted by: jb22 on June 14, 2007 at 03:39 AM

• Hi Enrique,

  > The source of the issue is not the life-cycle method. ceo

  Can you elaborate on your point, and perhaps elaborate on what you consider the source of the issue is?

  Hello zero,

  Are you essentially saying, mark these APIs as deprecated, but don't actually change the spec until MIDP 4?

  I don't think we'll see MIDP 4 implementations until 2010 at the earliest. I'd hate to see this point of fragmentation continue needlessly. But maybe this would work. Are you saying that calling this deprecated, and describing the desired final result (the methods are no-ops) would provide a strong enough incentive for MIDP3 implementers to actually treat them as no-ops today (which is in fact permitted by the MIDP 1 and 2 spec today??

  Or, do you mean that deprecation implies that the methods will actually go away someday? I don't think anyone is proposing that, since every app today contains a pauseApp method, and removing pauseApp from MIDP would break all those apps in future devices. If deprecation implies eventually not having the API, then deprecation is not what we want, I don't think. Would it be better to simply narrow the interpretation down to "is never called" (pauseApp) or "does nothing" (resumeRequest, notifyPaused)?

  Finally, you mention the confusion around changing the API ... I like the proposal because it reduces the confusion of the fragmentation caused by the current definition of this API. Would it be more appropriate simply to cut the legs off the alternate interpretations by tightening up the specification?

  Posted by: sean_sheedy on June 14, 2007 at 12:10 AM

• Why not go the standard way:
  1. let the compiler print a deprecated warning if the API methods are used with midp 3.0
  2. remove the API parts with midp 4.0

  Making it not work anymore without chaning the interface is essentially skipping 1), but IMHO more confusing. So either remove the functionality or go through the whole process :-)

  Posted by: zero on June 13, 2007 at 10:51 PM

• I disagree with the deprecation of such life-cycle method. The source of the issue is not the life-cycle method.

  ceo
  

  Posted by: eortiz on June 13, 2007 at 09:51 PM

This work is licensed under a Creative Commons License.