Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 258: Mobile User Interface Customization API

Stage Access Start Finish
Maintenance Release Download page 31 Oct, 2011  
Maintenance Draft Review Download page 15 Mar, 2011 14 Apr, 2011
Final Release Download page 18 Jun, 2008  
Final Approval Ballot View results 02 Jan, 2007 16 Jan, 2007
Proposed Final Draft Download page 19 Oct, 2006  
Public Review Ballot View results 06 Jun, 2006 12 Jun, 2006
Public Review Download page 09 May, 2006 12 Jun, 2006
Early Draft Review Download page 12 Oct, 2005 11 Nov, 2005
Expert Group Formation   16 Nov, 2004 25 May, 2005
JSR Review Ballot View results 02 Nov, 2004 15 Nov, 2004
Status: Maintenance
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

Specification Leads
Star Spec Lead Jere Kapyaho Nokia Corporation
  Erkki Rysä North Sixty-One Ltd
Expert Group
  AT&T BenQ Corporation Ericsson AB
  Esmertec AG Motorola Nokia Corporation
  North Sixty-One Ltd Petronelli, Paul L. Sony Ericsson Mobile Communications AB
  Sprint Sun Microsystems, Inc. Telecom Italia

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:
- Available free of charge to qualified not-for-profit organizations and individuals in accordance with the JSPA, solely for developing and testing their own implementations and not allowing to test any third party or commercial for-profit implementations.
- The TCK is licensed, in line with the MSA licensing principles, with a flat fee of USD 50 000 for a license term of 3 years. This includes all maintenance updates and releases, if any. The license will be worldwide, non-exclusive and will be granted on an AS IS basis without any warranties or indemnities given and with the exclusion of all indirect and consequential damages. Major new releases, from new follower JSR, are subject to a separate license fee.
- The license grant will be for a term of not less than three (3) years.
- A license allowing licensees to test implementations on behalf of third parties as a free or for-fee commercial service under certain conditions shall be available. This right may result in a higher license fee.

2012.08.21: North Sixty-One has become the co-Maintenance Lead.

Maintenance Lead: Erkki Rysä

E-Mail Address: jsr258@northsixtyone.com

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
Ericsson Mobile Platforms
Siemens AG

Supporting this JSR:

Intel Corp
Nokia Corporation
Ericsson Mobile Platforms
Siemens AG



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.
The API should have the following functionality:
- Querying the customization properties of user interface themes of a mobile device or platform.
- Modifying the customization properties of user interface themes of a mobile device or platform.
The initial requirements for the API are:
- Independence of specific user interface toolkits. The API should work with any graphical user interface toolkit, including (but not limited to) the LCDUI of MIDP, AGUI of JSR 209 or AWT of PBP/PP.
- Providing an open framework for access to customization properties, without being fixed to any specific named collection of customization properties.
Access to a collection of customization properties is provided through a vocabulary. This vocabulary may be specific to a device or a platform. The customization API will try to identify a common vocabulary for the properties. However, the API should be an open and flexible framework for accessing any device-specific or platform-specific properties. The properties are not limited to UI APIs, but may include also application platform properties like application icons, tones etc.
The specification enables implementations where the customization uniformly affects all user interface elements of applications (both native and Java) in the device or platform, thereby achieving a unified user experience across the device.
The JSR expert group will study whether there is a need to have application-specific customization capabilities, or the need to extend the customization capabilities to functional elements such as menu extensions and browser bookmarks.
This JSR will specify the UI customization API as an Optional Package API, and does not assume any specific application model or UI toolkit. The Optional Package can be used by any J2ME application using any supported application model, running on any J2ME Profile.
The API can be utilized in the creation of a customized look and feel for custom UI components, but it does not define any APIs for creating those custom components. The custom components are created using the facilities available in existing UI toolkits.
The expert group will also study whether there is a need to specify an over-the-air (OTA) transmission/serialization format for the customization property / UI theme data.

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.
The Swing UI toolkit contains pluggable look and feel technology that allows providing totally new widget implementations to be used with the Swing APIs. Producing a complete look and feel using this mechanism is a highly laborious task, which is not so much about customization as about the implementation of a new widget library.
The API will assist developers in the creation of custom components that have the same look and feel as the standard UI components used by the application.

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.
As stated in section 2.1, the expert group will also study whether it is possible to define a standardized vocabulary of the theme property names. If so, then the implementation of the API will, if necessary, map these names to the proprietary theme property names used in a given platform or toolkit.

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
Jan 2005: Early Draft Review
Mar 2005: Public Review
June 2005: Proposed Final Draft
Oct 2005: Final Approval Ballot

Note that this information has been updated from the original JSR.

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.
See the business terms section for more details.

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.
We will license to all interested parties. Independent implementations will be allowed - TCK and RI will be licensed separately.
For the TCK we will charge a single one-time fee of max US $50,000 and an annual maintenance fee, max US $20,000 for a term of four years. The TCK will include both the binary environment and the source code for the test suite. The maintenance fee covers limited basic support, first level TCK appeals process, bug fixes when available and updates, which are due to changes in the Specification. Major new releases (esp. from new follower JSR) might be subject to an additional single one-time fee.
Using the TCK for testing of implementations on behalf of third parties will be allowed, though, be subject to a higher fee, which is capped at the sum of license fees due in accordance with license fees as described above in this section, if the third parties would have directly licensed the TCK from Nokia.
For the RI in source code form we will charge a one-time access fee, and an annual maintenance fee. Maintenance covers bug fixes, updates and new releases necessary due to specification changes, and when made generally available by the specification lead.
The binary license is free of charge.





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