Skip to main content

pauseApp questions from the MIDP3 EG

14 replies [Last post]
Anonymous

After reading all the KVM-INTEREST and Mobile & Embedded posts on the
topic, I've tried to provide some clarifications to the MIDP3
pauseApp question: http://weblogs.java.net/blog/sean_sheedy/archive/
2007/06/clarifying_the.html

More important is that Mike Milikich, the MIDP3 EG spec lead, is
looking for answers to these questions (please respond here or to
jsr-271-comments@jcp.org):

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

Thanks, Enrique, for kicking off the discussion on this!

Sean

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
David Brittain

If you don't stop using the 3D API on these devices the phone resets.
So, it definitely shouldn't happen.

I agree that this shouldn't be a requirement on the game programmer. But
practically speaking it is very useful as the presence of pauseApp
allows us to fix the issue. I don't think the VM/handset programmers
explicitly decided to make it a requirement to stop using the 3D API
when a call came in - or presumably they would have done something to
stop the devices crashing. However, the fact that pauseApp was called by
the VM meant that it _was_ possible for us to do something about the
crash!

I liked the idea that was proposed of a generic event callback which
tells us exactly what is going on with the phone. The more data our app
can get the better in my view.

Dave

-----Original Message-----
From: A mailing list for KVM discussion
[mailto:KVM-INTEREST@JAVA.SUN.COM] On Behalf Of
meinterest@MOBILEANDEMBEDDED.ORG
Sent: Monday, June 25, 2007 12:03 PM
To: KVM-INTEREST@JAVA.SUN.COM
Subject: Re: pauseApp questions from the MIDP3 EG

> On some Sprint JSR 184 capable handsets you are
> required to stop using
> 3D render calls when the app is paused as both
> telephony and 3D use the
> device's DSP.

This is exactly the problem I'm talking about, what if you don't stop
using the 3D API?
Besides being a security vulnerability (e.g. DoS attack) this can harm
the main use case of the device (phone calls). There should be no such
requirement to begin with since it can lead to problems with the phone
call.
[Message sent by forum member 'vprise' (vprise)]

http://forums.java.net/jive/thread.jspa?messageID=223838

========================================================================
===
To unsubscribe, send email to listserv@java.sun.com and include in the
body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

captainfreedom
Offline
Joined: 2007-01-10
Points: 0

> If you don't stop using the 3D API on these devices
> the phone resets.
> So, it definitely shouldn't happen.
>
> I agree that this shouldn't be a requirement on the
> game programmer. But
> practically speaking it is very useful as the
> presence of pauseApp
> allows us to fix the issue. I don't think the
> VM/handset programmers
> explicitly decided to make it a requirement to stop
> using the 3D API
> when a call came in - or presumably they would have
> done something to
> stop the devices crashing. However, the fact that
> pauseApp was called by
> the VM meant that it _was_ possible for us to do
> something about the
> crash!
What, doesn't hideNotify work on those handsets?
And what do you mean by "stop using the 3D API"? Just stop the game loop, or do you have null all references to the 3d objects?

Sean Sheedy

Hi Alec,

There is a new API that didn't make it into the EDR that is planned
for the public review that will let you provide a display listener
for all kinds of displays.

Sean

On Jun 24, 2007, at 7:40 PM, Alec Bickerton wrote:

> Sean Sheedy was heard to mumble on 20/06/07 13:41:
>> After reading all the KVM-INTEREST and Mobile & Embedded posts on the
>> topic, I've tried to provide some clarifications to the MIDP3
>> pauseApp
>> question: http://weblogs.java.net/blog/sean_sheedy/archive/2007/06/
>> clarifying_the.html
>>
>> More important is that Mike Milikich, the MIDP3 EG spec lead, is
>> looking
>> for answers to these questions (please respond here or to
>> jsr-271-comments@jcp.org ):
>>
>> - 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?
>
> One problem with deprecating pauseApp...
>
> Any application with a UI not extending a Canvas has no ability to
> sanely handle interruptions as hideNotify / showNotify is not
> available
> . ( These applications do exist )
>
> Alec,
>
> ======================================================================
> =====
> To unsubscribe, send email to listserv@java.sun.com and include in
> the body
> of the message "signoff KVM-INTEREST". For general help, send
> email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

