|
Replies:
27
-
Last Post:
Jun 19, 2007 4:05 AM
by: terrencebarr
|
|
|
|
|
|
|
MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 13, 2007 11:22 PM
|
|
|
|
|
Currently there is a proposal within the MIDP3 Expert Group, to remove,
or I should say, deprecate, the MIDlet pauseApp() life-cycle method...
What is your opinion?
Read more at:
http://www.cenriqueortiz.com/weblog/JavaME%2C+J2ME/2007/06/14/MIDP3-Proposal-to-remove-the-MIDlet-pauseApp-lifecycle-method.html
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]
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 14, 2007 12:43 AM
in response to: C. Enrique Ortiz
|
|
|
so what would they replace it with?
|
|
|
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 14, 2007 7:01 AM
in response to: C. Enrique Ortiz
|
|
|
AFAIK, the Canvas.showNotify /Canvas.hideNotify mechanism has a much
better moniker.
C. Enrique Ortiz wrote:
> With nada... It would be deprecated.
>
> ceo
>
> meinterest@mobileandembedded.org wrote:
>> so what would they replace it with?
>> [Message sent by forum member 'captainfreedom' (captainfreedom)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=222067
>>
>> ===========================================================================
>>
>> 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".
>>
>> --------------------------------
>> Spam/Virus scanning by CanIt Pro
>>
>> For more information see
>> http://www.kgbinternet.com/SpamFilter.htm
>>
>> To control your spam filter, log in at
>> http://filter.kgbinternet.com
>>
>>
>
> --
> C. Enrique Ortiz
> eortiz@j2medeveloper.com
> 512-635-4225
> http://www.CEnriqueOrtiz.com
> http://www.CEnriqueOrtiz.com/weblog
> http://www.MobileMondayAustin.org
> http://www.AustinWirelessAlliance.org
>
> ===========================================================================
>
> 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".
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 14, 2007 7:07 AM
in response to: Adrian Valentin...
|
|
|
I think there needs to be a more granulated communication from the os to the
vm,
public static MIDlet.externalEvent( String event, String parameter )
{
switch ( event )
{
case MIDlet.INCOMING_CALL:
break;
case MIDlet.INCOMING_SMS:
break;
case MIDlet.LOW_BATTERY_WARNING:
int batteryLevel = Integer.parseInt( paramenter );
break;
case.AND_SO_ON:
break;
}
}
This way you have more control of how your app should behave on any type of
external event. There should also be a strict TCK to ensure that each
implementation respects this...
At the same time hide/shownotfy should remain as they do, however you cannot
be 100% sure that these are triggered by an external event or by your apps
behaviour itself.
On 14/6/07 22:01, "Adrian Valentin Dan" <adrian.dan@12SNAP.RO> wrote:
> AFAIK, the Canvas.showNotify /Canvas.hideNotify mechanism has a much
> better moniker.
>
>
>
> C. Enrique Ortiz wrote:
>> With nada... It would be deprecated.
>>
>> ceo
>>
>> meinterest@mobileandembedded.org wrote:
>>> so what would they replace it with?
>>> [Message sent by forum member 'captainfreedom' (captainfreedom)]
>>>
>>> http://forums.java.net/jive/thread.jspa?messageID=222067
>>>
>>> ===========================================================================
>>>
>>> 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".
>>>
>>> --------------------------------
>>> Spam/Virus scanning by CanIt Pro
>>>
>>> For more information see
>>> http://www.kgbinternet.com/SpamFilter.htm
>>>
>>> To control your spam filter, log in at
>>> http://filter.kgbinternet.com
>>>
>>>
>>
>> --
>> C. Enrique Ortiz
>> eortiz@j2medeveloper.com
>> 512-635-4225
>> http://www.CEnriqueOrtiz.com
>> http://www.CEnriqueOrtiz.com/weblog
>> http://www.MobileMondayAustin.org
>> http://www.AustinWirelessAlliance.org
>>
>> ===========================================================================
>>
>> 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".
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 14, 2007 7:11 AM
in response to: Kim Daniel Arthur
|
|
|
Kim -
MIDP3 supports system events such as the low battery one -- I don't
think the incoming call one.. One thing is primitive life-cycle
methods, and one thing are more elaborated events, in my opinion.
ceo
Kim Daniel Arthur wrote:
> I think there needs to be a more granulated communication from the os to the
> vm,
>
> public static MIDlet.externalEvent( String event, String parameter )
> {
> switch ( event )
> {
> case MIDlet.INCOMING_CALL:
> break;
>
> case MIDlet.INCOMING_SMS:
> break;
>
> case MIDlet.LOW_BATTERY_WARNING:
> int batteryLevel = Integer.parseInt( paramenter );
> break;
>
> case.AND_SO_ON:
> break;
> }
> }
>
> This way you have more control of how your app should behave on any type of
> external event. There should also be a strict TCK to ensure that each
> implementation respects this...
>
> At the same time hide/shownotfy should remain as they do, however you cannot
> be 100% sure that these are triggered by an external event or by your apps
> behaviour itself.
>
>
> On 14/6/07 22:01, "Adrian Valentin Dan" <adrian.dan@12SNAP.RO> wrote:
>
>
>> AFAIK, the Canvas.showNotify /Canvas.hideNotify mechanism has a much
>> better moniker.
>>
>>
>>
>> C. Enrique Ortiz wrote:
>>
>>> With nada... It would be deprecated.
>>>
>>> ceo
>>>
>>> meinterest@mobileandembedded.org wrote:
>>>
>>>> so what would they replace it with?
>>>> [Message sent by forum member 'captainfreedom' (captainfreedom)]
>>>>
>>>> http://forums.java.net/jive/thread.jspa?messageID=222067
>>>>
>>>> ===========================================================================
>>>>
>>>> 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".
>>>>
>>>> --------------------------------
>>>> Spam/Virus scanning by CanIt Pro
>>>>
>>>> For more information see
>>>> http://www.kgbinternet.com/SpamFilter.htm
>>>>
>>>> To control your spam filter, log in at
>>>> http://filter.kgbinternet.com
>>>>
>>>>
>>>>
>>> --
>>> C. Enrique Ortiz
>>> eortiz@j2medeveloper.com
>>> 512-635-4225
>>> http://www.CEnriqueOrtiz.com
>>> http://www.CEnriqueOrtiz.com/weblog
>>> http://www.MobileMondayAustin.org
>>> http://www.AustinWirelessAlliance.org
>>>
>>> ===========================================================================
>>>
>>> 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".
>
> --------------------------------
> Spam/Virus scanning by CanIt Pro
>
> For more information see
> http://www.kgbinternet.com/SpamFilter.htm
>
> To control your spam filter, log in at
> http://filter.kgbinternet.com
>
>
--
C. Enrique Ortiz
eortiz@j2medeveloper.com
512-635-4225
http://www.CEnriqueOrtiz.com
http://www.CEnriqueOrtiz.com/weblog
http://www.MobileMondayAustin.org
http://www.AustinWirelessAlliance.org
===========================================================================
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".
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 14, 2007 7:53 AM
in response to: C. Enrique Ortiz
|
|
|
>I think there needs to be a more granulated communication from the os to the...
Actually, there is an infinite list of things that could cause the midlet to be interrupted... for example, incoming bluetooth connection, switch to mp3 player, switch to browser (possible in se phones), etc.
Also, while we're on the topic I notice that some SE phones call hideNotify when you change the volume. Rather annoying when you play a game, each time you turn down the music it pops up with the interrupt menu.
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 14, 2007 8:01 AM
in response to: captainfreedom
|
|
|
One way to go around this is to allow for a time to pass since the
hideNotify is called before starting releasing resources, to avoid
situations where some minor event interfeers, and the showNotify is
called shortly after hideNotify.
meinterest@MOBILEANDEMBEDDED.ORG wrote:
>> I think there needs to be a more granulated communication from the os to the...
>>
>
> Actually, there is an infinite list of things that could cause the midlet to be interrupted... for example, incoming bluetooth connection, switch to mp3 player, switch to browser (possible in se phones), etc.
>
> Also, while we're on the topic I notice that some SE phones call hideNotify when you change the volume. Rather annoying when you play a game, each time you turn down the music it pops up with the interrupt menu.
> [Message sent by forum member 'captainfreedom' (captainfreedom)]
>
> http://forums.java.net/jive/thread.jspa?messageID=222160
>
> ===========================================================================
> 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".
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 14, 2007 8:33 AM
in response to: Adrian Valentin...
|
|
|
That wouldn't work. The time for the volume control interrupt to return could be longer than a phone call (it's possible to have very short phone calls)
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 14, 2007 4:43 PM
in response to: C. Enrique Ortiz
|
|
|
Granted I have not researched this issue, but here are my first thoughts.
We need something smarter here. I think it should be deprecated and replaced with a new more informative method, or reduced in scope to a set of well defined events to provide consistency across implementations and complemented with a new method for handling the more general non-life cycle events.
PauseApp does not provide enough information about why it was called for the developer to make smart implementation decisions.
In addition, there is not a hard definition for the “Paused� state and the application developer has no reliable way of differentiating what the device implementation considers an actively shared resource, a resource that can be shared, resources that is intended to be shared, or resources that cannot be shared.
In addition there is no way to negotiate which resources are “nice to have�, “must haves�, or if the MIDlet should have precedence or exclusive access to a resource.
Reducing resource usage is not something that can be done intelligently, partly because of the lack of information that is provided by pauseApp, but more so because hardware and resource management vary across devices.
Consider playing a multiplayer/networked game or streaming/downloading a relatively large file from a server. A pause and resume may not be viable in this case. How do I decide that I would rather continue playing my game or listening to my stream rather than taking a call from a vendor?
I think we should have something more informative in its place. I think Kim’s idea is a good approach.
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 14, 2007 11:32 PM
in response to: astrientlabs
|
|
|
It's also possible that the new KVMs that support MIDP3 are smart enough to handle all the resource allocation themselves without any intervention required by the midlet. Maybe that's why they are getting rid of it?
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 15, 2007 2:37 AM
in response to: astrientlabs
|
|
|
If their aim is reduce fragmentation, I think that is exactly what they
shouldn't do!
By all means deprecate functionality, but as soon as you start adding a
different mechanism for achieving the same result, you will break
compatability between midp1/2 and midp3.
Tbh I don't think any enhancements to the api should be considered, until
the cause of the platforms fragmentation has been isolated, and the
appropriate action taken. (e.g. shooting some of the people responsible!
=D )
----- Original Message -----
From: <meinterest@MOBILEANDEMBEDDED.ORG>
To: <KVM-INTEREST@JAVA.SUN.COM>
Sent: Friday, June 15, 2007 12:43 AM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Granted I have not researched this issue, but here are my first thoughts.
We need something smarter here. I think it should be deprecated and replaced
with a new more informative method, or reduced in scope to a set of well
defined events to provide consistency across implementations and
complemented with a new method for handling the more general non-life cycle
events.
PauseApp does not provide enough information about why it was called for the
developer to make smart implementation decisions.
In addition, there is not a hard definition for the “Paused� state and the
application developer has no reliable way of differentiating what the device
implementation considers an actively shared resource, a resource that can be
shared, resources that is intended to be shared, or resources that cannot be
shared.
In addition there is no way to negotiate which resources are “nice to have�,
“must haves�, or if the MIDlet should have precedence or exclusive access to
a resource.
Reducing resource usage is not something that can be done intelligently,
partly because of the lack of information that is provided by pauseApp, but
more so because hardware and resource management vary across devices.
Consider playing a multiplayer/networked game or streaming/downloading a
relatively large file from a server. A pause and resume may not be viable
in this case. How do I decide that I would rather continue playing my game
or listening to my stream rather than taking a call from a vendor?
I think we should have something more informative in its place. I think Kim’s
idea is a good approach.
[Message sent by forum member 'astrientlabs' (astrientlabs)]
http://forums.java.net/jive/thread.jspa?messageID=222292
===========================================================================
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".
________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp
===========================================================================
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".
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 15, 2007 3:03 AM
in response to: C. Enrique Ortiz
|
|
|
|
|
99% of applications will be ported any way so any lack of compatibility can be easily solved then and i don't see the need to do porting being reduced until there is a consistent j2me application platform across all devices that is strictly adhered to.
BREW allows for different events to be sent to the application and this functionality when interacting with the phone os would possibly make it easier to work around j2me implementations that do not play nice.
----- Original Message ----
From: Robin Chaddock <robin.chaddock@IPLAY.COM>
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Friday, 15 June, 2007 7:07:07 PM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
If their aim is reduce fragmentation, I think that is exactly what they
shouldn't do!
By all means deprecate functionality, but as soon as you start adding a
different mechanism for achieving the same result, you will break
compatability between midp1/2 and midp3.
Tbh I don't think any enhancements to the api should be considered, until
the cause of the platforms fragmentation has been isolated, and the
appropriate action taken. (e.g. shooting some of the people responsible!
=D )
----- Original Message -----
From: <meinterest@MOBILEANDEMBEDDED.ORG>
To: <KVM-INTEREST@JAVA.SUN.COM>
Sent: Friday, June 15, 2007 12:43 AM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Granted I have not researched this issue, but here are my first thoughts.
We need something smarter here. I think it should be deprecated and replaced
with a new more informative method, or reduced in scope to a set of well
defined events to provide consistency across implementations and
complemented with a new method for handling the more general non-life cycle
events.
PauseApp does not provide enough information about why it was called for the
developer to make smart implementation decisions.
In addition, there is not a hard definition for the “Paused� state and the
application developer has no reliable way of differentiating what the device
implementation considers an actively shared resource, a resource that can be
shared, resources that is intended to be shared, or resources that cannot be
shared.
In addition there is no way to negotiate which resources are “nice to have�,
“must haves�, or if the MIDlet should have precedence or exclusive access to
a resource.
Reducing resource usage is not something that can be done intelligently,
partly because of the lack of information that is provided by pauseApp, but
more so because hardware and resource management vary across devices.
Consider playing a multiplayer/networked game or streaming/downloading a
relatively large file from a server. A pause and resume may not be viable
in this case. How do I decide that I would rather continue playing my game
or listening to my stream rather than taking a call from a vendor?
I think we should have something more informative in its place. I think Kim’s
idea is a good approach.
[Message sent by forum member 'astrientlabs' (astrientlabs)]
http://forums.java.net/jive/thread.jspa?messageID=222292
===========================================================================
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".
________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp
===========================================================================
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".
_________________________________________________________________________________
Yahoo!7 Mail has just got even bigger and better with unlimited storage on all webmail accounts.
http://au.docs.yahoo.com/mail/unlimitedstorage.html
===========================================================================
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]
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 15, 2007 4:25 AM
in response to: Fly Home
|
|
|
|
|
I think you are missing the point of this thread; the impetus behind deprecating pauseApp() is to *reduce* handset incompatabilities, and consequently *simplify* porting.
----- Original Message -----
From: Fly Home
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Friday, June 15, 2007 11:03 AM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
99% of applications will be ported any way so any lack of compatibility can be easily solved then and i don't see the need to do porting being reduced until there is a consistent j2me application platform across all devices that is strictly adhered to.
BREW allows for different events to be sent to the application and this functionality when interacting with the phone os would possibly make it easier to work around j2me implementations that do not play nice.
----- Original Message ----
From: Robin Chaddock <robin.chaddock@IPLAY.COM>
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Friday, 15 June, 2007 7:07:07 PM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
If their aim is reduce fragmentation, I think that is exactly what they
shouldn't do!
By all means deprecate functionality, but as soon as you start adding a
different mechanism for achieving the same result, you will break
compatability between midp1/2 and midp3.
Tbh I don't think any enhancements to the api should be considered, until
the cause of the platforms fragmentation has been isolated, and the
appropriate action taken. (e.g. shooting some of the people responsible!
=D )
----- Original Message -----
From: <meinterest@MOBILEANDEMBEDDED.ORG>
To: <KVM-INTEREST@JAVA.SUN.COM>
Sent: Friday, June 15, 2007 12:43 AM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Granted I have not researched this issue, but here are my first thoughts.
We need something smarter here. I think it should be deprecated and replaced
with a new more informative method, or reduced in scope to a set of well
defined events to provide consistency across implementations and
complemented with a new method for handling the more general non-life cycle
events.
PauseApp does not provide enough information about why it was called for the
developer to make smart implementation decisions.
In addition, there is not a hard definition for the “Paused� state and the
application developer has no reliable way of differentiating what the device
implementation considers an actively shared resource, a resource that can be
shared, resources that is intended to be shared, or resources that cannot be
shared.
In addition there is no way to negotiate which resources are “nice to have�,
“must haves�, or if the MIDlet should have precedence or exclusive access to
a resource.
Reducing resource usage is not something that can be done intelligently,
partly because of the lack of information that is provided by pauseApp, but
more so because hardware and resource management vary across devices.
Consider playing a multiplayer/networked game or streaming/downloading a
relatively large file from a server. A pause and resume may not be viable
in this case. How do I decide that I would rather continue playing my game
or listening to my stream rather than taking a call from a vendor?
I think we should have something more informative in its place. I think Kim’s
idea is a good approach.
[Message sent by forum member 'astrientlabs' (astrientlabs)]
http://forums.java.net/jive/thread.jspa?messageID=222292
===========================================================================
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".
________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp
===========================================================================
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".
------------------------------------------------------------------------------
Yahoo!7 Mail has just got even bigger and better with unlimited storage on all webmail accounts. Find out more. =========================================================================== 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".
________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp
===========================================================================
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]
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 15, 2007 8:23 AM
in response to: Robin Chaddock
|
|
|
|
|
pauseApp is just a life-cycle signal that the application will go
passive, with a suggested behavior to release resources.
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."
Handset capabilities will continue to increase, but not all platforms
are created equal: some will continue to be
embedded/resource-constrained platforms, and we should not remove this
primitive signal.
The problem w/ pauseApp is not pauseApp, but all those definitions and
assumptions that have evolved over the years. If you treat pauseApp as
just that, a life-cycle signal, there is no source of issues or
fragmentation.
While MIDP3 is defining a system event/state API, the primitive
life-cycle methods should be kept.
Instead, let's address the interpretation issue. pauseApp is just one
of many interpretation issues. pauseApp is the trivial one (in my opinion).
ceo
Robin Chaddock wrote:
> I think you are missing the point of this thread; the impetus behind
> deprecating pauseApp() is to *reduce* handset incompatabilities,
> and consequently *simplify* porting.
>
>
> ----- Original Message -----
> *From:* Fly Home <mailto:vedanuzal@YAHOO.COM.AU>
> *To:* KVM-INTEREST@JAVA.SUN.COM <mailto:KVM-INTEREST@JAVA.SUN.COM>
> *Sent:* Friday, June 15, 2007 11:03 AM
> *Subject:* Re: MIDP3 Proposal to remove the MIDlet pauseApp()
> lifecycle method
>
> 99% of applications will be ported any way so any lack of
> compatibility can be easily solved then and i don't see the need
> to do porting being reduced until there is a consistent j2me
> application platform across all devices that is strictly adhered to.
>
> BREW allows for different events to be sent to the application and
> this functionality when interacting with the phone os would
> possibly make it easier to work around j2me implementations that
> do not play nice.
>
> ----- Original Message ----
> From: Robin Chaddock <robin.chaddock@IPLAY.COM>
> To: KVM-INTEREST@JAVA.SUN.COM
> Sent: Friday, 15 June, 2007 7:07:07 PM
> Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp()
> lifecycle method
>
> If their aim is reduce fragmentation, I think that is exactly what
> they
> shouldn't do!
>
> By all means deprecate functionality, but as soon as you start
> adding a
> different mechanism for achieving the same result, you will break
> compatability between midp1/2 and midp3.
>
> Tbh I don't think any enhancements to the api should be
> considered, until
> the cause of the platforms fragmentation has been isolated, and the
> appropriate action taken. (e.g. shooting some of the people
> responsible!
> =D )
>
>
> ----- Original Message -----
> From: <meinterest@MOBILEANDEMBEDDED.ORG>
> To: <KVM-INTEREST@JAVA.SUN.COM>
> Sent: Friday, June 15, 2007 12:43 AM
> Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp()
> lifecycle method
>
>
> Granted I have not researched this issue, but here are my first
> thoughts.
>
> We need something smarter here. I think it should be deprecated
> and replaced
> with a new more informative method, or reduced in scope to a set
> of well
> defined events to provide consistency across implementations and
> complemented with a new method for handling the more general
> non-life cycle
> events.
>
> PauseApp does not provide enough information about why it was
> called for the
> developer to make smart implementation decisions.
>
> In addition, there is not a hard definition for the “Paused� state
> and the
> application developer has no reliable way of differentiating what
> the device
> implementation considers an actively shared resource, a resource
> that can be
> shared, resources that is intended to be shared, or resources that
> cannot be
> shared.
>
> In addition there is no way to negotiate which resources are “nice
> to have�,
> “must haves�, or if the MIDlet should have precedence or exclusive
> access to
> a resource.
>
> Reducing resource usage is not something that can be done
> intelligently,
> partly because of the lack of information that is provided by
> pauseApp, but
> more so because hardware and resource management vary across devices.
>
> Consider playing a multiplayer/networked game or
> streaming/downloading a
> relatively large file from a server. A pause and resume may not
> be viable
> in this case. How do I decide that I would rather continue
> playing my game
> or listening to my stream rather than taking a call from a vendor?
>
> I think we should have something more informative in its place. I
> think Kim’s
> idea is a good approach.
> [Message sent by forum member 'astrientlabs' (astrientlabs)]
>
> http://forums.java.net/jive/thread.jspa?messageID=222292
>
> ===========================================================================
> 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".
>
>
>
> ________________________________________________________________________
> E-mail is an informal method of communication and may be subject
> to data corruption, interception and unauthorised amendment for
> which I-play, a trading name of Digital Bridges Ltd will accept no
> liability. Therefore, it will normally be inappropriate to rely on
> information contained on e-mail without obtaining written
> confirmation.
>
> This e-mail may contain confidential and/or privileged
> information. If you are not the intended recipient (or have
> received this e-mail in error) please notify the sender
> immediately and destroy this e-mail. Any unauthorized copying,
> disclosure or distribution of the material in this e-mail is
> strictly forbidden.
>
> (C) 2005. I-play is a trademark and trading name of Digital
> Bridges Limited. All Rights Reserved.
> ________________________________________________________________________
> This message has been checked for all known viruses by the
> MessageLabs Virus Scanning Service. For further information visit
> http://www.messagelabs.com/stats.asp
>
> ===========================================================================
> 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".
>
>
> ------------------------------------------------------------------------
> Yahoo!7 Mail has just got even bigger and better with unlimited
> storage on all webmail accounts. Find out more
> <http://.
> ===========================================================================
> 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".
>
>
> ________________________________________________________________________
> E-mail is an informal method of communication and may be subject to
> data corruption, interception and unauthorised amendment for which
> I-play, a trading name of Digital Bridges Ltd will accept no
> liability. Therefore, it will normally be inappropriate to rely on
> information contained on e-mail without obtaining written confirmation.
>
> This e-mail may contain confidential and/or privileged information. If
> you are not the intended recipient (or have received this e-mail in
> error) please notify the sender immediately and destroy this e-mail.
> Any unauthorized copying, disclosure or distribution of the material
> in this e-mail is strictly forbidden.
>
> (C) 2005. I-play is a trademark and trading name of Digital Bridges
> Limited. All Rights Reserved.
> ________________________________________________________________________
> This message has been checked for all known viruses by the
> MessageLabs Virus Scanning Service. For further information visit
> http://www.messagelabs.com/stats.asp
>
> --------------------------------
>
>
> Spam/Virus scanning by CanIt Pro
>
> For more information see http://www.kgbinternet.com/SpamFilter.htm
>
> To control your spam filter, log in at http://filter.kgbinternet.com
>
> ===========================================================================
> 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]
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 15, 2007 8:15 AM
in response to: C. Enrique Ortiz
|
|
|
|
|
While I understand that this is the goal I am currently employed porting j2me games and in my experience the biggest hurdle to reducing porting in this area is not depreciating pauseApp() although this would not matter for j2me games much as most if not all of the games that i have ported just call hidenotify() in the pauseApp() method.
The biggest hurdle in this area is the implementation of the KVM on the handset, so until this is solved any modification in the specification will have little or no effect to the amount of porting required. A recent example was that for a game that I was porting to the Nokia N73 is that the audio was actually deing stopped before letting the j2me game know what it was doing so that the code the developer had written in hidenotify() never got executed as the state of the player had already changed.
And that is mild compared to stopping the KVM entirely like some manufacturers and not telling the KVM anything that's going on.
So from a software engineer who ports j2me applications daily it may be of some help but will have no great effect on reducing the incompatibilities between handsets, the quality of the KVM on the device and the design of the Application itself are the major factors that determine how much an application needs to be ported.
----- Original Message ----
From: Robin Chaddock <robin.chaddock@IPLAY.COM>
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Friday, 15 June, 2007 8:55:58 PM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
DIV {
MARGIN:0px;}
I think you are missing the point of this thread;
the impetus behind deprecating pauseApp() is to *reduce* handset
incompatabilities, and consequently *simplify* porting.
----- Original Message -----
From:
Fly
Home
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Friday, June 15, 2007 11:03
AM
Subject: Re: MIDP3 Proposal to remove the
MIDlet pauseApp() lifecycle method
99%
of applications will be ported any way so any lack of compatibility can be
easily solved then and i don't see the need to do porting being reduced until
there is a consistent j2me application platform across all devices that is
strictly adhered to.
BREW allows for different events to be sent to the
application and this functionality when interacting with the phone os would
possibly make it easier to work around j2me implementations that do not play
nice.
-----
Original Message ----
From: Robin Chaddock
<robin.chaddock@IPLAY.COM>
To: KVM-INTEREST@JAVA.SUN.COM
Sent:
Friday, 15 June, 2007 7:07:07 PM
Subject: Re: MIDP3 Proposal to remove the
MIDlet pauseApp() lifecycle method
If their aim is reduce fragmentation, I think that is exactly what
they
shouldn't do!
By all means deprecate functionality, but as soon
as you start adding a
different mechanism for achieving the same result,
you will break
compatability between midp1/2 and midp3.
Tbh I don't
think any enhancements to the api should be considered, until
the cause of
the platforms fragmentation has been isolated, and the
appropriate action
taken. (e.g. shooting some of the people responsible!
=D )
-----
Original Message -----
From:
<meinterest@MOBILEANDEMBEDDED.ORG>
To:
<KVM-INTEREST@JAVA.SUN.COM>
Sent: Friday, June 15, 2007 12:43
AM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle
method
Granted I have not researched this issue, but here are my
first thoughts.
We need something smarter here. I think it should be
deprecated and replaced
with a new more informative method, or reduced in
scope to a set of well
defined events to provide consistency across
implementations and
complemented with a new method for handling the more
general non-life cycle
events.
PauseApp does not provide enough
information about why it was called for the
developer to make smart
implementation decisions.
In addition, there is not a hard definition
for the “Paused� state and the
application developer has no reliable way of
differentiating what the device
implementation considers an actively shared
resource, a resource that can be
shared, resources that is intended to be
shared, or resources that cannot be
shared.
In addition there is no
way to negotiate which resources are “nice to have�,
“must haves�, or if
the MIDlet should have precedence or exclusive access to
a
resource.
Reducing resource usage is not something that can be done
intelligently,
partly because of the lack of information that is provided
by pauseApp, but
more so because hardware and resource management vary
across devices.
Consider playing a multiplayer/networked game or
streaming/downloading a
relatively large file from a server. A
pause and resume may not be viable
in this case. How do I decide
that I would rather continue playing my game
or listening to my stream
rather than taking a call from a vendor?
I think we should have
something more informative in its place. I think Kim’s
idea is a good
approach.
[Message sent by forum member 'astrientlabs'
(astrientlabs)]
http://forums.java.net/jive/thread.jspa?messageID=222292
===========================================================================
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".
________________________________________________________________________
E-mail
is an informal method of communication and may be subject to data corruption,
interception and unauthorised amendment for which I-play, a trading name of
Digital Bridges Ltd will accept no liability. Therefore, it will normally be
inappropriate to rely on information contained on e-mail without obtaining
written confirmation.
This e-mail may contain confidential and/or
privileged information. If you are not the intended recipient (or have
received this e-mail in error) please notify the sender immediately and
destroy this e-mail. Any unauthorized copying, disclosure or distribution of
the material in this e-mail is strictly forbidden.
(C) 2005. I-play is
a trademark and trading name of Digital Bridges Limited. All Rights
Reserved.
________________________________________________________________________
This
message has been checked for all known viruses by the
MessageLabs Virus
Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp
===========================================================================
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".
Yahoo!7 Mail has just got even bigger and better with unlimited storage on all
webmail accounts. Find
out more.
=========================================================================== 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".
________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp
===========================================================================
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".
Send instant messages to your online friends http://au.messenger.yahoo.com
===========================================================================
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]
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 15, 2007 10:16 AM
in response to: C. Enrique Ortiz
|
|
|
|
|
The first question is what problem are we trying to solve? If the
problem is device fragmentation the answer is extremely simple. Sun
Microsystems must actually start doing its job and verify that OEM
implementations of the MIDP API are followed. Its plainly and painfully
obvious that Sun is allow OEMs to ship whatever they feel like in
regards to the interrupt callback methods. Some OEMs ship devices which
do not even call a single callback on interrupt at all.
Personally I don't believe there is any use in complicating the system
by adding additional information about the callbacks as BREW does. Who
cares if it is an SMS interrupt or a phone call interrupt, especially if
it isn't going to give us any other information such as the contents of
the SMS or an audio stream to the phone call. There is certainly no
reason to make the system more complex if OEMs are going to continue to
do as they please. Device fragmentation will only become worse as the
devices have more ways in differentiating themselves by implementing the
API differently.
The solution has little to do with modifying the API and much more to do
with fixing Sun Microsystems model of any virtual machine implementation
will pass Sun standards (or lack thereof). Sun must be more strict and
scrutinize OEMs better if they are going to make our lives any easier.
Until they accomplish that any new features they add to the MIDP
specifications are merely a tease, because most OEM implementations will
be completely broken and utterly useless.
Jacob
________________________________
From: A mailing list for KVM discussion
[mailto:KVM-INTEREST@JAVA.SUN.COM] On Behalf Of C. Enrique Ortiz
Sent: Friday, June 15, 2007 8:23 AM
To: KVM-INTEREST@JAVA.SUN.COM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp()
lifecycle method
pauseApp is just a life-cycle signal that the application will
go passive, with a suggested behavior to release resources.
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."
Handset capabilities will continue to increase, but not all
platforms are created equal: some will continue to be
embedded/resource-constrained platforms, and we should not remove this
primitive signal.
The problem w/ pauseApp is not pauseApp, but all those
definitions and assumptions that have evolved over the years. If you
treat pauseApp as just that, a life-cycle signal, there is no source of
issues or fragmentation.
While MIDP3 is defining a system event/state API, the primitive
life-cycle methods should be kept.
Instead, let's address the interpretation issue. pauseApp is
just one of many interpretation issues. pauseApp is the trivial one (in
my opinion).
ceo
Robin Chaddock wrote:
I think you are missing the point of this thread; the
impetus behind deprecating pauseApp() is to *reduce* handset
incompatabilities, and consequently *simplify* porting.
----- Original Message -----
From: Fly Home <mailto:vedanuzal@YAHOO.COM.AU>
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Friday, June 15, 2007 11:03 AM
Subject: Re: MIDP3 Proposal to remove the MIDlet
pauseApp() lifecycle method
99% of applications will be ported any way so
any lack of compatibility can be easily solved then and i don't see the
need to do porting being reduced until there is a consistent j2me
application platform across all devices that is strictly adhered to.
BREW allows for different events to be sent to
the application and this functionality when interacting with the phone
os would possibly make it easier to work around j2me implementations
that do not play nice.
----- Original Message ----
From: Robin Chaddock <robin.chaddock@IPLAY.COM>
<mailto:robin.chaddock@IPLAY.COM>
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Friday, 15 June, 2007 7:07:07 PM
Subject: Re: MIDP3 Proposal to remove the MIDlet
pauseApp() lifecycle method
If their aim is reduce fragmentation, I think
that is exactly what they
shouldn't do!
By all means deprecate functionality, but as
soon as you start adding a
different mechanism for achieving the same
result, you will break
compatability between midp1/2 and midp3.
Tbh I don't think any enhancements to the api
should be considered, until
the cause of the platforms fragmentation has
been isolated, and the
appropriate action taken. (e.g. shooting some of
the people responsible!
=D )
----- Original Message -----
From: <meinterest@MOBILEANDEMBEDDED.ORG>
<mailto:meinterest@MOBILEANDEMBEDDED.ORG>
To: <KVM-INTEREST@JAVA.SUN.COM>
<mailto:KVM-INTEREST@JAVA.SUN.COM>
Sent: Friday, June 15, 2007 12:43 AM
Subject: Re: MIDP3 Proposal to remove the MIDlet
pauseApp() lifecycle method
Granted I have not researched this issue, but
here are my first thoughts.
We need something smarter here. I think it
should be deprecated and replaced
with a new more informative method, or reduced
in scope to a set of well
defined events to provide consistency across
implementations and
complemented with a new method for handling the
more general non-life cycle
events.
PauseApp does not provide enough information
about why it was called for the
developer to make smart implementation
decisions.
In addition, there is not a hard definition for
the "Paused" state and the
application developer has no reliable way of
differentiating what the device
implementation considers an actively shared
resource, a resource that can be
shared, resources that is intended to be shared,
or resources that cannot be
shared.
In addition there is no way to negotiate which
resources are "nice to have",
"must haves", or if the MIDlet should have
precedence or exclusive access to
a resource.
Reducing resource usage is not something that
can be done intelligently,
partly because of the lack of information that
is provided by pauseApp, but
more so because hardware and resource management
vary across devices.
Consider playing a multiplayer/networked game or
streaming/downloading a
relatively large file from a server. A pause and
resume may not be viable
in this case. How do I decide that I would
rather continue playing my game
or listening to my stream rather than taking a
call from a vendor?
I think we should have something more
informative in its place. I think Kim's
idea is a good approach.
[Message sent by forum member 'astrientlabs'
(astrientlabs)]
http://forums.java.net/jive/thread.jspa?messageID=222292
========================================================================
===
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".
________________________________________________________________________
E-mail is an informal method of communication
and may be subject to data corruption, interception and unauthorised
amendment for which I-play, a trading name of Digital Bridges Ltd will
accept no liability. Therefore, it will normally be inappropriate to
rely on information contained on e-mail without obtaining written
confirmation.
This e-mail may contain confidential and/or
privileged information. If you are not the intended recipient (or have
received this e-mail in error) please notify the sender immediately and
destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
(C) 2005. I-play is a trademark and trading name
of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known
viruses by the
MessageLabs Virus Scanning Service. For further
information visit
http://www.messagelabs.com/stats.asp
========================================================================
===
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".
________________________________
Yahoo!7 Mail has just got even bigger and better
with unlimited storage on all webmail accounts. Find out more
<http:// .
========================================================================
=== 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".
________________________________________________________________________
E-mail is an informal method of communication and may be
subject to data corruption, interception and unauthorised amendment for
which I-play, a trading name of Digital Bridges Ltd will accept no
liability. Therefore, it will normally be inappropriate to rely on
information contained on e-mail without obtaining written confirmation.
This e-mail may contain confidential and/or privileged
information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy
this e-mail. Any unauthorized copying, disclosure or distribution of the
material in this e-mail is strictly forbidden.
(C) 2005. I-play is a trademark and trading name of
Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by
the
MessageLabs Virus Scanning Service. For further
information visit
http://www.messagelabs.com/stats.asp
--------------------------------
Spam/Virus scanning by CanIt Pro
For more information see
http://www.kgbinternet.com/SpamFilter.htm
To control your spam filter, log in at
http://filter.kgbinternet.com
========================================================================
=== 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]
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 16, 2007 5:17 AM
in response to: Jacob Abrams
|
|
|
|
|
[att1.html]
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 16, 2007 5:25 AM
in response to: Robin Chaddock
|
|
|
This reminds me of a thread about 1 or 2 years ago, not sure if anyone at
sun picked up on it then 
On 16/6/07 20:17, "Robin Chaddock" <robin.chaddock@IPLAY.COM> wrote:
> Well said, now if only the appropriate people in Sun were subscribers to this
> mailing list.....
>
> Jacob Abrams wrote:
>>
>> The first question is what problem are we trying to solve? If the problem is
>> device fragmentation the answer is extremely simple. Sun Microsystems must
>> actually start doing its job and verify that OEM implementations of the MIDP
>> API are followed. Its plainly and painfully obvious that Sun is allow OEMs to
>> ship whatever they feel like in regards to the interrupt callback methods.
>> Some OEMs ship devices which do not even call a single callback on interrupt
>> at all.
>>
>>
>>
>> Personally I don't believe there is any use in complicating the system by
>> adding additional information about the callbacks as BREW does. Who cares if
>> it is an SMS interrupt or a phone call interrupt, especially if it isn't
>> going
>> to give us any other information such as the contents of the SMS or an audio
>> stream to the phone call. There is certainly no reason to make the system
>> more
>> complex if OEMs are going to continue to do as they please. Device
>> fragmentation will only become worse as the devices have more ways in
>> differentiating themselves by implementing the API differently.
>>
>>
>>
>> The solution has little to do with modifying the API and much more to do with
>> fixing Sun Microsystems model of any virtual machine implementation will pass
>> Sun standards (or lack thereof). Sun must be more strict and scrutinize OEMs
>> better if they are going to make our lives any easier. Until they accomplish
>> that any new features they add to the MIDP specifications are merely a tease,
>> because most OEM implementations will be completely broken and utterly
>> useless.
>>
>>
>>
>> Jacob
>>
>>
>>>
>>>
>>>
>>> From: A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM]
>>> On Behalf Of C. Enrique Ortiz
>>> Sent: Friday, June 15, 2007 8:23 AM
>>> To: KVM-INTEREST@JAVA.SUN.COM
>>> Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle
>>> method
>>>
>>>
>>>
>>> pauseApp is just a life-cycle signal that the application will go passive,
>>> with a suggested behavior to release resources.
>>>
>>> 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."
>>>
>>> Handset capabilities will continue to increase, but not all platforms are
>>> created equal: some will continue to be embedded/resource-constrained
>>> platforms, and we should not remove this primitive signal.
>>>
>>> The problem w/ pauseApp is not pauseApp, but all those definitions and
>>> assumptions that have evolved over the years. If you treat pauseApp as just
>>> that, a life-cycle signal, there is no source of issues or fragmentation.
>>>
>>> While MIDP3 is defining a system event/state API, the primitive life-cycle
>>> methods should be kept.
>>>
>>> Instead, let's address the interpretation issue. pauseApp is just one of
>>> many
>>> interpretation issues. pauseApp is the trivial one (in my opinion).
>>>
>>> ceo
>>>
>>> Robin Chaddock wrote:
>>>>
>>>> I think you are missing the point of this thread; the impetus behind
>>>> deprecating pauseApp() is to *reduce* handset incompatabilities, and
>>>> consequently *simplify* porting.
>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>
>>>>> From: Fly Home <mailto:vedanuzal@YAHOO.COM.AU>
>>>>>
>>>>> To: KVM-INTEREST@JAVA.SUN.COM
>>>>>
>>>>> Sent: Friday, June 15, 2007 11:03 AM
>>>>>
>>>>> Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle
>>>>> method
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 99% of applications will be ported any way so any lack of compatibility
>>>>> can
>>>>> be easily solved then and i don't see the need to do porting being reduced
>>>>> until there is a consistent j2me application platform across all devices
>>>>> that is strictly adhered to.
>>>>>
>>>>> BREW allows for different events to be sent to the application and this
>>>>> functionality when interacting with the phone os would possibly make it
>>>>> easier to work around j2me implementations that do not play nice.
>>>>>
>>>>>
>>>>> ----- Original Message ----
>>>>> From: Robin Chaddock <robin.chaddock@IPLAY.COM>
>>>>> <mailto:robin.chaddock@IPLAY.COM>
>>>>> To: KVM-INTEREST@JAVA.SUN.COM
>>>>> Sent: Friday, 15 June, 2007 7:07:07 PM
>>>>> Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle
>>>>> method
>>>>>
>>>>>
>>>>> If their aim is reduce fragmentation, I think that is exactly what they
>>>>> shouldn't do!
>>>>>
>>>>> By all means deprecate functionality, but as soon as you start adding a
>>>>> different mechanism for achieving the same result, you will break
>>>>> compatability between midp1/2 and midp3.
>>>>>
>>>>> Tbh I don't think any enhancements to the api should be considered, until
>>>>> the cause of the platforms fragmentation has been isolated, and the
>>>>> appropriate action taken. (e.g. shooting some of the people responsible!
>>>>> =D )
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: <meinterest@MOBILEANDEMBEDDED.ORG>
>>>>> <mailto:meinterest@MOBILEANDEMBEDDED.ORG>
>>>>> To: <KVM-INTEREST@JAVA.SUN.COM> <mailto:KVM-INTEREST@JAVA.SUN.COM>
>>>>> Sent: Friday, June 15, 2007 12:43 AM
>>>>> Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle
>>>>> method
>>>>>
>>>>>
>>>>> Granted I have not researched this issue, but here are my first thoughts.
>>>>>
>>>>> We need something smarter here. I think it should be deprecated and
>>>>> replaced
>>>>> with a new more informative method, or reduced in scope to a set of well
>>>>> defined events to provide consistency across implementations and
>>>>> complemented with a new method for handling the more general non-life
>>>>> cycle
>>>>> events.
>>>>>
>>>>> PauseApp does not provide enough information about why it was called for
>>>>> the
>>>>> developer to make smart implementation decisions.
>>>>>
>>>>> In addition, there is not a hard definition for the ³Paused² state and the
>>>>> application developer has no reliable way of differentiating what the
>>>>> device
>>>>> implementation considers an actively shared resource, a resource that can
>>>>> be
>>>>> shared, resources that is intended to be shared, or resources that cannot
>>>>> be
>>>>> shared.
>>>>>
>>>>> In addition there is no way to negotiate which resources are ³nice to
>>>>> have²,
>>>>> ³must haves², or if the MIDlet should have precedence or exclusive access
>>>>> to
>>>>> a resource.
>>>>>
>>>>> Reducing resource usage is not something that can be done intelligently,
>>>>> partly because of the lack of information that is provided by pauseApp,
>>>>> but
>>>>> more so because hardware and resource management vary across devices.
>>>>>
>>>>> Consider playing a multiplayer/networked game or streaming/downloading a
>>>>> relatively large file from a server. A pause and resume may not be viable
>>>>> in this case. How do I decide that I would rather continue playing my game
>>>>> or listening to my stream rather than taking a call from a vendor?
>>>>>
>>>>> I think we should have something more informative in its place. I think
>>>>> Kim¹s
>>>>> idea is a good approach.
>>>>> [Message sent by forum member 'astrientlabs' (astrientlabs)]
>>>>>
>>>>> http://forums.java.net/jive/thread.jspa?messageID=222292
>>>>>
>>>>>
==========================================================================>>>>>
=
>>>>> 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".
>>>>>
>>>>>
>>>>>
>>>>> ________________________________________________________________________
>>>>> E-mail is an informal method of communication and may be subject to data
>>>>> corruption, interception and unauthorised amendment for which I-play, a
>>>>> trading name of Digital Bridges Ltd will accept no liability. Therefore,
>>>>> it
>>>>> will normally be inappropriate to rely on information contained on e-mail
>>>>> without obtaining written confirmation.
>>>>>
>>>>> This e-mail may contain confidential and/or privileged information. If you
>>>>> are not the intended recipient (or have received this e-mail in error)
>>>>> please notify the sender immediately and destroy this e-mail. Any
>>>>> unauthorized copying, disclosure or distribution of the material in this
>>>>> e-mail is strictly forbidden.
>>>>>
>>>>> (C) 2005. I-play is a trademark and trading name of Digital Bridges
>>>>> Limited. All Rights Reserved.
>>>>> ________________________________________________________________________
>>>>> This message has been checked for all known viruses by the
>>>>> MessageLabs Virus Scanning Service. For further information visit
>>>>> http://www.messagelabs.com/stats.asp
>>>>>
>>>>>
==========================================================================>>>>>
=
>>>>> 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".
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Yahoo!7 Mail has just got even bigger and better with unlimited storage
>>>>> on
>>>>> all webmail accounts. Find out more
>>>>> <http:// .
>>>>> ==========================================================================
>>>>> =
>>>>> 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".
>>>>
>>>> ________________________________________________________________________
>>>> E-mail is an informal method of communication and may be subject to data
>>>> corruption, interception and unauthorised amendment for which I-play, a
>>>> trading name of Digital Bridges Ltd will accept no liability. Therefore, it
>>>> will normally be inappropriate to rely on information contained on e-mail
>>>> without obtaining written confirmation.
>>>>
>>>> This e-mail may contain confidential and/or privileged information. If you
>>>> are not the intended recipient (or have received this e-mail in error)
>>>> please notify the sender immediately and destroy this e-mail. Any
>>>> unauthorized copying, disclosure or distribution of the material in this
>>>> e-mail is strictly forbidden.
>>>>
>>>> (C) 2005. I-play is a trademark and trading name of Digital Bridges
>>>> Limited.
>>>> All Rights Reserved.
>>>> ________________________________________________________________________
>>>> This message has been checked for all known viruses by the
>>>> MessageLabs Virus Scanning Service. For further information visit
>>>> http://www.messagelabs.com/stats.asp
>>>>
>>>>
>>>> --------------------------------
>>>>
>>>> Spam/Virus scanning by CanIt Pro
>>>>
>>>> For more information see http://www.kgbinternet.com/SpamFilter.htm
>>>>
>>>>
>>>> To control your spam filter, log in at http://filter.kgbinternet.com
>>>> ===========================================================================
>>>> 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".
>
>
> ________________________________________________________________________
> E-mail is an informal method of communication and may be subject to data
> corruption, interception and unauthorised amendment for which I-play, a
> trading name of Digital Bridges Ltd will accept no liability. Therefore, it
> will normally be inappropriate to rely on information contained on e-mail
> without obtaining written confirmation.
>
> This e-mail may contain confidential and/or privileged information. If you are
> not the intended recipient (or have received this e-mail in error) please
> notify the sender immediately and destroy this e-mail. Any unauthorized
> copying, disclosure or distribution of the material in this e-mail is strictly
> forbidden.
>
> (C) 2005. I-play is a trademark and trading name of Digital Bridges Limited.
> All Rights Reserved.
> ________________________________________________________________________
> This message has been checked for all known viruses by the
> MessageLabs Virus Scanning Service. For further information visit
> http://www.messagelabs.com/stats.asp
> =========================================================================== 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".
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 16, 2007 5:37 AM
in response to: Robin Chaddock
|
|
|
Yes, there are many Sun subscribers on this list that
want to see MIDP3 spec be the best it can be.
Yes, some specifications have not been clear enough
and greater effort should be given when the specs are
written and reviewed.
Yes, some TCKs have not been thorough enough in
writing tests that would cover the key functionality to
verify it has been supported in a spec compliant manner.
It is the spec lead's responsibility to shepherd the process
and the expert group as a spec comes together. It is the
JCP community at large that supplies members for
the expert group and it is the community at large that
has opportunities to comment and challenge parts of any
specification as it becomes final.
Having spec compliant implementations as verified by
the JSR specific TCK is all that can be expected.
Robin Chaddock wrote:
> Well said, now if only the appropriate people in Sun were subscribers
> to this mailing list.....
>
> Jacob Abrams wrote:
>> The first question is what problem are we trying to solve? If the
>> problem is device fragmentation the answer is extremely simple. Sun
>> Microsystems must actually start doing its job and verify that OEM
>> implementations of the MIDP API are followed. Its plainly and
>> painfully obvious that Sun is allow OEMs to ship whatever they feel
>> like in regards to the interrupt callback methods. Some OEMs ship
>> devices which do not even call a single callback on interrupt at all.
>> Personally I don't believe there is any use in complicating the
>> system by adding additional information about the callbacks as BREW
>> does. Who cares if it is an SMS interrupt or a phone call interrupt,
>> especially if it isn't going to give us any other information such as
>> the contents of the SMS or an audio stream to the phone call. There
>> is certainly no reason to make the system more complex if OEMs are
>> going to continue to do as they please. Device fragmentation will
>> only become worse as the devices have more ways in differentiating
>> themselves by implementing the API differently.
>> The solution has little to do with modifying the API and much more to
>> do with fixing Sun Microsystems model of any virtual machine
>> implementation will pass Sun standards (or lack thereof). Sun must be
>> more strict and scrutinize OEMs better if they are going to make our
>> lives any easier. Until they accomplish that any new features they
>> add to the MIDP specifications are merely a tease, because most OEM
>> implementations will be completely broken and utterly useless.
>> Jacob
>>
>> *From:* A mailing list for KVM discussion
>> [mailto:KVM-INTEREST@JAVA.SUN.COM] *On Behalf Of *C. Enrique Ortiz
>> *Sent:* Friday, June 15, 2007 8:23 AM
>> *To:* KVM-INTEREST@JAVA.SUN.COM <mailto:KVM-INTEREST@JAVA.SUN.COM>
>> *Subject:* Re: MIDP3 Proposal to remove the MIDlet pauseApp()
>> lifecycle method
>>
>>
>> pauseApp is just a life-cycle signal that the application will go
>> passive, with a suggested behavior to release resources.
>>
>> 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."
>>
>> Handset capabilities will continue to increase, but not all
>> platforms are created equal: some will continue to be
>> embedded/resource-constrained platforms, and we should not remove
>> this primitive signal.
>>
>> The problem w/ pauseApp is not pauseApp, but all those
>> definitions and assumptions that have evolved over the years. If
>> you treat pauseApp as just that, a life-cycle signal, there is no
>> source of issues or fragmentation.
>>
>> While MIDP3 is defining a system event/state API, the primitive
>> life-cycle methods should be kept.
>>
>> Instead, let's address the interpretation issue. pauseApp is just
>> one of many interpretation issues. pauseApp is the trivial one
>> (in my opinion).
>>
>> ceo
>>
>> Robin Chaddock wrote:
>>> I think you are missing the point of this thread; the impetus
>>> behind deprecating pauseApp() is to *reduce* handset
>>> incompatabilities, and consequently *simplify* porting.
>>>
>>> ----- Original Message -----
>>> *From:* Fly Home <mailto:vedanuzal@YAHOO.COM.AU>
>>> *To:* KVM-INTEREST@JAVA.SUN.COM
>>> <mailto:KVM-INTEREST@JAVA.SUN.COM>
>>> *Sent:* Friday, June 15, 2007 11:03 AM
>>> *Subject:* Re: MIDP3 Proposal to remove the MIDlet
>>> pauseApp() lifecycle method
>>>
>>> 99% of applications will be ported any way so any lack of
>>> compatibility can be easily solved then and i don't see the
>>> need to do porting being reduced until there is a consistent
>>> j2me application platform across all devices that is
>>> strictly adhered to.
>>>
>>> BREW allows for different events to be sent to the
>>> application and this functionality when interacting with the
>>> phone os would possibly make it easier to work around j2me
>>> implementations that do not play nice.
>>>
>>> ----- Original Message ----
>>> From: Robin Chaddock <robin.chaddock@IPLAY.COM>
>>> <mailto:robin.chaddock@IPLAY.COM>
>>> To: KVM-INTEREST@JAVA.SUN.COM <mailto:KVM-INTEREST@JAVA.SUN.COM>
>>> Sent: Friday, 15 June, 2007 7:07:07 PM
>>> Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp()
>>> lifecycle method
>>>
>>> If their aim is reduce fragmentation, I think that is
>>> exactly what they
>>> shouldn't do!
>>>
>>> By all means deprecate functionality, but as soon as you
>>> start adding a
>>> different mechanism for achieving the same result, you will
>>> break
>>> compatability between midp1/2 and midp3.
>>>
>>> Tbh I don't think any enhancements to the api should be
>>> considered, until
>>> the cause of the platforms fragmentation has been isolated,
>>> and the
>>> appropriate action taken. (e.g. shooting some of the people
>>> responsible!
>>> =D )
>>>
>>>
>>> ----- Original Message -----
>>> From: <meinterest@MOBILEANDEMBEDDED.ORG>
>>> <mailto:meinterest@MOBILEANDEMBEDDED.ORG>
>>> To: <KVM-INTEREST@JAVA.SUN.COM>
>>> <mailto:KVM-INTEREST@JAVA.SUN.COM>
>>> Sent: Friday, June 15, 2007 12:43 AM
>>> Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp()
>>> lifecycle method
>>>
>>>
>>> Granted I have not researched this issue, but here are my
>>> first thoughts.
>>>
>>> We need something smarter here. I think it should be
>>> deprecated and replaced
>>> with a new more informative method, or reduced in scope to a
>>> set of well
>>> defined events to provide consistency across implementations and
>>> complemented with a new method for handling the more general
>>> non-life cycle
>>> events.
>>>
>>> PauseApp does not provide enough information about why it
>>> was called for the
>>> developer to make smart implementation decisions.
>>>
>>> In addition, there is not a hard definition for the “Paused�
>>> state and the
>>> application developer has no reliable way of differentiating
>>> what the device
>>> implementation considers an actively shared resource, a
>>> resource that can be
>>> shared, resources that is intended to be shared, or
>>> resources that cannot be
>>> shared.
>>>
>>> In addition there is no way to negotiate which resources are
>>> “nice to have�,
>>> “must haves�, or if the MIDlet should have precedence or
>>> exclusive access to
>>> a resource.
>>>
>>> Reducing resource usage is not something that can be done
>>> intelligently,
>>> partly because of the lack of information that is provided
>>> by pauseApp, but
>>> more so because hardware and resource management vary across
>>> devices.
>>>
>>> Consider playing a multiplayer/networked game or
>>> streaming/downloading a
>>> relatively large file from a server. A pause and resume may
>>> not be viable
>>> in this case. How do I decide that I would rather continue
>>> playing my game
>>> or listening to my stream rather than taking a call from a
>>> vendor?
>>>
>>> I think we should have something more informative in its
>>> place. I think Kim’s
>>> idea is a good approach.
>>>
===========================================================================
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".
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 15, 2007 7:11 PM
in response to: C. Enrique Ortiz
|
|
|
|
|
Absolutely very well put.
----- Original Message ----
From: Jacob Abrams <jacob.abrams@GLU.COM>
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Saturday, 16 June, 2007 2:46:06 AM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
The first question is what problem are we trying to solve?
If the problem is device fragmentation the answer is extremely simple. Sun
Microsystems must actually start doing its job and verify that OEM
implementations of the MIDP API are followed. Its plainly and painfully obvious
that Sun is allow OEMs to ship whatever they feel like in regards to the
interrupt callback methods. Some OEMs ship devices which do not even call a
single callback on interrupt at all.
Personally I don't believe there is any use in complicating
the system by adding additional information about the callbacks as BREW does.
Who cares if it is an SMS interrupt or a phone call interrupt, especially if it
isn't going to give us any other information such as the contents of the SMS or
an audio stream to the phone call. There is certainly no reason to make the
system more complex if OEMs are going to continue to do as they please. Device
fragmentation will only become worse as the devices have more ways in
differentiating themselves by implementing the API
differently.
The solution has little to do with modifying the API and
much more to do with fixing Sun Microsystems model of any virtual
machine implementation will pass Sun standards (or lack thereof). Sun must
be more strict and scrutinize OEMs better if they are going to make our lives
any easier. Until they accomplish that any new features they add to the MIDP
specifications are merely a tease, because most
OEM implementations will be completely broken and utterly
useless.
Jacob
From: A mailing list for KVM discussion
[mailto:KVM-INTEREST@JAVA.SUN.COM] On Behalf Of C. Enrique
Ortiz
Sent: Friday, June 15, 2007 8:23 AM
To:
KVM-INTEREST@JAVA.SUN.COM
Subject: Re: MIDP3 Proposal to remove the
MIDlet pauseApp() lifecycle method
pauseApp is just a life-cycle signal that the application will
go passive, with a suggested behavior to release resources.
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."
Handset capabilities will
continue to increase, but not all platforms are created equal: some will
continue to be embedded/resource-constrained platforms, and we should not
remove this primitive signal.
The problem w/ pauseApp is not pauseApp,
but all those definitions and assumptions that have evolved over the years. If
you treat pauseApp as just that, a life-cycle signal, there is no source of
issues or fragmentation.
While MIDP3 is defining a system event/state
API, the primitive life-cycle methods should be kept.
Instead, let's
address the interpretation issue. pauseApp is just one of many interpretation
issues. pauseApp is the trivial one (in my opinion).
ceo
Robin
Chaddock wrote:
DIV {
MARGIN:0px;}
I think you are missing the point of this
thread; the impetus behind deprecating pauseApp() is to *reduce* handset
incompatabilities, and consequently *simplify* porting.
-----
Original Message -----
From:
Fly
Home
To:
KVM-INTEREST@JAVA.SUN.COM
Sent:
Friday, June 15, 2007 11:03 AM
Subject:
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
99%
of applications will be ported any way so any lack of compatibility can be
easily solved then and i don't see the need to do porting being reduced
until there is a consistent j2me application platform across all devices
that is strictly adhered to.
BREW allows for different events to be
sent to the application and this functionality when interacting with the
phone os would possibly make it easier to work around j2me implementations
that do not play nice.
-----
Original Message ----
From: Robin Chaddock <robin.chaddock@IPLAY.COM>
To:
KVM-INTEREST@JAVA.SUN.COM
Sent:
Friday, 15 June, 2007 7:07:07 PM
Subject: Re: MIDP3 Proposal to remove
the MIDlet pauseApp() lifecycle method
If their aim is reduce fragmentation, I think that is exactly what
they
shouldn't do!
By all means deprecate functionality, but as
soon as you start adding a
different mechanism for achieving the same
result, you will break
compatability between midp1/2 and
midp3.
Tbh I don't think any enhancements to the api should be
considered, until
the cause of the platforms fragmentation has been
isolated, and the
appropriate action taken. (e.g. shooting some of the
people responsible!
=D )
----- Original Message
-----
From: <meinterest@MOBILEANDEMBEDDED.ORG>
To:
<KVM-INTEREST@JAVA.SUN.COM>
Sent:
Friday, June 15, 2007 12:43 AM
Subject: Re: MIDP3 Proposal to remove
the MIDlet pauseApp() lifecycle method
Granted I have not
researched this issue, but here are my first thoughts.
We need
something smarter here. I think it should be deprecated and
replaced
with a new more informative method, or reduced in scope to a
set of well
defined events to provide consistency across
implementations and
complemented with a new method for handling the
more general non-life cycle
events.
PauseApp does not provide
enough information about why it was called for the
developer to make
smart implementation decisions.
In addition, there is not a hard
definition for the “Paused� state and the
application developer has no
reliable way of differentiating what the device
implementation
considers an actively shared resource, a resource that can be
shared,
resources that is intended to be shared, or resources that cannot
be
shared.
In addition there is no way to negotiate which
resources are “nice to have�,
“must haves�, or if the MIDlet should
have precedence or exclusive access to
a resource.
Reducing
resource usage is not something that can be done intelligently,
partly
because of the lack of information that is provided by pauseApp,
but
more so because hardware and resource management vary across
devices.
Consider playing a multiplayer/networked game or
streaming/downloading a
relatively large file from a server. A pause
and resume may not be viable
in this case. How do I decide that I would
rather continue playing my game
or listening to my stream rather than
taking a call from a vendor?
I think we should have something more
informative in its place. I think Kim’s
idea is a good
approach.
[Message sent by forum member 'astrientlabs'
(astrientlabs)]
http://forums.java.net/jive/thread.jspa?messageID=222292
===========================================================================
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".
________________________________________________________________________
E-mail
is an informal method of communication and may be subject to data
corruption, interception and unauthorised amendment for which I-play, a
trading name of Digital Bridges Ltd will accept no liability. Therefore,
it will normally be inappropriate to rely on information contained on
e-mail without obtaining written confirmation.
This e-mail may
contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify
the sender immediately and destroy this e-mail. Any unauthorized copying,
disclosure or distribution of the material in this e-mail is strictly
forbidden.
(C) 2005. I-play is a trademark and trading name of
Digital Bridges Limited. All Rights
Reserved.
________________________________________________________________________
This
message has been checked for all known viruses by the
MessageLabs Virus
Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp
===========================================================================
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".
Yahoo!7 Mail has just got even bigger and better with unlimited storage on
all webmail accounts. Find out more.
===========================================================================
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".
________________________________________________________________________
E-mail
is an informal method of communication and may be subject to data
corruption, interception and unauthorised amendment for which I-play, a
trading name of Digital Bridges Ltd will accept no liability. Therefore, it
will normally be inappropriate to rely on information contained on e-mail
without obtaining written confirmation.
This e-mail may contain
confidential and/or privileged information. If you are not the intended
recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly
forbidden.
(C) 2005. I-play is a trademark and trading name of
Digital Bridges Limited. All Rights
Reserved.
________________________________________________________________________
This
message has been checked for all known viruses by the
MessageLabs Virus
Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp
--------------------------------
Spam/Virus scanning by CanIt Pro
For more information see http://www.kgbinternet.com/SpamFilter.htm
To control your spam filter, log in at http://filter.kgbinternet.com
===========================================================================
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".
_________________________________________________________________________________
Yahoo!7 Mail has just got even bigger and better with unlimited storage on all webmail accounts.
http://au.docs.yahoo.com/mail/unlimitedstorage.html
===========================================================================
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]
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 15, 2007 9:04 PM
in response to: C. Enrique Ortiz
|
|
|
|
|
100% concur. Sun MUST take the lead and enforce adherence to JSRs. The current situation is a joke. I am sure that for MIDP at least Sun could also enlist the operators as well.
From: A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM] On Behalf Of Fly Home
Sent: Saturday, 16 June 2007 12:11 PM
To: KVM-INTEREST@JAVA.SUN.COM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Absolutely very well put.
----- Original Message ----
From: Jacob Abrams <jacob.abrams@GLU.COM>
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Saturday, 16 June, 2007 2:46:06 AM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
The first question is what problem are we trying to solve? If the problem is device fragmentation the answer is extremely simple. Sun Microsystems must actually start doing its job and verify that OEM implementations of the MIDP API are followed. Its plainly and painfully obvious that Sun is allow OEMs to ship whatever they feel like in regards to the interrupt callback methods. Some OEMs ship devices which do not even call a single callback on interrupt at all.
Personally I don't believe there is any use in complicating the system by adding additional information about the callbacks as BREW does. Who cares if it is an SMS interrupt or a phone call interrupt, especially if it isn't going to give us any other information such as the contents of the SMS or an audio stream to the phone call. There is certainly no reason to make the system more complex if OEMs are going to continue to do as they please. Device fragmentation will only become worse as the devices have more ways in differentiating themselves by implementing the API differently.
The solution has little to do with modifying the API and much more to do with fixing Sun Microsystems model of any virtual machine implementation will pass Sun standards (or lack thereof). Sun must be more strict and scrutinize OEMs better if they are going to make our lives any easier. Until they accomplish that any new features they add to the MIDP specifications are merely a tease, because most OEM implementations will be completely broken and utterly useless.
Jacob
_____
From: A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM] On Behalf Of C. Enrique Ortiz
Sent: Friday, June 15, 2007 8:23 AM
To: KVM-INTEREST@JAVA.SUN.COM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
pauseApp is just a life-cycle signal that the application will go passive, with a suggested behavior to release resources.
>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."
Handset capabilities will continue to increase, but not all platforms are created equal: some will continue to be embedded/resource-constrained platforms, and we should not remove this primitive signal.
The problem w/ pauseApp is not pauseApp, but all those definitions and assumptions that have evolved over the years. If you treat pauseApp as just that, a life-cycle signal, there is no source of issues or fragmentation.
While MIDP3 is defining a system event/state API, the primitive life-cycle methods should be kept.
Instead, let's address the interpretation issue. pauseApp is just one of many interpretation issues. pauseApp is the trivial one (in my opinion).
ceo
Robin Chaddock wrote:
I think you are missing the point of this thread; the impetus behind deprecating pauseApp() is to *reduce* handset incompatabilities, and consequently *simplify* porting.
----- Original Message -----
From: HYPERLINK "mailto:vedanuzal@YAHOO.COM.AU" \nFly Home
To: HYPERLINK "mailto:KVM-INTEREST@JAVA.SUN.COM" \nKVM-INTEREST@JAVA.SUN.COM
Sent: Friday, June 15, 2007 11:03 AM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
99% of applications will be ported any way so any lack of compatibility can be easily solved then and i don't see the need to do porting being reduced until there is a consistent j2me application platform across all devices that is strictly adhered to.
BREW allows for different events to be sent to the application and this functionality when interacting with the phone os would possibly make it easier to work around j2me implementations that do not play nice.
----- Original Message ----
From: Robin Chaddock HYPERLINK "mailto:robin.chaddock@IPLAY.COM" \n<robin.chaddock@IPLAY.COM>
To: HYPERLINK "mailto:KVM-INTEREST@JAVA.SUN.COM" \nKVM-INTEREST@JAVA.SUN.COM
Sent: Friday, 15 June, 2007 7:07:07 PM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
If their aim is reduce fragmentation, I think that is exactly what they
shouldn't do!
By all means deprecate functionality, but as soon as you start adding a
different mechanism for achieving the same result, you will break
compatability between midp1/2 and midp3.
Tbh I don't think any enhancements to the api should be considered, until
the cause of the platforms fragmentation has been isolated, and the
appropriate action taken. (e.g. shooting some of the people responsible!
=D )
----- Original Message -----
From: HYPERLINK "mailto:meinterest@MOBILEANDEMBEDDED.ORG" \n<meinterest@MOBILEANDEMBEDDED.ORG>
To: HYPERLINK "mailto:KVM-INTEREST@JAVA.SUN.COM" \n<KVM-INTEREST@JAVA.SUN.COM>
Sent: Friday, June 15, 2007 12:43 AM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Granted I have not researched this issue, but here are my first thoughts.
We need something smarter here. I think it should be deprecated and replaced
with a new more informative method, or reduced in scope to a set of well
defined events to provide consistency across implementations and
complemented with a new method for handling the more general non-life cycle
events.
PauseApp does not provide enough information about why it was called for the
developer to make smart implementation decisions.
In addition, there is not a hard definition for the “Paused� state and the
application developer has no reliable way of differentiating what the device
implementation considers an actively shared resource, a resource that can be
shared, resources that is intended to be shared, or resources that cannot be
shared.
In addition there is no way to negotiate which resources are “nice to have�,
“must haves�, or if the MIDlet should have precedence or exclusive access to
a resource.
Reducing resource usage is not something that can be done intelligently,
partly because of the lack of information that is provided by pauseApp, but
more so because hardware and resource management vary across devices.
Consider playing a multiplayer/networked game or streaming/downloading a
relatively large file from a server. A pause and resume may not be viable
in this case. How do I decide that I would rather continue playing my game
or listening to my stream rather than taking a call from a vendor?
I think we should have something more informative in its place. I think Kim’s
idea is a good approach.
[Message sent by forum member 'astrientlabs' (astrientlabs)]
HYPERLINK "http://forums.java.net/jive/thread.jspa?messageID=222292" \nhttp://forums.java.net/jive/thread.jspa?messageID=222292
===========================================================================
To unsubscribe, send email to HYPERLINK "mailto:listserv@java.sun.com" \nlistserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
HYPERLINK "mailto:listserv@java.sun.com" \nlistserv@java.sun.com and include in the body of the message "help".
________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
HYPERLINK "http://www.messagelabs.com/stats.asp" \nhttp://www.messagelabs.com/stats.asp
===========================================================================
To unsubscribe, send email to HYPERLINK "mailto:listserv@java.sun.com" \nlistserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
HYPERLINK "mailto:listserv@java.sun.com" \nlistserv@java.sun.com and include in the body of the message "help".
_____
Yahoo!7 Mail has just got even bigger and better with unlimited storage on all webmail accounts. HYPERLINK "http://au.docs.yahoo.com/mail/unlimitedstorage.html" \nFind out more. =========================================================================== To unsubscribe, send email to HYPERLINK "mailto:listserv@java.sun.com" \nlistserv@java.sun.com and include in the body of the message "signoff KVM-INTEREST". For general help, send email to HYPERLINK "mailto:listserv@java.sun.com" \nlistserv@java.sun.com and include in the body of the message "help".
________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
HYPERLINK "http://www.messagelabs.com/stats.asp" \nhttp://www.messagelabs.com/stats.asp
--------------------------------
Spam/Virus scanning by CanIt Pro
For more information see HYPERLINK "http://www.kgbinternet.com/SpamFilter.htm" \nhttp://www.kgbinternet.com/SpamFilter.htm
To control your spam filter, log in at HYPERLINK "http://filter.kgbinternet.com" \nhttp://filter.kgbinternet.com
=========================================================================== To unsubscribe, send email to HYPERLINK "mailto:listserv@java.sun.com" \nlistserv@java.sun.com and include in the body of the message "signoff KVM-INTEREST". For general help, send email to HYPERLINK "mailto:listserv@java.sun.com" \nlistserv@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".
_____
Yahoo!7 Mail has just got even bigger and better with unlimited storage on all webmail accounts. HYPERLINK "http://au.docs.yahoo.com/mail/unlimitedstorage.html" \nFind out more.
=========================================================================== 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".
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.13 - Release Date: 8/06/2007 12:00 AM
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.13 - Release Date: 8/06/2007 12:00 AM
===========================================================================
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]
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 17, 2007 5:30 AM
in response to: Ruhan, Craig
|
|
|
> 100% concur. Sun MUST take the lead and enforce adherence to JSRs. The current situation > is a joke. I am sure that for MIDP at least Sun could also enlist the operators as well.
That would be nice, I would really like to see it happen, but I wonder how realistic it would be.
In this cut-throat competive environment each mobile manufacture has to rush out new models within a 3 month turn around time, or risk loosing marketshare.
So what would happen if Sun tells them that they must delay their development cycle by an extra month for jsr conformance?
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 17, 2007 2:28 PM
in response to: Ruhan, Craig
|
|
|
>From personal experience the operators themselves are making use of MIDP a lot more than they used to and the quality/consistency of the KVM is really starting to impact them as well.
-----Original Message-----
From: A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM] On Behalf Of meinterest@MOBILEANDEMBEDDED.ORG
Sent: Sunday, 17 June 2007 10:30 PM
To: KVM-INTEREST@JAVA.SUN.COM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
> 100% concur. Sun MUST take the lead and enforce adherence to JSRs. The current situation > is a joke. I am sure that for MIDP at least Sun could also enlist the operators as well.
That would be nice, I would really like to see it happen, but I wonder how realistic it would be.
In this cut-throat competive environment each mobile manufacture has to rush out new models within a 3 month turn around time, or risk loosing marketshare.
So what would happen if Sun tells them that they must delay their development cycle by an extra month for jsr conformance?
[Message sent by forum member 'captainfreedom' (captainfreedom)]
http://forums.java.net/jive/thread.jspa?messageID=222607
===========================================================================
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".
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 16, 2007 8:13 PM
in response to: C. Enrique Ortiz
|
|
|
Is there currently or are there plans to implement a process to ensure that if an implementation of a JSR does not conform to the spec that steps are taken to rectify this in the next version of the implementation as currently this does not seem to happen much.
----- Original Message ----
From: Gary <Gary.Adams@SUN.COM>
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Saturday, 16 June, 2007 10:07:35 PM
Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Yes, there are many Sun subscribers on this list that
want to see MIDP3 spec be the best it can be.
Yes, some specifications have not been clear enough
and greater effort should be given when the specs are
written and reviewed.
Yes, some TCKs have not been thorough enough in
writing tests that would cover the key functionality to
verify it has been supported in a spec compliant manner.
It is the spec lead's responsibility to shepherd the process
and the expert group as a spec comes together. It is the
JCP community at large that supplies members for
the expert group and it is the community at large that
has opportunities to comment and challenge parts of any
specification as it becomes final.
Having spec compliant implementations as verified by
the JSR specific TCK is all that can be expected.
Robin Chaddock wrote:
> Well said, now if only the appropriate people in Sun were subscribers
> to this mailing list.....
>
> Jacob Abrams wrote:
>> The first question is what problem are we trying to solve? If the
>> problem is device fragmentation the answer is extremely simple. Sun
>> Microsystems must actually start doing its job and verify that OEM
>> implementations of the MIDP API are followed. Its plainly and
>> painfully obvious that Sun is allow OEMs to ship whatever they feel
>> like in regards to the interrupt callback methods. Some OEMs ship
>> devices which do not even call a single callback on interrupt at all.
>> Personally I don't believe there is any use in complicating the
>> system by adding additional information about the callbacks as BREW
>> does. Who cares if it is an SMS interrupt or a phone call interrupt,
>> especially if it isn't going to give us any other information such as
>> the contents of the SMS or an audio stream to the phone call. There
>> is certainly no reason to make the system more complex if OEMs are
>> going to continue to do as they please. Device fragmentation will
>> only become worse as the devices have more ways in differentiating
>> themselves by implementing the API differently.
>> The solution has little to do with modifying the API and much more to
>> do with fixing Sun Microsystems model of any virtual machine
>> implementation will pass Sun standards (or lack thereof). Sun must be
>> more strict and scrutinize OEMs better if they are going to make our
>> lives any easier. Until they accomplish that any new features they
>> add to the MIDP specifications are merely a tease, because most OEM
>> implementations will be completely broken and utterly useless.
>> Jacob
>>
>> *From:* A mailing list for KVM discussion
>> [mailto:KVM-INTEREST@JAVA.SUN.COM] *On Behalf Of *C. Enrique Ortiz
>> *Sent:* Friday, June 15, 2007 8:23 AM
>> *To:* KVM-INTEREST@JAVA.SUN.COM <mailto:KVM-INTEREST@JAVA.SUN.COM>
>> *Subject:* Re: MIDP3 Proposal to remove the MIDlet pauseApp()
>> lifecycle method
>>
>>
>> pauseApp is just a life-cycle signal that the application will go
>> passive, with a suggested behavior to release resources.
>>
>> 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."
>>
>> Handset capabilities will continue to increase, but not all
>> platforms are created equal: some will continue to be
>> embedded/resource-constrained platforms, and we should not remove
>> this primitive signal.
>>
>> The problem w/ pauseApp is not pauseApp, but all those
>> definitions and assumptions that have evolved over the years. If
>> you treat pauseApp as just that, a life-cycle signal, there is no
>> source of issues or fragmentation.
>>
>> While MIDP3 is defining a system event/state API, the primitive
>> life-cycle methods should be kept.
>>
>> Instead, let's address the interpretation issue. pauseApp is just
>> one of many interpretation issues. pauseApp is the trivial one
>> (in my opinion).
>>
>> ceo
>>
>> Robin Chaddock wrote:
>>> I think you are missing the point of this thread; the impetus
>>> behind deprecating pauseApp() is to *reduce* handset
>>> incompatabilities, and consequently *simplify* porting.
>>>
>>> ----- Original Message -----
>>> *From:* Fly Home <mailto:vedanuzal@YAHOO.COM.AU>
>>> *To:* KVM-INTEREST@JAVA.SUN.COM
>>> <mailto:KVM-INTEREST@JAVA.SUN.COM>
>>> *Sent:* Friday, June 15, 2007 11:03 AM
>>> *Subject:* Re: MIDP3 Proposal to remove the MIDlet
>>> pauseApp() lifecycle method
>>>
>>> 99% of applications will be ported any way so any lack of
>>> compatibility can be easily solved then and i don't see the
>>> need to do porting being reduced until there is a consistent
>>> j2me application platform across all devices that is
>>> strictly adhered to.
>>>
>>> BREW allows for different events to be sent to the
>>> application and this functionality when interacting with the
>>> phone os would possibly make it easier to work around j2me
>>> implementations that do not play nice.
>>>
>>> ----- Original Message ----
>>> From: Robin Chaddock <robin.chaddock@IPLAY.COM>
>>> <mailto:robin.chaddock@IPLAY.COM>
>>> To: KVM-INTEREST@JAVA.SUN.COM <mailto:KVM-INTEREST@JAVA.SUN.COM>
>>> Sent: Friday, 15 June, 2007 7:07:07 PM
>>> Subject: Re: MIDP3 Proposal to remove the MIDlet pauseApp()
>>> lifecycle method
>>>
>>> If their aim is reduce fragmentation, I think that is
>>> exactly what they
>>> shouldn't do!
>>>
>>> By all means deprecate functionality, but as soon as you
>>> start adding a
>>> different mechanism for achieving the same result, you will
>>> break
>>> compatability between midp1/2 and midp3.
>>>
>>> Tbh I don't think any enhancements to the api should be
>>> considered, until
>>> the cause of the platforms fragmentation has been isolated,
>>> and the
>>> appropriate action taken. (e.g. shooting some of the people
>>> responsible!
>>> =D )
>>>
>>>
>>> ----- Original Message -----
>>> From: <meinterest@MOBILEANDEMBEDDED.ORG>
>>> <mailto:meint
=
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 18, 2007 4:56 AM
in response to: C. Enrique Ortiz
|
|
|
The discussion has digressed a little but I'd like to add some thoughts on the latest comments.
Sun and many in the industry are well aware of the inconsistencies across Java ME platform implementations. There are multiple angles to this and some of the issues are very hard to solve. I encourage you to read to articles we've posted on the ME Application Developer project:
https://meapplicationdevelopers.dev.java.net/optimizing_portability.html
https://meapplicationdevelopers.dev.java.net/fragmentation.html
At the heart of the matter is the fact that there is no single "golden set" of reference bits (a product-quality, shipping, widely used platform implementation) that the industry can orient itself towards. Establishing such a reference platform is a key objective that Sun is pursuing by open sourcing its Java ME implementions (phoneME Feature and phoneME Advanced).
Also, going forward, Sun is augmenting its distribution model with binary (or "near-binary") distributions as to minimize the modifications a device manufacturer must make to create a shippable product.
Finally, Sun has created a comprehensive device test suite called Java Device Test Suite (http://java.sun.com/products/javadevice/) that tests implementations in much greater depth and detail than TCKs do. This test suite is already being mandated by many carriers around the world as a gating test for devices to be enabled for their networks.
So, things are being addressed but it is a complex problem that takes time and energy.
-- Terrence
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 18, 2007 7:14 AM
in response to: terrencebarr
|
|
|
Following your fragmentation type definition, I think the worst one is
the **Implementation fragmentation**, specially about rude KVM
implementation bugs and mistakes. I think that is the major lake of
TCKs. However, I do agree that it must be too hard (or expensive) to
prevent all potential problems, regarding all time-to-market constraints
and software/hardware variability.
In order to address (not only but specially) this kind of fragmentation,
I`d really like to see some mechanism to **dynamically update KVM
software**, allowing download of new patches. It could be such as
recall, but cheaper. However, it`s important to be careful to not lead
that to another fragmentation source. I would not like to see
application have to address specific KVM version to run. I`d like to see
application addressing a JSR version (or clarification) and be sure that
it runs properly.
Thank`s
_________________________
Tarcisio Camara
Meantime Mobile Creations
Recife/Brazil
meinterest@MOBILEANDEMBEDDED.ORG escreveu:
> The discussion has digressed a little but I'd like to add some thoughts on the latest comments.
>
> Sun and many in the industry are well aware of the inconsistencies across Java ME platform implementations. There are multiple angles to this and some of the issues are very hard to solve. I encourage you to read to articles we've posted on the ME Application Developer project:
>
> https://meapplicationdevelopers.dev.java.net/optimizing_portability.html
> https://meapplicationdevelopers.dev.java.net/fragmentation.html
>
> At the heart of the matter is the fact that there is no single "golden set" of reference bits (a product-quality, shipping, widely used platform implementation) that the industry can orient itself towards. Establishing such a reference platform is a key objective that Sun is pursuing by open sourcing its Java ME implementions (phoneME Feature and phoneME Advanced).
>
> Also, going forward, Sun is augmenting its distribution model with binary (or "near-binary") distributions as to minimize the modifications a device manufacturer must make to create a shippable product.
>
> Finally, Sun has created a comprehensive device test suite called Java Device Test Suite (http://java.sun.com/products/javadevice/) that tests implementations in much greater depth and detail than TCKs do. This test suite is already being mandated by many carriers around the world as a gating test for devices to be enabled for their networks.
>
> So, things are being addressed but it is a complex problem that takes time and energy.
>
> -- Terrence
> [Message sent by forum member 'terrencebarr' (terrencebarr)]
>
> http://forums.java.net/jive/thread.jspa?messageID=222673
>
> ===========================================================================
> 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".
|
|
|
|
|
|
|
|
|
Re: MIDP3 Proposal to remove the MIDlet pauseApp() lifecycle method
Posted:
Jun 19, 2007 4:05 AM
in response to: C. Enrique Ortiz
|
|
|
Yep, implementation bugs are some worst headaches.
Regarding dynamic/in-the-field updates of the Java implementation: This is certainly one way of addressing some of the problems and in fact such firmware updates are already being done by major device manufacturers.
However, I am not sure this is really the way to go for multiple reasons:
- It may actually *increase* fragmentation since now application developers cannot rely on a particular version of a phone to contain a particular well-known implementation. Ideally, all phones would be upgraded to the latest and greatest implementation but in practice that is not going to happen. So you've just moved the problem around and made is less predictable.
- Security and reliability are a huge risk. You would potentially be updating millions of different phone versions and if something in your update goes wrong you have a massive problem. Difficult to handle and OEMs and carriers are concerned.
- JSR versioning: This requires some pretty smart infrastructure on the phone and the back-end to handle versioning and dependencies. For example, what if app1 requires version 1.1 of a JSR but app2 requires version 1.2? What if version 1.1 was included in the firmware and optimized-in-place but version 1.2 is downloaded on demand and installed in some secure area of the device post production? Do you need to switch back and forth depending on the app? Hold multiple copies in memory?
I'm not saying it is not possible or feasable but dynamic updates require a lot of thought and an advanced infrastructure to work reliably for millions of devices. I guess that's why it is not yet in widespread use.
-- Terrence
|
|
|
|
|
java.net RSS
