Find JSRs
Submit this Search


Ad Banner
 
 
 
 
JSRs: Java Specification Requests
JSR 324: On Screen MIDlet API for Java ME

This JSR has been Rejected
Reason: This JSR was not approved by the ME Executive Committee in the JSR Approval Ballot.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: SK Telecom

Name of Contact Person: Dave Kim

E-Mail Address: dave_kim@sktelecom.com

Telephone Number: +82 2 6100 2673

Fax Number: +82 2 6100 7914


Specification Lead: Dave Kim

E-Mail Address: dave_kim@sktelecom.com

Telephone Number: +82 2 6100 2673

Fax Number: +82 2 6100 7914


Initial Expert Group Membership:

Vodafone
Orange
T-Mobile
Telefonica
Telecom Italia
Samsung
LG Electronics
SUN
Veloxsoft

Supporting this JSR:



Section 2: Request

2.1 Please describe the proposed Specification:

This JSR is designed to provide a standard API set of enabling MIDlet to be displayed, to operate, and to be activated on the idle screen of embedded devices.
With this JSR, 3rd party like contents provider and application vendor will have various advantages as below.

  • Open Interface of using idle screen as direct channel for user to access application without complex discovery procedure
  • Separation of device dependent variables in the mounting MIDlets on the idle screen to guarantee flexibility and wide penetration of service

Based on the proposed JSR, the various enablers of mobile industry including service operators, embedded device vendors, application/solution developers can find a stable and standard way to use idle screen as application playground. The contents market is growing with the increase of data service usage and major revenue comes from contents downloading unlikely with wired internet service. But the event-based contents downloading service has the opportunity ceiling to make users always contact with wireless data service because most of content lose its communication with customers closing MIDlet.
If MIDlet can stay on idle screen and placed on idle screen for user to access directly and intuitively, the business opportunity will be rapidly enhanced for contents provider seeking new business channel. The user benefit will be increased also with the improvement of accessibility.

See image for better understanding.

http://project.veloxsoft.com/download/2.1.MIDlet%20Exposure.bmp

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

his specification is targeted for the Java ME platform on embedded devices.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

The target is the CLDC/MIDP and the next generation of CDC based platform. This specification mainly focuses on the mobile devices which have single or dual display screen fulfilling user needs to access easily and simply to the information and function of device.
This specification should be designed not to cause fragmentation problems between CDC and CLDC.

2.4 Should this JSR be voted on by both Executive Committees?

No

2.5 What need of the Java community will be addressed by the proposed specification?

As the usage of mobile device increased, operators and handset vendors are considering the idle screen of handset as the most effective interactive window to communicate with user and to deliver information to user intuitionally. Based on many Java specifications, the extent of function that Java application covers has been broadened. But the advantages of Java application have been hurdled since that the exposure of Java application is hidden behind the complexity of application discovery experience.
The potential usage of idle screen as shelf of application to be displayed and as window of intuitional information delivery will improve the user accessibility to the advantages of MIDlet application and provide attractive and profitable chance for Java application industry in mobile market.
By providing general technology fulfilling these needs, Java Community can prevent fragmentation of the market to make Java players more profitable.
If Java technology misses the chance of providing general technology for on screen controllability, it will lose the market opportunity for Java application industry. For example, various ODP solution vendors are trying to provide solutions to support idle screen presence in Europe mobile market, but their solutions are not compliable in the condition without uniform specification. Eventually solution vendors are now adding their own proprietary APIs and specifications to the present standard and it makes fragmentation that is an obstacle for spreading compliable pervasive service.

2.6 Why isn't this need met by existing specifications?