David Brittain

On some Sprint JSR 184 capable handsets you are required to stop using
3D render calls when the app is paused as both telephony and 3D use the
device's DSP.

Dave

________________________________

From: A mailing list for KVM discussion
[mailto:KVM-INTEREST@JAVA.SUN.COM] On Behalf Of Sean Sheedy
Sent: Wednesday, June 20, 2007 4:41 AM
To: KVM-INTEREST@JAVA.SUN.COM
Subject: pauseApp questions from the MIDP3 EG

After reading all the KVM-INTEREST and Mobile & Embedded posts on the
topic, I've tried to provide some clarifications to the MIDP3 pauseApp
question:
http://weblogs.java.net/blog/sean_sheedy/archive/2007/06/clarifying_the.
html

More important is that Mike Milikich, the MIDP3 EG spec lead, is looking
for answers to these questions (please respond here or to
jsr-271-comments@jcp.org):

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

Thanks, Enrique, for kicking off the discussion on this!

Sean

========================================================================
=== To unsubscribe, send email to listserv@java.sun.com and include in
the body of the message "signoff KVM-INTEREST". For general help, send
email to listserv@java.sun.com and include in the body of the message
"help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

vprise
Offline
Joined: 2003-11-07
Points: 0

> On some Sprint JSR 184 capable handsets you are
> required to stop using
> 3D render calls when the app is paused as both
> telephony and 3D use the
> device's DSP.

This is exactly the problem I'm talking about, what if you don't stop using the 3D API?
Besides being a security vulnerability (e.g. DoS attack) this can harm the main use case of the device (phone calls). There should be no such requirement to begin with since it can lead to problems with the phone call.

C. Enrique Ortiz

- What percentage of your applications implement pauseApp, and for the
ones that do, what functionality is present in pauseApp?

* It all depends on the application requirements -- some apps do nothing
because are simple/light, others free stuff and remember state...

- For any applications that implement pauseApp, what would be the effect
of running that application in an environment in which pauseApp was
never called?

* nothing; since the app never enters the state for which such code was
designed for. But that is not the point! The question is if the pause
app state is a valid state, and it is....

Environments / OSes that are advanced enough, such as the S60, with
multitasking etc. might not need to pause app etc, thus it has no need
to call pause app, which is totally fine -- but not all OSes/envs are
created equal.

BTW, is Xlet deprecating pauseXlet()? Hinkmod, are you in this KVM
list? What's the answer? Maybe I should post this question to the CDC list.

Please continue posting your comments... And feel free to add your
opinion/vote here:
http://www.cenriqueortiz.com/weblog/JavaME%2C+J2ME/2007/06/14/MIDP3-Prop...

Current poll results are:

Deprecate pauseApp only for MIDP3-labeled apps

18% (10 Votes)
Deprecate pauseApp regardless of version

16% (9 Votes)
Do not deprecate pauseApp

63% (36 Votes)
I don't care

4% (2 Votes)

57 total votes since Jun 14, 2007

ceo

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Alec Bickerton

Sean Sheedy was heard to mumble on 20/06/07 13:41:
> After reading all the KVM-INTEREST and Mobile & Embedded posts on the
> topic, I've tried to provide some clarifications to the MIDP3 pauseApp
> question: http://weblogs.java.net/blog/sean_sheedy/archive/2007/06/clarifying_the....
>
> More important is that Mike Milikich, the MIDP3 EG spec lead, is looking
> for answers to these questions (please respond here or to
> jsr-271-comments@jcp.org ):
>
> - 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?

One problem with deprecating pauseApp...

Any application with a UI not extending a Canvas has no ability to
sanely handle interruptions as hideNotify / showNotify is not available
. ( These applications do exist )

Alec,

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Kim Daniel Arthur

Hi,

hide/showNotify() are in the Displayable class so I think you should be safe
there :)

Kim

On 25/6/07 01:40, "Alec Bickerton" wrote:

