The Source for Java Technology Collaboration
User: Password:



Sean Sheedy's Blog

June 2007 Archives


MIDP3 EG face-to-face wraps up

Posted by sean_sheedy on June 26, 2007 at 09:12 PM | Permalink | Comments (0)


Another MIDP3 Expert Group face-to-face meeting wrapped up today. I have to say, although I went as an individual JCP member and paid my own way to Spain, it was worth every moment - the friendships, the networking, the feeling of accomplishment as we worked through spec issues, dusting off high school foreign language skills, being able to have intelligent conversations with geniuses in the mobile space... it was wonderful. There was a LOT of working going on - many people tired if not burned out from all the travel, the 9 1/2 hour days, the office email that one must attend to back at the hotel - all of this making the time after hours that much more anticipated.


Speaking of after-hours activities, unlike other standards bodies, you don't find JSR EGs running off to boondoggles in the French Riviera or Thailand - they generally meet in ordinary cities in Europe or somewhere in the US, alternating continents each meeting. Someone from the EG volunteers to host a meeting in one of their offices, pays for food to be catered, and takes folks out to dinner one night for the "EG Dinner" (which prospective EG hosts should know is NOT mandatory.)


Before and after meetings, some of us explore the city we've come to for our meetings...

Continue Reading...



Clarifying the MIDP3 pauseApp proposal

Posted by sean_sheedy on June 20, 2007 at 04:29 AM | Permalink | Comments (3)

The intent of this post is to summarize and address the developer comments regarding the MIDP3 proposal to deprecate pauseApp, and hopefully clarify some misconceptions about the proposal. I want to thank Enrique Ortiz for using his position in the industry to help get the message on this topic out to developers via his blog and post to KVM-INTEREST which is reflected in the Mobile & Embedded forums at java.net.

Mike Milikich, the MIDP3 EG lead, has asked for developer input on two specific questions:
  • What percentage of your applications implement pauseApp, and for the ones that do, what functionality is present in pauseApp?
  • For any applications that implement pauseApp, what would be the effect of running that application in an environment in which pauseApp was never called?
If you don't make it through this rather long post, these are the two most pressing questions at this point.

Also, I will be going to next week's MIDP3 face-to-face meeting. If there is a particular aspect of this topic or any other you would like me to emphasize, post a reply, or call me at +1-703-771-8527. The developer community is underrepresented in face-to-face meetings because of the substantial time and financial burden that attending these presents, and frankly we need more of the "street smarts" experience of developers.

What is driving the proposal?

The MIDP3 pauseApp proposal revolves around these points:

Continue Reading...



Message from MIDP3: Goodbye pauseApp!

Posted by sean_sheedy on June 13, 2007 at 09:13 PM | Permalink | Comments (13)

[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
.

Continue Reading...





Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds