 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 258: Mobile User Interface Customization API
JCP version in use: 2.7 Java Specification Participation Agreement version in use: 2.0 Description: The Mobile User Interface Customization API provides a way to query and modify the user interface customization properties of a mobile device or platform. Please direct comments on this JSR to the Spec Lead(s) Team
Updates to the Java Specification Request (JSR) The following information has been updated from the original JSR: 2012.08.22: The following section has been updated. 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
TCK: 2012.08.21: North Sixty-One has become the co-Maintenance Lead. Maintenance Lead: Erkki Rysä E-Mail Address: jsr258 Telephone Number: - Fax Number: - 2006.04.27: April 2006: Public Review August 2006: Proposed Final Draft September 2006: Final Approval Ballot
Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Nokia Corporation Name of Contact Person: Kimmo Loytana E-Mail Address: kimmo.loytana@nokia.com Telephone Number: +358 7180 35252 Fax Number: +358 7180 70530 Specification Lead: Jere Kapyaho E-Mail Address: jere.kapyaho@nokia.com Telephone Number: +358 7180 39173 Fax Number: +358 7180 70530 Initial Expert Group Membership: Nokia Corporation Supporting this JSR: Intel Corp Section 2: Request
2.1 Please describe the proposed Specification:The overall goal is the specification of an API that allows the customization of the look and feel of the user interface components in a mobile device or platform. This can be achieved by allowing the API to access the customization properties of user interface (i.e. the themes), providing a mechanism to achieve a uniform customized look and feel in the user interface components, regardless of their underlying implementation mechanism. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Java 2 Micro Edition. The minimum requirement of the API should be the CLDC. 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.This JSR is targeting to JavaTM 2, Micro Edition only. 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?The access to user interface customization properties provided by this API is seen as a desirable capability in providing a customized user experience. At the same time the customization must not degrade the usability of a device. The API will assist developers in the creation of custom components that have the same look and feel as the standard UI components provided by the underlying UI toolkits. 2.6 Why isn't this need met by existing specifications?None of the existing Java APIs provide this kind of functionality, even in the J2SE. There are currently no APIs that allow generic access to the user interface theme properties of the platform. 2.7 Please give a short description of the underlying technology or technologies:The API does not rely on any specific underlying theme or customization technology. The customization data can reside in a proprietary OS or in the implementation layer of a standardized Java UI toolkit. The API simply provides access to the platform or UI toolkit customization properties. The goal of the API is to provide unified access mechanism to different theme technologies for applications. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.microedition.customization 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?No. The expert group will define the relationship of this API to both the MIDP 2.0 security framework and the Java 2 security framework. The mechanism for setting the customization properties may be subject to security policy checks. 2.11 Are there any internationalization or localization issues?Yes. Some of the customization properties may be locale-specific. The expert group will decide what kind of internationalization (I18N) model is needed for the API. Similarly, the properties must work properly in devices or platforms supporting bidirectional languages. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.13 Please describe the anticipated schedule for the development of this specification.Dec 2004: EG formed 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.Electronic mail and the World-Wide Web, phone conferences and face-to-face meetings when needed (at least as a kick-off). The work will start with requirements gathering and continues based on technical design proposals. The bulk of the work on requirements and design is processed in the expert group mailing list. In requirements gathering the expert group should consider the requirements of relevant external parties such as OMTP. 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 final JSR specification and intermediate review drafts will be available from the JCP web site, as is customary. The Expert Group will provide status updates on the JSR Community Update Page on a monthly basis. These will include at least updates to the anticipated schedule, status of the specification and possible open issues where input is requested from the wider community. 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.The Reference Implementation (RI) and Technology Compatibility Kit (TCK) will be delivered separately and as stand-alone. 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.These terms only represent the initial commercial terms to be used and remain subject to the execution of final legal agreements covering the subject matter hereof to be determined by Nokia at its sole discretion. 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.None 3.2 Explanation of how these items might be used as a starting point for the work.N/A 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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