> Sean Sheedy was heard to mumble on 20/06/07 13:41:
>> After reading all the KVM-INTEREST and Mobile & Embedded posts on the
>> topic, I've tried to provide some clarifications to the MIDP3 pauseApp
>> question:
>> http://weblogs.java.net/blog/sean_sheedy/archive/2007/06/clarifying_the....
>>
>> More important is that Mike Milikich, the MIDP3 EG spec lead, is looking
>> for answers to these questions (please respond here or to
>> jsr-271-comments@jcp.org ):
>>
>> - 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?
>
> One problem with deprecating pauseApp...
>
> Any application with a UI not extending a Canvas has no ability to
> sanely handle interruptions as hideNotify / showNotify is not available
> . ( These applications do exist )
>
> Alec,
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Alec Bickerton

Kim Daniel Arthur was heard to mumble on 24/06/07 19:46:
> Hi,
>
> hide/showNotify() are in the Displayable class so I think you should be safe
> there :)
>
> Kim

Not according to the MIDP 2.0 javadoc (I don't have it installed on this
machine) so I checked
http://mobilezoo.biz/jsr/118/javax/microedition/lcdui/Displayable.html here.

Alec,

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Kim Daniel Arthur

You're right, I was looking at some rogue javadoc here:
http://www.docjar.com/docs/api/javax/microedition/lcdui/Displayable.html

On 25/6/07 02:17, "Alec Bickerton" wrote:

> Kim Daniel Arthur was heard to mumble on 24/06/07 19:46:
>> Hi,
>>
>> hide/showNotify() are in the Displayable class so I think you should be safe
>> there :)
>>
>> Kim
>
> Not according to the MIDP 2.0 javadoc (I don't have it installed on this
> machine) so I checked
> http://mobilezoo.biz/jsr/118/javax/microedition/lcdui/Displayable.html here.
>
> Alec,
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Stefano Andreani

Hi Sean,

Your proposal to deprecate pauseApp is clever, but I'm not fully
confident it could be the best choice. Removing pauseApp has an
important impact on JVM implementations, because it implies that the
native system would have no way to reduce the amount of resources used
by MIDlets other than killing them.

Regarding your questions: we use pauseApp in case the MIDlet is targeted
for devices implementing the PAUSE state (when saving/handling the
execution status is required), and, believe me, there are several
devices, in particular for the Asian market, with PAUSE state as the
only way to have Java running properly and efficiently on low level
hardware.

But apart from the problem we would have with low-range mobile phones,
the other reason why I think deprecating pauseApp it is not a good idea
is because it would reduce the "scope" of MIDP: as the early story of
Java says, in specification design it is better to prefer flexibility
and concentrate on high level features, to allow uses of the technology
different from the ones we can think about today.

Thanks from me to for raising the discussion in the ML.

BR,
Stefano.

_________________________

Stefano Andreani
www.opentecheng.com
www.mobileplasma.com

> After reading all the KVM-INTEREST and Mobile & Embedded posts on the
> topic, I've tried to provide some clarifications to the MIDP3 pauseApp
> question: http://weblogs.java.net/blog/sean_sheedy/archive/2007/06/clarifying_the....
>
> More important is that Mike Milikich, the MIDP3 EG spec lead, is
> looking for answers to these questions (please respond here or to
> jsr-271-comments@jcp.org ):
>
> - 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?
>
> Thanks, Enrique, for kicking off the discussion on this!
>
> Sean
>
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send
> email to listserv@java.sun.com and include in the body of the message
> "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Sean Sheedy

Stefano,

You have a very good point. The question is, has the low end of
devices risen to the point where they are sufficiently capable off
handling system critical tasks (phone calls) without having to turn
off MIDlets? I think it is up to the manufacturers and implementers
(and I take it that your company is the latter) to let us know where
the manufacturers stand.

As I am now an individual JCP member, I tend to take the perspective
that if there is some way we can get CPU time for our threads when we
don't have the display (such as in a phone call) and new notification
mechanisms exist that replace those overloaded onto pauseApp, then we
don't need a paused state any more.