Currently, there has been no Java specification related to idle screen functionality since the device was restricted due to various conditions that must be considered in regards to MIDlet that is always running. Moreover, there was strong, continuing interest about idle screen functionality for using idle screen as communication window in mobile industry but so many stakeholders including operators and device manufacturers had developed proprietary specification to further fragment the mobile market that is already very much fragmented.
MIDP 3.0 which is being developed under JSR 271 also deals with similar functionality which is proposed in this document. But MIDP 3.0 focuses the way to expose part of MIDlets, does not present the controllability of MIDlet over idle screen such as OEM application. With MIDP 3.0, MIDlet application vendor can designate what component of MIDlet application to be exposed in idle screen but the way of display depends on OEM implementation. It means that user experience can be varied as to the OEM vendor?s implementation. Service can be shown in different way with different user scenario regardless of service vendor's intention. MIDP 3.0 functionality is only fit for providing preview of MIDlet or short cut to enter MIDlet application activation mode.
OnScreenMIDlet specification does not only focus to provide functionality to expose MIDlet with more interactive way but also try to provide full accessibility to idle screen area for 3rd party MIDlet application vendor. This specification is designed to implement full idle screen MIDlet with less OEM dependency.
OnScreenMIDlet enables for solution vendors to develop such applications as dynamic handset menu application that replaces OEM menu, ODP application with idle presence and customizable dynamic theme service.

See table

http://project.veloxsoft.com/download/2.6.%20Table.png

and image

http://project.veloxsoft.com/download/2.6.%20OnScrMIDlet.bmp

2.7 Please give a short description of the underlying technology or technologies:

The condition for implementation of this JSR is fully prepared. With the advance of mobile technology, the capability of CPU/memory and the endurance of battery power have been rapidly enhanced for MIDlet to always run.
This JSR is designed to have modular architecture and to provide native idle screen features.

    =.Modular architecture
    -.In modular architecture, idle screen based service can be easily managed with increased memory efficiency.
    -.Modular architecture guarantees the expandability of service and compatibility between services.
    =.Native idle screen feature
    -.For respecting user experience and handset vendor needs, this JSR should support the coherence feature with legacy OEM function as much as possible.

The core technologies to enable the JSR include:

    =. Handset state management method: Every handset has the idle state. Based on raised events, the state transfers to other states and then the state comes back to the idle state.
    =. Event handling method: In accord with state management, all kinds of events should be handled properly on the idle state. Some of them should be delivered to the idle screen MIDlet set by the JSR, and the others to the underlying subsystem.
    =. Abstraction layer to ensure subsystem independency: There are various underlying SW subsystems on handsets to launch an idle MIDlet. A uniform interface should be defined to ensure the subsystem independency of the JSR.

2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.microedition.OnScrMIDlet will be a good candidate.

2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

None

2.10 Are there any security issues that cannot be addressed by the current security model?

None

2.11 Are there any internationalization or localization issues?

Support for a sufficient set of character encodings might be required.

2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

None

2.13 Please describe the anticipated schedule for the development of this specification.

pril 2008: EG Formed
July 2008: Early Draft Review
December 2008: Public Review
March 2009: Proposed Final Draft
June 2009: Final Approval Ballot

2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.

The working interactions will be primarily email communications, with occasional teleconferences/video conferences as appropriate. Face-to-face meetings, which will be tele/videoconferenced, will be arranged as needed and as appropriate.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

The transparency plan is:
a) JSR community page is used to provide the community with regular updates of the draft specifications and information about the current topics and issues of the Expert Group.
b) A mail alias is maintained for the JCP members who are outside of the Expert Group but requested the mail notification of the progress of the EG activities. Periodic milestone draft specifications and status are published to this list. The Expert Group may also use the list to request feedback on key issues facing the group.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

Both RI and TCK will be delivered as stand-alone packages.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Currently, we plan that for both the TCK and RI we will charge a single one-time fee of max 70,000 USD and an annual maintenance fee of max 50,000 USD for three years.





Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Original document of this request is can be downloaded at http://project.veloxsoft.com/download/OnScreenMIDlet_v1.pdf

3.2 Explanation of how these items might be used as a starting point for the work.

Items are provided for introduction of request.



Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

N/A