MIDP3 may be beyond the scope of certain small devices, and this
should be an interesting debate in the face to face meeting this
week. VMs such as the Squawk VM are appearing to fill in the very
low end. I have some experience with this as I am trying to find a
way to put Java ME into amateur radio handy talkies. The first
question asked by one of the manufacturers was, "how many kilobytes
does it consume?" But it sounds like your firm may have some
experience with clients at the low end of device capabilities.

I'm looking forward to seeing you this week!

Sean

On Jun 24, 2007, at 6:16 PM, Stefano Andreani wrote:

> Hi Sean,
>
> Your proposal to deprecate pauseApp is clever, but I’m not fully
> confident it could be the best choice. Removing pauseApp has an
> important impact on JVM implementations, because it implies that
> the native system would have no way to reduce the amount of
> resources used by MIDlets other than killing them.
>
> Regarding your questions: we use pauseApp in case the MIDlet is
> targeted for devices implementing the PAUSE state (when saving/
> handling the execution status is required), and, believe me, there
> are several devices, in particular for the Asian market, with PAUSE
> state as the only way to have Java running properly and efficiently
> on low level hardware.
>
> But apart from the problem we would have with low-range mobile
> phones, the other reason why I think deprecating pauseApp it is not
> a good idea is because it would reduce the “scope” of MIDP: as the
> early story of Java says, in specification design it is better to
> prefer flexibility and concentrate on high level features, to allow
> uses of the technology different from the ones we can think about
> today.
>
> Thanks from me to for raising the discussion in the ML.
> BR,
> Stefano.
>
> _________________________
>
> Stefano Andreani
> www.opentecheng.com
> www.mobileplasma.com
>
>> After reading all the KVM-INTEREST and Mobile & Embedded posts on
>> the topic, I've tried to provide some clarifications to the MIDP3
>> pauseApp question: http://weblogs.java.net/blog/sean_sheedy/
>> archive/2007/06/clarifying_the.html
>>
>> More important is that Mike Milikich, the MIDP3 EG spec lead, is
>> looking for answers to these questions (please respond here or to
>> jsr-271-comments@jcp.org):
>>
>> - 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?
>>
>> Thanks, Enrique, for kicking off the discussion on this!
>>
>> Sean
>>
>>
>> =====================================================================
>> ====== To unsubscribe, send email to listserv@java.sun.com and
>> include in the body of the message "signoff KVM-INTEREST". For
>> general help, send email to listserv@java.sun.com and include in
>> the body of the message "help".
> ======================================================================
> ===== To unsubscribe, send email to listserv@java.sun.com and
> include in the body of the message "signoff KVM-INTEREST". For
> general help, send email to listserv@java.sun.com and include in
> the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

vprise
Offline
Joined: 2003-11-07
Points: 0

The problem isn't with low end devices, the problem is with high end devices where you have multiple MIDlets running simultaneously. Some of these MIDlets may be very heavy (e.g. 3D) and the device could take some time to run pauseApp() e.g. take time to dispose 3D resources/network or suddenly cause a GC inadvertently (or worse call System.gc()).
Operators consider calls to be the most important service, if there is even a single second delay in the ring people might choose to avoid content (especially when waiting for an important call). Nothing must get in the way!
Calling pauseApp requires detecting the incoming call yet keeping the context in Java and waiting for pauseApp() to complete (it might do some asynchronous things inadvertently which means that even after returning from it resources won't change).

A high end phone has separate resources for Java and calls, it doesn't need resources other than CPU (memory is plenty). It would much rather suspend the execution of the Java VM abruptly and let it know that it resumed when resuming (at which point you have plenty of CPU).

When switching to a different application in MVM pause might be useful, but then it wouldn't be appropriate. It makes far more sense to have an API indicating whether you are the foreground MIDlet or a background MIDlet.

captainfreedom
Offline
Joined: 2007-01-10
Points: 0

I don't use pauseApp, only use hideNotify to stop the game playing while the midlet is minimised and that's it. Most phones don't even use the pauseApp method, so it's fairly pointless anyway.
By the way, it's nice to see someone from the commitee looking for feedback for a change.

Message was edited by: captainfreedom