omtp technology assessment · 2016. 5. 4. · 1 preface. 1.1 document purpose. this document is the...

OMTP

TECHNOLOGYASSESSMENT

OMTP JAVATM

WITH FOCUS ON CDC:DEFINITION AND REQUIREMENTS

This document contains information that is confidential and proprietary to

OMTP Limited. The information may not be used, disclosed or reproduced

without the prior written authorisation of OMTP Limited, and those so

authorised may only use this information for the purpose consistent with the

authorisation.

VERSION: Version 1_0, Release 1

STATUS: Approved

DATE OF LAST EDIT: 10 January 2006

OWNER: OMTP JavaTM Workstream

OMTP JAVATM WITH FOCUS ON CDC

© 2006 OMTP Ltd. All rights reserved. No part of this document may be reproduced ortransmitted in any form or by any means without prior written permission from OMTP Ltd.

of 44

CONTENTS

1 PREFACE .............................................................................. 5

1.1 DOCUMENT PURPOSE ............................................................. 5

1.2 INTENDED AUDIENCE............................................................... 5

1.3 CONVENTIONS........................................................................ 5

2 INTRODUCTION.................................................................... 7

2.1 OMTP JAVATM

WORKSTREAM GOALS...................................... 7

2.2 RELATIONSHIP TO OTHER OMTP GROUPS/WORKSTREAMS ........ 7

2.2.1 OMTP Software Group ............................................................... 72.2.2 OMTP User Experience Group................................................... 82.2.3 OMTP Application Security......................................................... 82.2.4 Other OMTP Groups .................................................................. 8

3 OMTP JAVATM PLATFORM VISION......................................... 9

3.1 JAVATM

PLATFORM VISION AND CORE COMPONENTS ................. 9

3.1.1 MSA CDC (JSR 249)................................................................ 103.1.2 Relationship to MSA CLDC (JSR 248) ..................................... 11

3.2 BACKWARDS COMPATIBILITY.................................................. 11

4 IDENTIFIED GAP AREAS/REQUIREMENTS..................... 12

4.1 RUNTIME MANAGEMENT AND ISOLATION ................................. 12

4.1.1 Problem description.................................................................. 124.1.2 Requirements ........................................................................... 134.1.3 Actions taken............................................................................ 134.1.4 Results and decisions............................................................... 13

4.2 FILE SYSTEM........................................................................ 14


4.3 APPLICATION META DATA ...................................................... 16


4.4 PERSISTENT ALARMS............................................................ 17

4.4.1 Problem description.................................................................. 17



of 44

4.4.2 Requirements ........................................................................... 184.4.3 Actions taken............................................................................ 184.4.4 Results and decisions............................................................... 18

4.5 SYSTEM INFORMATION AND NOTIFICATIONS ............................ 20


4.6 DIGITAL RIGHTS MANAGEMENT ................................... 26

4.6.1 Problem.................................................................................... 264.6.2 Requirements ........................................................................... 264.6.3 Actions Taken........................................................................... 264.6.4 Results ..................................................................................... 26

5 NEXT STEPS........................................................................... 27

6 APPENDIX 1: UI TECHNOLOGIES - EVALUATION CRITERIA &RESULTS................................................................................ 28

6.1 OVERVIEW ........................................................................... 28

6.2 EVALUATION BASED ON OMTP UI CUSTOMIZATION USE CASES

........................................................................................... 28

6.3 EVALUATION CRITERIA .......................................................... 30

6.4 EVALUATION RESULTS .......................................................... 33

7 ABBREVIATIONS...................................................................... 43

8 REFERENCED DOCUMENTS ...................................................... 44



of 44

This document contains information that is confidential and proprietary toOMTP Limited. The information may not be used, disclosed or reproducedwithout the prior written authorisation of OMTP Limited, and those soauthorised may only use this information for the purpose consistent with theauthorisation.

The information contained in this document represents the current view heldby OMTP Ltd. on the issues discussed as of the date of publication.

This document is provided “as is” with no warranties whatsoever including anywarranty of merchantability, non-infringement, or fitness for any particularpurpose. All liability (including liability for infringement of any property rights)relating to the use of information in this document is disclaimed. No license,express or implied, to any intellectual property rights are granted herein.

This document is distributed for informational purposes only and is subject tochange without notice. Readers should not design products based on thisdocument.

Each Open Mobile Terminal Platform member and participant has agreed touse reasonable endeavours to inform the Open Mobile Terminal Platform in atimely manner of Essential IPR as it becomes aware that the Essential IPR isrelated to the prepared or published specification. The declared Essential IPRis publicly available to members and participants of the Open Mobile TerminalPlatform and may be found on the “OMTP IPR Declarations” list at the OMTPteam room.

The Open Mobile Terminal Platform has not conducted an independent IPRreview of this document and the information contained herein, and makes norepresentations or warranties regarding third party IPR, including withoutlimitation patents, copyrights or trade secret rights. This document maycontain inventions for which you must obtain licenses from third parties beforemaking, using or selling the inventions.

Defined terms and applicable rules above are set forth in the Schedule to theOpen Mobile Terminal Platform Member and Participation Annex Form.

© 2006 Open Mobile Terminal Platform Ltd. All rights reserved. No part of thisdocument may be reproduced or transmitted in any form or by any meanswithout prior written permission from OMTP Ltd. “OMTP” is a registeredtrademark. Other product or company names mentioned herein may be thetrademarks of their respective owners.



of 44

1 PREFACE

1.1 DOCUMENT PURPOSE

This document is the OMTP JavaTM with Focus on CDC RequirementsSpecification. The purpose of the document is to identify requirementsfrom the perspective of wireless network operators to develop anadvanced mobile execution environment based on Java™ technology.

JavaTM technology has established itself as a leading executionenvironment for downloadable applications. The industry hascollectively identified the potential in the technology to go beyond itscurrent state. In order to enable the delivery of further value-addedservices to consumers, the JavaTM Micro Edition (JavaTM ME) platformneeds to grow in terms of APIs that the developers can use to writeinteresting applications. There is also a need to alleviate thefragmentation introduced due to implementation variations.

This document builds upon existing JavaTM platform standards, andidentifies technology gaps that are not yet covered by existing JCP(JavaTM Community Process) standards. The OMTP JavaTM Workstreamwill feed these gap requirements into JCP standardization activities(which may potentially initiate new JSRs) to ensure that all the operatorrequirements can be fulfilled by the JavaTM platform. A central goal ofthis document is to perform a gap analysis for advanced mobileterminal platforms that are based on JavaTM technology.

The document also identifies and defines key operator requirements forthe JavaTM platform in the user interface area. In addition, thisdocument provides criteria to effectively evaluate two possible userinterface technologies for the advanced JavaTM ME platform.

1.2 INTENDED AUDIENCE

This requirement document is intended primarily for companies andindividuals who are involved in the standardization and implementationof the JavaTM Micro Edition platform (Java™ ME). The document ispotentially useful also for tool vendors, content developers, or otherparties who are generally interested in the future directions andevolution of JavaTM technology for mobile devices.

1.3 CONVENTIONS

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,“SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”,“MAY”, and “OPTIONAL” in this document are to be interpreted asdescribed in RFC2119 [1].

• MUST: This word, or the terms "REQUIRED" or "SHALL", meanthat the definition is an absolute requirement of the specification.



of 44

• MUST NOT: This phrase, or the phrase "SHALL NOT", meanthat the definition is an absolute prohibition of the specification.

• SHOULD: This word, or the adjective "RECOMMENDED", meanthat there may exist valid reasons in particular circumstances toignore a particular item, but the full implications must beunderstood and carefully weighed before choosing a differentcourse.

• SHOULD NOT: This phrase, or the phrase "NOTRECOMMENDED" mean that there may exist valid reasons inparticular circumstances when the particular behaviour isacceptable or even useful, but the full implications should beunderstood and the case carefully weighed before implementingany behaviour described with this label.

• MAY: This word, or the adjective "OPTIONAL", mean that anitem is truly optional. One vendor may choose to include theitem because a particular marketplace requires it or because thevendor feels that it enhances the product while another vendormay omit the same item. An implementation which does notinclude a particular option MUST be prepared to interoperatewith another implementation which does include the option,though perhaps with reduced functionality. In the same vein animplementation which does include a particular option MUST beprepared to interoperate with another implementation whichdoes not include the option (except, of course, for the feature theoption provides.)



of 44

2 INTRODUCTION

2.1 OMTP JAVATM

WORKSTREAM GOALS

The OMTP Java Workstream has several goals that it is workingtoward. These goals support the overall effort to make the Javaexecution environment a compelling and complete platform whichmeets the needs of OMTP which is suitable for both operators andhandset manufacturers. The goals that support this overall effort areas follows

• Define the base platform that will be used as the starting pointfor next-generation advanced mobile devices.

• Define platform requirements that will yield less fragmentation inthe market.

• Identify gap technologies that are needed to enable JavaTM

applications to become more resident on handsets, e.g., in orderto support built-in system applications written in the JavaTM

programming language.

• Drive gap requirements into JCP standardization activities and, ifneeded, initiate new JSRs to ensure that the operatorrequirements can be met by the JavaTM platform.

• Define User Experience and customization requirements thatmeet the specified needs of operators.

• Provide evaluation criteria to guide the User Interfacetechnology selection that will meet the operator requirements.

The OMTP JavaTM Workstream will feed the requirements into JCPstandardization activities, and may potentially initiate new JSRs inorder to ensure that the operator requirements can be met by theJava™ platform.

2.2 RELATIONSHIP TO OTHER OMTP GROUPS/WORKSTREAMS

2.2.1 OMTP SOFTWARE GROUP

The OMTP Software group is identifying requirements that areindependent of a specific technology. These requirements will be usedby the JavaTM Workstream as guidance in both the creation ofrequirements as well as defining specific gap technologies to help meetits goals. The JavaTM Workstream, by nature, will establish morespecific requirements since its focus is specifically on the developmentof the JavaTM ME platform for the wireless industry.



of 44

2.2.2 OMTP USER EXPERIENCE GROUP

The User Experience group is identifying specific use cases andrequirements for operators to provide a compelling user experience.The Software group will define generic (platform agnostic)requirements based on this work. JavaTM Workstream will then utilizethis set of relevant requirements and define the specific UserExperience use cases and requirements for the JavaTM Platform.

2.2.3 OMTP APPLICATION SECURITY

The Application Security group is identifying security requirements thatwill help enable the protection of the mobile devices and networks fromrogue applications and external attacks. The JavaTM Workstream willmonitor the work of the Application Security group closely, and utilizethe results in the future activities as necessary. The consideration,development, and requirement of a strong and flexible securityframework in terminals including JavaTM technology is key to theiracceptance in the marketplace. Future revisions of this document mustalign with the work of Application Security group.

2.2.4 OTHER OMTP GROUPS

The output of the other groups will be evaluated for relevance to theJavaTM platform. If relevant, this data will be incorporated into the futurework of the JavaTM Workstream.



of 44

3 OMTP JAVATM PLATFORM VISIONThis chapter summarizes the overall JavaTM Platform vision and thehigh-level JavaTM platform architecture defined by the OMTP JavaTM

Workstream. The results in this chapter are based on numerousconversations in the JavaTM Workstream meetings, the gap analysisperformed by a task force initiated by the JavaTM Workstream, as wellas the use cases developed during the OMTP activity.

3.1 JAVATM PLATFORM VISION AND CORE COMPONENTS

In today’s mobile devices, the role of the JavaTM platform is primarilythat of a “content player”. The JavaTM platform is used mainly forexecuting 3rd party applications – most typically games – that havebeen downloaded to the device over the wireless network. The JavaTM

platform has become enormously successful in this role. It has beenestimated that over 800 million mobile devices already support theJavaTM ME platform. Tens of thousands of commercial applicationshave already been developed, generating global revenues of over $1billion annually.

Based on the requirements and use cases collected from operators,there is a desire to take the role of the JavaTM platform in mobiledevices further, and to enable the use of the JavaTM platform not only asa content development platform but also as a platform for the creationof system software and resident applications. The JavaTM platformcapabilities should also be extended to enable more flexible userinterface customization to meet the operator needs.

In order to support these extended capabilities and use cases, weenvision a mobile JavaTM platform built upon the more capable J2MECDC (Connected Device Configuration) standard. An ongoing activity,MSA CDC (JSR 249), is currently defining a comprehensive platformbuilt around CDC technology (see next subsection for a brief summaryof the MSA CDC standardisation effort). In order to facilitate a transitionfrom JavaTM ME CDLC based platforms to JavaTM ME CDC basedplatforms the OMTP JavaTM workstream has agreed upon a set ofrequirements and recommendations. These requirements andrecommendations will be provided to the MSA CDC (JSR-249) expertgroup. The responsibility for this smooth transition between theplatforms falls on the expert group of the MSA JSRs, the JavaTM

community, as well as the industry as a whole. f

Figure 1 illustrates our overall OMTP JavaTM platform vision. Weassume that the OMTP JavaTM platform shall be built around the MSACDC platform. This general architecture might also be considered asmechanism to transition existing CLDC based platforms to CDC. Inaddition, a number of new, additional APIs may have to be developed



of 44

in order to support the development of JavaTM-based system softwareand resident applications in case the existing standards do not providethe necessary capabilities.

Based on the use cases and requirements, we also assume that theuser interface capabilities of the OMTP JavaTM platform will have to bemore capable than those provided by the libraries used in the majorityof JavaTM-enabled mobile devices today. A key outcome of the OMTPJavaTM Workstream activity will be the selection of a suitable userinterface library for the advanced JavaTM ME platform. The userinterface evaluation criteria and evaluation results will be summarizedlater in this document.

Figure 1: OMTP JavaTM Platform Vision

3.1.1 MSA CDC (JSR 249)

The OMTP Java platform definition and requirements documentprovides requirements and recommendations to the MSA (MobileService Architecture) CDC Java platform, defined by the JavaCommunity Process effort JSR 249. MSA CDC is a standardizationeffort that is currently defining a new, CDC-based JavaTM platformtargeted towards smartphones and other high-end mobile devices.MSA CDC consists of a JavaTM virtual machine that is fully compliantwith the JavaTM Virtual Machine Specification and the J2SE virtual



of 44

machine, augmented with a large number of libraries that providesignificantly more functionality than the more limited MSA CLDCplatform.

The MSA CDC standardization effort is currently in progress, and thedetails of the platform are still subject to change. For currentinformation on the MSA CDC platform, refer to the following JCP website:

http://www.jcp.org/en/jsr/detail?id=249

3.1.2 RELATIONSHIP TO MSA CLDC (JSR 248)

Most mobile devices today are built upon the J2ME CLDC (ConnectedLimited Device Configuration) platform. The collective “umbrella”standard that defines the set of most widely supported JavaTM APIs forthe J2ME CLDC platform is known as the JavaTM Technology for theWireless Industry (JTWI) initiative (JSR 185). JTWI devices are alreadyin widespread use in millions of devices, and there is a need for moreadvanced capabilities and features.

The MSA CLDC standardization effort (JSR 248) is currently definingthe next generation mass-market mobile JavaTM platform based on theexisting JTWI standard. MSA CLDC is targeting high-volume, mass-market devices, and it will provide a subset of the functionality offeredby the more capable MSA CDC platform.

For further information on the MSA CLDC platform, refer to thefollowingJCP web site:

http://www.jcp.org/en/jsr/detail?id=248

3.2 BACKWARDS COMPATIBILITY

Backwards compatibility is a critical requirement for the successfuldeployment and evolution of the JavaTM platform. The MSA CDCplatform will be a pure superset of the MSA CLDC platform, i.e., all thecontent developed for the MSA CLDC platform will also run on MSACDC devices. Correspondingly, MSA CLDC devices must be able torun existing JTWI and MIDP applications.

A key requirement in OMTP is to maintain the backwards compatibilityrequirement with MSA and earlier versions of the JavaTM ME platform.As a general principle, OMTP shall not define features that wouldviolate backwards compatibility with existing J2ME applications,devices or standards, unless such features are specified in order to fixserious incompatibilities between existing devices.



of 44

4 IDENTIFIED GAP AREAS/REQUIREMENTSAlthough OMTP is not specifying that all applications must be writtenonly in the JavaTM programming language, there are currently a numberof gaps in the available JavaTM APIs that prevent the preparation of acomplete set of phone applications or system software in the JavaTM

programming language. At present, many proprietary extensions arerequired, and the specification of the JavaTM ME platform is notsufficiently taking into account system issues and the needs of residentsystem applications.

To support the OMTP Java workstream overall goal of defining acompelling and complete platform which meets the needs of OMTP it isalso important to have a common understanding of the scope, featuresas well as the inherent limitations of such an execution environment; interms of UI replacement/customization, execution and interrupt model(non real time), security and access model. Having this in mind will alsoensure a successful adoption by developers and the market at large.Specifically it is envisioned that OMTP JavaTM ME CDC will beparticular well suited to provide UI front-ends to existing end-userapplications exposing network services and device data such asphonebook, bookmarks, messages etc. in a user friendly and highlyextensible and flexible way. It is fundamental that existing devicesoftware can be tapped into from the OMTP JavaTM ME CDC in a fullystandards compliant and secure way while making optimal use of stateof the art device software that already have been certified for andexecute in existing mobile networks.

One of the key goals of the OMTP JavaTM Workstream was to identifygap areas that prevent the industry from moving towards mobiledevices in which the majority of the resident applications and othersystem components are written in the JavaTM programming language.The approach followed by the OMTP JavaTM Workstream was to firstanalyse the relevant gap areas, and then to identify – for each of thegap areas – one or more existing JSR that can possibly fill or reducethe gap. Liaison statements were sent out to existing/ongoing JSRs tosee if those activities could potentially cover the gaps as part of theirongoing work.

The gap areas are summarized in detail in the sections below.

4.1 RUNTIME MANAGEMENT AND ISOLATION

4.1.1 PROBLEM DESCRIPTION

In a phone system that is written mainly in the JavaTM programminglanguage, some JavaTM applications will have the responsibility ofperforming high-level runtime management of other applications.



of 44

“Other applications” may be integral parts of the system, or extraapplications downloaded and installed by the user.

In the absence of effective runtime management, it could be possiblefor an individual application to use an excessive amount of CPU time orother resources, making it impossible to start up new applications (suchas the application to handle incoming phone calls.)

4.1.2 REQUIREMENTS

Given that the runtime management system may be written in theJavaTM programming language, there must be a standardized JavaTM

mechanism for runtime management.

4.1.3 ACTIONS TAKEN

Liaison statements sent to

• JSR 121 (Isolation API)

• JSR 249 (MSA)

• JSR 271 (MIDP3)

4.1.4 RESULTS AND DECISIONS

Note that a new JSR (JSR 278 – Resource Management Framework)is going to be start soon and will focus specifically on resourcemanagement. This can potentially fill the gaps in the area of runtimeresource management of simultaneously running JavaTM applications.

Responses received from JSR 121 and JSR 271 are below:

(From Grzegorz Czajkowski, Sun) JSR 121: Thanks for your comments.Indeed, they touch upon critical functionality, and before proposing thisspecification we the issue of resource management was on the table.However, bundling RM with isolation in one specification would inevitablydelay completing the JSR 121, and there are people for whom there issignificant value in Isolates alone. So the issue of resource managementwon't be addressed in the JSR 121.

However, since the JSR 121 is rapidly approaching completion we (the121 Expert Group) have started to talk about starting another JSR, thistime focused on resource management of J2SE applications. Is itsomething you and/or your company would be interesting in participatingin?

(From Mike Milikich, Motorola) JSR 271 scope does not currently coverthe OMTP Group requirements as stated for runtime management andapplication isolation. The JSR 271 EG is discussing fair application andthread scheduling mechanisms to prevent a single program from denial ofservice attacks, and we anticipate discussions about providing fair accessto other resources within the scope of a MIDP application environment.



of 44

However, any runtime management API is not within the current scopeproposed for JSR 271.

Given this scope for MIDP3, it may be possible to use privileged MIDletsto implement a platform wide AMS for Java as well as native applications.But JSR 271 will not specify this as an inherent part of the AMS, nor willany APIs be developed to include this functionality. JSR 271 will includethe following:

1. JSR-271 will define a method of inter-MIDlet communication.

2. JSR-271 will address the correct operation and management ofconcurrent MIDlets, but will not include runtime management APIs forcontrol of other applications. As in past MIDP specifications, runtimemanagement functionality is within the domain of the AMS. Isolation ofobjects between MIDlet suites will be part of what is required to supportconcurrency.

3. Some additional consideration may be given to concurrency andsynchronization utilities, perhaps in the form of JSR 166 or some subsettherein.

4.2 FILE SYSTEM


Java.io and the Generic Connection Framework file: mechanismsprovide general access to file systems. However, they do not providethe detailed knowledge of how to use the file system in an integratedway on a mobile device. For example, there is no standard way ofknowing where to save a sound file as a ring tone.

A possible resolution to this problem is to define properties for theselocations. Where an application wishes to save a particular data typefor system usage, it should lookup the property based on some criteria.The criteria should include mime type, user (if the OMTP requirementsinclude support for multiple users, and if the device support multipleusers), and usage. This mechanism would allow multiple applicationsto provide services for the same data.

4.2.2 REQUIREMENTS

There must be a standard way for a JavaTM application to identifypredefined file system locations.



of 44

4.2.3 ACTIONS TAKEN

Liaison statement sent to

• JSR 249 (MSA)


According to the MSA expert group, this area will be covered by theMSA Specifications. No further actions were deemed necessary by theOMTP JavaTM Workstream during the last face to face meeting.However it should be noted that the solution in the Public Review draftof JSR-248 may be insufficient for the following reasons:

1. There should be support for multiple locations for storage of standardtypes of content. For instance many devices allow storage in phonememory as well as in memory cards.

2. The system property approach could be extended to define a path,but this makes additional work for every application using theproperties.

3. Dealing with multiple locations for content and whether or not thoselocations are currently “reachable” imposes a lot of overhead onapplication code and fosters code duplication in applications. Thisoverhead could be dealt with much more efficiently by the system,which could present to an application a unified view of what contentis currently available regardless of location, whether removablestorage is present or not, etc, together with events when the contentavailable changes due for example to changes in networkconnectivity, removal of a storage card.

4. Lack of support of any metadata relating to the content (e.g. length ofmusic track) and the characteristics of the places where it is stored(removable, persistent, temporary, secure etc) increases the burdenon applications.. It should be possible for an untrusted application toget information about DRM protected content while not being able todirectly access the actual content. Also, applications should be ableto access metadata such as track length without having to beintimately familiar with all of the corresponding file formats.

5. JSR-75 leaves the implementation of the security model for the filesystem APIs up to the platform, so there is no standard way to definewhat kinds of content (music, ring tones, images, etc) , and what kindof access (read, write, create, delete) an application wants/should beallowed access to, or any way for this to be visible to the user.



of 44

4.3 APPLICATION META DATA


Currently, there is no standardized application packaging solution forJ2ME CDC applications. The CLDC/MIDP platform provides a solution,but it is not currently directly applicable to J2ME CDC.

Applications in are typically composed of the following elements:

• Application Binary: The application itself (the object code)

• Non-Code Resources: These include data required for theoperation of the application

Images

Resource bundles (for I18N)

Data

Application Meta Data (the data NOT fundamental to theoperation of the application, but perhaps useful in thedeployment of the application.)

Examples of Application Meta Data:

• Icon references

• Display Name of Application

• Supported MIME Types

• Versioning Information

• Application library dependencies

4.3.2 REQUIREMENTS

The application packaging solution should meet the followingrequirements:

1. Meta Data SHOULD work with existing CDC application models

2. Meta Data SHOULD make use of JAR file manifest mechanism

3. Meta Data SHOULD provide pre-download properties (AKA JAD)

4. Meta Data SHOULD NOT be required to be provided with anapplication

There already exist a number of specifications that provide support forsome of the features required to support Application Meta Data. Where



of 44

appropriate these facilities should be reused rather than inventing newspecifications.

4.3.3 ACTIONS TAKEN

Liaison statement sent to

• JSR 249 (MSA)

• JSR 271 (MIDP3)


Response received from the JSR 271 expert group is below:

(From Mike Milikich, Motorola) JSR 271 addresses the four requirementsmentioned above.

1. Meta Data SHOULD work with existing CDC application models MIDP3specified meta data should have no conflicts when implemented on top ofCDC, although CDC will not be required.

2. Meta Data SHOULD make use of JAR file manifest mechanismGuaranteed, for MIDP3 / MIDP2 backward compatibility.

3. Meta Data SHOULD provide pre-download properties (AKA JAD)Guaranteed, for MIDP3 / MIDP2 backward compatibility.

4. Meta Data SHOULD NOT be required to be provided with an applicationGuaranteed, for MIDP3 / MIDP2 backward compatibility.

Additionally, JSR-271 will revisit the split between descriptor and manifest,since currently it is somewhat unclear as to which attributes should residein each. Furthermore, some MIDP2 required checks at installationnecessitate the download of the JAR, negating the benefits of separatingattributes into the descriptor.

4.4 PERSISTENT ALARMS


The MIDP API provides the PushRegistry class but this does notprovide the flexibility to define an arbitrary number of time-basedalarms.

MIDP 2.0 has a suitable mechanism available, but it is currently limitedto specifying only one timer-based application launch at a time. CHAPIcould have been a place to do persistent alarms, but it’s based aroundhandling content rather than responding to timers.



of 44

4.4.2 REQUIREMENTS

There must be a mechanism for programmatically specifying a timewhen a particular application should be started. The number of timer-based application launches should not be limited to just one at a time.

4.4.3 ACTIONS TAKEN


• JSR 249 (MSA)

• JSR 271 (MIDP3)

• JSR 232 (Mobile Operational Management).


Responses received from the JSR 232 and JSR 271 expertgroups are below:

(From Jon Bostrom, Nokia) JSR 232 provides a flexible event system bymeans of which it is possible to issue events of different types and registerto be notified when given events occur. Each event has a topic and a setof properties defined in terms of key-value pairs. When registering forevents one has to specify a topic and possibly a filter on the properties. Inparticular the system is able to deal with timer events. These events haveorg/osgi/timer as topic. The properties carried by each timer eventdescribe the year, month, day, hour, minute and second the timer eventoccurred. The event system automatically issues timer events wheneversomeone is registered for receiving one. As an example, if someoneregisters for timer events specifying as filter

(& (hour=12) (minute=0) (second=0))

it will be notified everyday at noon.

Moreover JSR232 allows to request the scheduling of an application whena specific event occurs if needed on a recurring basis. If the application isnot running when the event occurs, the framework automatically starts it.

The possibility of scheduling applications when given timer events occurseems to provide the power and flexibility that OMTP requires in terms ofpersistent alarms.

(From Mike Milikich, Motorola) JSR 271 will provide such a mechanism;however, the proposed time format (yyyymm-dd hh:ss zone_offset) maybe problematic for some MIDP class mobile devices. Timezonedesignations and / or the timezone offset from GMT are not consistentlyknown on devices. MIDP3 will address this area.



of 44

Note that alarm based MIDlet launch is already provided within the MIDP2APIs via dynamic registration. MIDP3 will investigate the addition of staticregistration of alarm based application launch. Note that since alarmbased application launching may not be supported on all platforms, thisfeature will likely remain optional in MIDP3.

With respect to the comment about MIDP3 linking MIDlets to a top level UIwindow, th is is a l ready covered in MIDP2 us ingDisplay.getDisplay(MIDlet) to make the binding. If a device supports awindow system, the implementation can use top level windowsappropriately; the

Display is the top level window for a MIDlet.



of 44

4.5 SYSTEM INFORMATION AND NOTIFICATIONS


In a mobile terminal there is a lot of information that, though beingmade available by the underlying operating system, is not accessibleby JavaTM applications (at least not in a uniform way). Such informationincludes, for instance, information related to network accounts orinformation about installed and running applications. Accessing suchsystem information and system attributes is critical in enabling thepreparation of resident system applications entirely in the JavaTM

programming language.

4.5.2 REQUIREMENTS

1. A JavaTM application must be able to retrieve in a standard way all theinformation included in Table 1.

2. A JavaTM application must be able to register in a standard way to benotified about changes of all information marked with Yes in theListener column in Table 1.

3. A JavaTM application must be able to modify in a standard way allinformation marked with Yes in the Modify column in Table 1.

Notes:

- The Type column in Table 1 contains a suggested type for the valuesof a given element and is included mainly for clarification purposes.

- The mechanism for accessing the attributes and settings needs to beaware of the underlying security practices, i.e., provide access to theseattributes and settings only if the application has the necessarypermissions to do so.

SYSTEM

ATTRIBUTE

DESCRIPTION AND USE CASE(S) FOR 2ND AND

3RD PARTY APPLICATIONSTYPE LISTENER MODIFY

IDENTIFICATION

IMEI

Enables an application to identify the handset:

1. Billing purposes2. Personalization3. Statistics4. QoS measurement String No No



of 44

SYSTEM

ATTRIBUTE



IMSI

For SIM-based devices only. Enables anapplication to identify the subscriber even if hemigrates to another handset:

1. Billing purposes2. Personalization3. Statistics4. QoS measurement String No No

ICCID

For SIM-based devices only. For security,some carriers prefer that applications identifysubscribers via ICCID instead of IMSI. String No No

Brand

Enables an application to identify the handsetbrand:

1. Dynamic brand-specific customizations2. Identification for Error Reporting String No No

Model

Enables an application to identify the handsetmodel:

1. Dynamic model-specific customizations2. Identification for Error Reporting String No No

OS

Enables an application to identify the handsetOS:

1. Statistics (see comment about IMEI)2. QoS measurements (see comment aboutIMEI)2. On-demand download of native code String No No

MOBILE NETWORK

Cell-ID

Enables an application to obtain the ID of thecurrent cell:1. Activate diagnostic measurements in case aproblem is detected in a cell String

Yes:Cell-IDChanged No

RSSI level

Allows the application to know the signalstrength from the current cell:

1. Notification to the user2. Enable diagnostic measurements in case aproblem is detected in a cell (see 9) Int

Yes:RSSI levelchanged No

Neighboring cellRSSI

Enables an application to obtain the powerlevel of neighboring cells:

1. Support finer localization mechanismimplemented at the application level2. Enable sophisticated cell relocationprocesses in case of cell congestion

Array of cell-ID, RSSIlevel couples No No

Available networkaccounts

Enable an application to retrieve networkaccounts currently defined in the terminal

Array ofObjectscontainingtheparametersbelow

Yes:accountadded/removed

Yes: It mustbe possibletocreate/deletenetworkaccounts

- Account name The name of the network account String



of 44

SYSTEM

ATTRIBUTE



- Account APN The name of the APN for the account String

- Bearer type(GPRS, EDGE,UMTS)

Enable an application to obtain the bearer typefor a given account String

Default networkaccount

Enable an application to obtain the name of thecurrent default network account String

Yes:defaultnetworkaccountchanged

Yes: it mustbe possibleto set thedefaultnetworkaccount

Active PDPcontext(s)

Enables an application to obtain data aboutthe current active PDP contexts:

1. QoS measurements

Array ofObjectscontainingtheparametersbelow:

Yes:PDPContextopened/closed

Yes: it mustbe possibleto open aPDPContextusing a givennetworkaccount andclose anactivePDPCOntext

- Account-nameEnables an application to obtain the accountname for the selected active PDP context String

- APN

Enables an application to obtain the APN namefor the selected active PDP context:

1. QoS measurements String

- Bearer type(GPRS, EDGE,UMTS..)

Enables an application to obtain the bear typefor the selected PDP context:

1. QoS measurements String/int

- Negotiatedparameters(service class,bandwidth..)

Enables an application to obtain negotiatedparameters for the selected PDP context:

1. Application can adjust behaviour toaccommodate negotiated parameters.

Properties/Enumeration

- TX and Rxbytes

Enables an application to obtain the number ofbytes transmitted and received for the selectedPDP context:

1. Data for progress bars and/or meters

1. TX bytes(int)2. Rx bytes(int)

APPLICATIONS

Installedapplications

Enables an application to obtain the list of allapplications currently installed in the device.(BOTH native and Java, both preinstalled ordownloaded).

Array ofobjectscontainingtheparametersbelow

Yes: appl.installed/uninstalled/updated

Yes: it mustbe possibleto install/uninstall/update atleast Javaapplications

- Name String



of 44

SYSTEM

ATTRIBUTE



- Version String

- Vendor String

Runningapplications

Enables an application to obtain the list of allapplications currently running in the device

Array ofobjectscontainingtheparametersbelow

Yes: appl.started/stopped

Yes: it mustbe possibleto start/stopan instanceof a givenapplication

- Instance ID

Unique identifier of the running instance (incertain cases there may be two or moreinstances of the same application running atthe same time on the same device) String

- Appl name The name of the application that is running String

Foregroundapplication

The running application that is currently inforeground

An objectcontainingtheparametersbelow

Yes:foregroundapplicationchanged

Yes: it mustbe possibleto bring arunningapplication inforeground

- Instance ID Unique identifier of the instance String

- Appl name The name of the application that is running String

LOCAL NETWORK/CONNECTIVITY

WiFion/off/unavailable

Enables an application to discover if WiFifunctionality is available and if it is on or off:

1. Allows application to adjust behaviour basedon WiFi Availability

int Fields:

UnavailableOffOn

Yes:WiFi statechanged No

Bluetoothon/off/unavailable

Enables an application to discover if Bluetoothfunctionality is available and if it is on or off:

1. Allows application to adjust behaviour basedon Bluetooth Availability

int Fields:

UnavailableOffOn

Yes:Bluetoothstatechanged No

IrDAon/off/unavailable

Enables an application to discover if IrDAfunctionality is available and if it is on or off:

1. Allows application to adjust behaviour basedon IrDA Availability

int Fields:

UnavailableOffOn

Yes:IrDA statechanged No

Data Cableplugged/unplugged/unavailable

Enables an application to discover if a localcable connection is available and if it is on oroff:

1. Allows application to adjust behaviour basedon local cable connection Availability

int Fields:

DisconnectedConnectedUnavailable

Yes:Cablestatechanged No



of 44

SYSTEM

ATTRIBUTE



TELEPHONY

Number of MissedCalls

Enables an application to obtain the number ofmissed calls:

1. Allows an application to notify the user howmany calls they have missed. int

Yes:Number ofmissedcallschanged No

Number of unreadmessages

Enables an application to obtain the number ofunread messages:

1. Allows an application to notify the user howmany new messages they have. int

Yes:Number ofunreadmessageschanged No

MMI

Battery levelEnables the application to inquire the currentbattery level of the device. int No No

Main Displayon/off

Enables an application to know if the maindisplay is switched on or off

1. Allows application to adjust behaviour (i.e.stop drawing to the screen)?2. Enables the application to request thedisplay is switched on?

int Fields:

OffOn

Yes:Maindisplaystatechanged No

Sub Displayon/off/unavailable

Enables an application to know if the subdisplay is switched on or off

1. Allows application to adjust behaviour (i.e.stop drawing to the screen)?2. Enables the application to request thedisplay is switched on?

int Fields:

OffOn

Yes:Sub-displaystatechanged No

Display focus

Enables an application to know which displayis currently in focus:

1. Application can optimize drawingaccordingly

int Fields

MainSub

Yes:Displayfocuschanged No

Keylockon/off/unavailable

Enables an application to know if the keypad isdisabled

1. Behaviour change - (e.g. Demo mode vinteractive mode)1. Notification to the user.

int Fields:

OffOn

Yes:Keylockstatuschanged No

Table 1. System information

4.5.3 ACTIONS TAKEN


• JSR 249 (MSA)

• JSR 232 (Mobile Operational Management).

• JSR 253 (Mobile Telephony API)



of 44

• JSR 256 (Sensor API)


The responses received from the JSR 232 and JSR 253 efforts arebelow:

(From Jon Bostrom, Nokia) JSR 232 seems to have the mechanisms inplace that you are requesting in terms of information retrieval, notificationand modification. These include

• A flexible and extensible event system. This event system providesthe capability to define new event types in a predictable format. JSR232 is currently working to define a core set of events and will reviewyour requests in that area to account and then notify you. JSR 232 willalso publish, as part of the spec, the format for the events which willallow other parties to use that definition to create new event types thatmeet their specific needs. OMTP will therefore be able to encourageother bodies to use the same format to define events that willeventually not be included in the JSR 232 core set.

• A generic API for accessing the DMT (Device Management Tree) anda set of predefined management objects for operational managementsome of which can be used to retrieve and modify systeminformation. Concerning this point however the relation between theJSR 232 and the JSR 246 (Device Management API for CLDC), thatis focusing on similar aspects for CLDC devices, still has to beclarified.

(From [email protected]) JSR 253 will not providemechanisms to retrieve the number of missed calls and unreadmessages. However, although the primary goal of the JSR 253 is tohandle calls and supplementary services, a very basic support of gettingnetwork information is also provided. Therefore, some of featuresmentioned in OMTP requirements for Mobile Network are also covered.Thus, for example, application can require which bearers are currentlyavailable (e.g. UMTS, GSM, CDMA or any other which could be related totelephony). If bearer becomes unavailable then application will receive anotification if an appropriate listener is registered. The same way, if qualityof coverage changes (e.g. full coverage, limited coverage, out ofcoverage), then application will get a notification. Application can querythe default bearer for telephony, e.g. if no specific bearer is chosen whatwould be the default one. Application can also receive the name ofservicing network (provider name) as a string and notification if servicingnetwork has been changed. However, application cannot change anynetwork settings using JSR 253.



of 44

4.6 DIGITAL RIGHTS MANAGEMENT

4.6.1 PROBLEM

Digital Rights Management (DRM) refers to the mechanisms used on acomputing device to protect digital content from unauthorized use. Forinstance, DRM technology can be used to control unauthorized copyingof digital music or video content. There a number of mechanisms thathave been developed and are in use today by various service providersand electronics manufacturers. Despite the growing use of thistechnology, there has not yet been defined a JavaTM programminginterface that allows a JavaTM application to in any way controlprotected content.

4.6.2 REQUIREMENTS

The requirements for DRM have not been discussed formally in thisworkstream so this section should be considered as an outline for amore formal discussion on this topic.

A JavaTM programming interface for DRM should include support for thebasic functions of DRM, querying and changing the policy of content,querying and changing the state of content, and perhaps otherfunctions. Any API should be DRM standard agnostic such that the APIcould be successfully implemented on any of the commonly used DRMschemes in used today.

4.6.3 ACTIONS TAKEN

This document has been edited to include this new section.

4.6.4 RESULTS

This topic should be discussed within the workgroup to determine ifthere is enough interest to include it more formally in this document.



of 44

5 NEXT STEPS

Based on the responses received to the liaison statements, it seemsthat the gap areas identified by the OMTP JavaTM Workstream will notall be covered sufficiently by the forthcoming JavaTM platform standardsand that there is a need to initiate new JCP efforts or otherstandardization activities at least in the area of System Information andNotification. The information exchange with the ongoingstandardization activities will still continue in order to ensure that all thedetails mentioned in the previous chapter will be covered adequately.

The list below summarizes the possible action items for the remainingOMTP JavaTM Workstream activities:

• Compose a revised liaison statement to JSR 253 in order toensure complete feature coverage in the area of systeminformation.

• Compose a new liaison statement to JSR 246 (DeviceManagement) in order to ensure the effective exchange ofinformation between JSR 246 and OMTP JavaTM Workstream.

• Compose a new liaison statement to JSR 278 (ResourceManagement) in order to ensure that this new JSR will take theOMTP requirements into account during its work.



of 44

6 APPENDIX 1: UI TECHNOLOGIES - EVALUATION

CRITERIA & RESULTS

6.1 OVERVIEW

This chapter has been prepared to identify the criteria to effectivelyevaluate two possible user interface technologies for the advancedJavaTM ME platform: JSR 209 and eSWT. The results presented hereare based on the UI Evaluation Task Force initiated by the OMTPJavaTM Workstream.

Note: The UI Technologies evaluation included in this revision of theOMTP Definition and Requirements document includes analyses ofJSR-209 and eSWT. It has been noted that other JavaTM ME UI toolkitspecifications may allow implementation on the CDC specification.Further analysis of these technologies should be considered when theirspecifications become publicly available. The following JSR’s werementioned in face to face meetings of the OMTP JavaTM WorkstreamJSR-258 (Mobile User Interface Customization API) and JSR-271(Mobile Information Device Profile 3) although this list should not beconsidered exclusive of other technologies. The OMTP JavaTM

Workstream will determine which technologies they find relevant.

6.2 EVALUATION BASED ON OMTP UI CUSTOMIZATION USE CASES

The OMTP Board has approved a collection of use cases related to thecustomization of mobile terminals by an operator. They relate to someaspects of the evaluation of UI Technologies. The following use casesare included in this document for informative purposes.

USE CASE DEFINITION

4A: ADD BASIC BRANDING

ELEMENTS

• Brand basic elements of a terminal UI in a consistent manner acrossall terminals, OTA updates possible

• E.g., background, menu items, wallpapers, colour scheme, start-up/shutdown sequences, ring tones, logo, screensaver, etc.

4B: SIMPLE LOOK AND FEEL

CUSTOMISATION

• Customise simple look and feel aspects of a terminal UI in aconsistent manner across all terminals, OTA updates possible

• E.g., splash screens, sounds, status indicators, animations, soft keyarea, etc. plus level 4A elements

4C: DEEP LOOK AND FEEL

CUSTOMISATION

• Define the look and feel of all UI components and their layout in aconsistent manner across all terminals and all applications, OTAupdates possible

• E.g., scroll bar, text entry boxes, buttons, list boxes, notifications,etc. plus level 4B



of 44

4D: BASIC MENU

CUSTOMISATION

• Customise the ordering and labelling of the device menu structureand define device shortcuts and soft-keys, OTA updates possible

• E.g., emphasise and prioritise terminal features, lock specific menuitems, define idle screen shortcuts, etc

4E: SIMPLE APPLICATION

INTEGRATION

• Define the structure of the menu of a terminal UI across allterminals, including the addition of links to operator applications andservices. OTA possible

• E.g., add an offline operator menu structure, access operatorapplication from idle screen, plus 4D

4F: APPLICATION

INTERWORKING CUSTOMISATION

• Customise the structure of Application Interworking Workflowsacross all terminals to define a seamless integration. OTA possible

• E.g. define application interworking workflows (AIW), plus 4E

The following table represents an evaluation of JSR-209 and eSWTbased on the use case definitions described above. This evaluation isbased on the features actually specified in the specifications listed notin any of the underlying technologies, which may be used to supporttheir implementations.

USE CASE JSR-209 ESWT

4A: ADD BASIC BRANDING

ELEMENTS

No direct support, could besupported by an implementation ofPluggable Look and Feel APIs.

eSWT relies on the native toolkit forappearance of the visual elements ofa terminal’s interface. As such, thereis no functionality included in theeSWT specification that addressesthis use case.

4B: SIMPLE LOOK AND FEEL

CUSTOMISATION

JSR-209 is technology that could beused to implement the entire UI ofthe terminal but as an enablingtechnology does not specificallyaddress this use case.

eSWT is technology that could beused to implement the entire UI of theterminal but as an enablingtechnology does not specificallyaddress this use case.

4C: DEEP LOOK AND FEEL

CUSTOMISATION

Support via the Pluggable Look andFeel APIs.

This use case is specifically NOTaddressed by eSWT.

4D: BASIC MENU

CUSTOMISATION

JSR-209 provides the facilities tomanipulate and customize menusas described in the use case,however these features and howthey relate to the operation of theterminal are out of scope for JSR-209.

eSWT provides the facilities tomanipulate and customize menus asdescribed in the use case, howeverthese features and how they relate tothe operation of the terminal are out ofscope for eSWT.

4E: SIMPLE APPLICATION

INTEGRATION

These features are out of scope forany user interface toolkit althoughterminal software could beimplemented with JSR-209 tosupport this use case.

These features are out of scope forany user interface toolkit althoughterminal software could beimplemented with eSWT to supportthis use case.



of 44

4F: APPLICATION INTERWORKING

CUSTOMISATION

These features are out of scope forany user interface toolkit althoughterminal software could beimplemented with JSR-209 tosupport this use case.

These features are out of scope forany user interface toolkit althoughterminal software could beimplemented with eSWT to supportthis use case.

Notes: Some of the features described in requirements 4a, 4b, 4d, 4e,and 4f may be supported in JSR-258 however no publicly availablespecification was available to evaluate it. JSR-258 specificallymentions support for JSR-209 but it may also be applicable to eSWT.

6.3 EVALUATION CRITERIA

The table below summarizes the evaluation criteria that weredeveloped by the OMTP JavaTM Workstream in order to compare JavaTM

UI toolkits in an objective fashion.

CATEGORY CRITERION DESCRIPTION JUSTIFICATION

INTRINSIC

CAPABILITY

Functionality This criterion covers the richness andcompleteness of functionalitypresented to the applicationprogrammer and UI writer.

Completeness is assessed in thecontext of the projected typical UIrequirements of target devices withinthe OMTP target timescale.

One of the reasons for requiring anew UI/graphics platform API tosupplement/supersede lcdui isthe requirement for greaterfunctionality.

Flexibility This criterion covers the intrinsicflexibility of the framework and API,both from the point of view of theapplication programmer and UI writer.Flexibility is taken to mean the abilityof the framework to accommodate awide range of differing requirementswithout requiring extension on theframework or undue upheaval

One of the reasons for requiring anew UI/graphics platform API tosupplement/supersede lcdui isthe requirement for greaterflexibility.

ENGINEERING

COMPATIBILITY

Footprintrequirements

The footprint requirements of thesolution, taking into account bothcode size and runtime memoryrequirements (native and Java ifnecessary).

In order to be deployable to asmany devices as possible,smaller footprint solutions arepreferred.

Processingrequirements

The CPU processing requirements ofthe solution. This is assessed in thecontext of the projected typical UIrequirements of target devices withinthe OMTP target timescale.

In order to be deployable to asmany devices as possible,solutions that are less processor-intensive are preferred.



of 44


Implementationfeasibility/cost

The implementation expense and timetaken of creating and validating asolution, taking into account thecreation of the libraries themselvesand any necessary underlyingextensions to the native platform orUI.

In order to be practicablydeployable to as many devicesas possible, solutions that aredeployable with sooner and withlower engineering cost arepreferred.

Availability ofimplementations for differentplatforms

Are implementations of the solutionavailable currently or in line with theOMTP Roadmap? For how manyplatforms relevant for mobile terminals(and others) these implementationshave been implemented on / portedto?

Availability of implementations ondifferent platforms relevant formobile terminals (and others)gives assurance that the solutionis feasible and implementable onthose platforms with reasonableeffort.

Availability ofCompatibility/ConformanceTests

Do implementations include aregimented and complete set ofconformance tests based on aframework familiar to platformdevelopers.

Compatibility testing ensures thatimplementations from differentvendors interoperate. The suite oftests used to test a platformshould be comprehensive(adequately test the breadth ofthe API) and integrate well withother tests required by theplatform.

RELEVANCE TO

OMTPOBJECTIVES

Specificationfragmentation

The degree to which thetechnology/standard fragments thedevice API/profile landscape (or risksfuture fragmentation).

Specific relevant sub-criteria are:

compatibility with CLDCimplementations

compatibility with lcduiimplementations

ability for the API to scale acrossmultiple device tiers

compatibility with other OMTP groups

As well as “API fragmentation” (wheredifferent devices support differentAPIs) the framework should beassessed in terms of “variantfragmentation” (where multipleimplementations of an application arerequired for different devices ordevice variants, even when thosevariants ostensibly implement thesame API and profiles).

A key aim of the OMTP is toenhance the consistency of userexperience and enhanceapplication programmability byreducing fragmentation inplatform APIs and profiles anddevice variants.

SpecificationMaturity

The degree to which the underlyingspecification has been available in themarket and allowed developerfeedback to improve it’s generalquality.

There is a risk associated withthe introduction of any newtechnology. As much as possiblewe should rely on technologiesthat have allowed applicationdevelopers a significant amountof “seat time” to identify areas forimprovement in the specification.



of 44


Applicationportability

The degree to which client and/orapplication software can be writtenthat can successfully migrate fromone implementation of the standard toanother.

This is strongly determined by thecompleteness and level of ambiguityin the specification.

The standard must allow forindependent implementations. Aspecification proven to supportmultiple independentimplementations is preferred.

Form factorportability

This is the degree to which theframework supports the creation ofapplications that can be portableacross multiple disparate form factorsand input systems.

This is determined by a wide range ofissues, including:

versatility and generality of navigationand traversal model to supportdifferent input systems;

availability of appropriately high levelUI abstractions in addition to onlycomponents/widgets and low levelinteraction system

suitability of available UI componentsto phone input systems, especiallywithout pointer device

flexibility of the UI framework to allowdevelopers to easily create portablecustom components

The standard must preserve theapplication writer’s ability totarget multiple form factors andinput systems. Ideally the formfactor portability should besuperior to that of lcdui. Poorform factor portability willcontribute to fragmentation.

Support formodification ofLAF

This is the degree to which theframework supports the modificationof the look and feel of a platform UI,and the ability for applications to beportable across disparate LAFimplementations/behaviours

A key requirement of OMTP is tomaximise the uniformity oftechnology implementationswhilst permitting operator-specificcustomisations to be deployed. Itis important that thosecustomisations do not contributeto variant fragmentation.

Suitability formixed terminals/warchitectures –Consistency ofthe LAF acrossthe wholedevice

This is the suitability of the frameworkto coexist with other UI technologyelements on devices that supportmultiple content executionenvironments (e.g. native as well asJava).

In the event that there are multipleenvironments, frameworks should beassessed according to the degree towhich consistency of LAF is achievedacross those environments.

OMTP’s desire is to maximise theconsistency of user experienceand it is believed that this shouldbe achievable on platforms thatsupport mixed terminal s/warchitectures



of 44


Suitability formixed terminals/warchitectures –Customisationof the LAFacross thewhole device

This is the suitability of the frameworkto coexist with other UI technologyelements on devices that supportmultiple content executionenvironments (e.g. native as well asJava).

How does the solution allow thecustomisation of the whole deviceLAF in a consistent way?

OMTP’s desire is to maximise theconsistency of user experienceand it is believed that this shouldbe achievable on platforms thatsupport mixed terminal s/warchitectures. Also thecustomisation technology mustallow customising the wholedevice in a consistent way.

Portability ofLAF

This is the ease with which LAFimplementations or customisationsare migrated from one implementationof the framework to another.

OMTP’s aim is to reduce the costof achieving operator-specificcustomisations, and this isreduced if the samecustomisations can beredeployed acrossimplementations from multiplemanufacturers.

Consistency ofLAF acrossdevices

ABC

This is the consistency of LAFimplementations or customisationsacross different devices

OMTP’s aim is to achieveconsistent implementations of anoperator LAF across devices,including devices from differentmanufacturers

Familiarity todevelopercommunity

This is the degree to which theframework is already familiar to thedeveloper community. Some of thecriteria to be considered are:

Size of the developer community

Consistency with the Javaprogramming paradigms

Number of commercial applications

Availability of tools

A framework is preferred if it ismore readily accessible to thedeveloper community.

PROCESS Standardisationprocess

This is the extent to which thestandardisation process for theframework is compatible with OMTPobjectives

OMTP must be satisfied that theprocess for definition,maintenance and enforcement ofthe standard is workable.

Maturity/timescale

This is the extent to which theremaining standardisation work iscompatible with OMTP timescales.

OMTP must be satisfied that thestandard can be adopted andachieve its objectives within therequired timescales.

Licensing What kind of licensing terms theseimplementations have?

OMTP should ensure that thetechnology is available onpredictable and reasonable

licensing terms.

6.4 EVALUATION RESULTS

The table below summarizes the actual JSR 209 vs. eSWT evaluationresults based on the criteria presented in the section above.



of 44

CATEGORY CRITERION JSR 209 ESWT

INTRINSIC

CAPABILITY

Functionality List of JSR 209 UI Components:JButtonJCheckBoxJCheckBoxMenuItemJColorChooserJComboBoxJComponentJDesktopPaneJDialogJEditorPaneJFileChooserJFormattedTextFieldJFormattedTextField.AbstractFormatterJFormattedTextField.AbstractFormatterFactoryJFrameJInternalFrameJInternalFrame.JDesktopIconJLabelJLayeredPaneJListJMenuJMenuBarJMenuItemJOptionPaneJPanelJPasswordFieldJPopupMenuJProgressBarJRadioButtonJRadioButtonMenuItemJRootPaneJScrollBarJScrollPaneJSliderJSpinnerJSpinner.DateEditorJSpinner.DefaultEditorJSpinner.ListEditorJSpinner.NumberEditorJTabbedPaneJTableJTextAreaJTextFieldJTextPaneJToggleButtonJToggleButton.ToggleButtonModelJToolTipJViewportJWindow

List of eSWT UI Components:ButtonCanvasColorDialogComboCompositeControlDialogDirectoryDialogFileDialogFontDialogItemLabelListMenuMenuItemMessageBoxProgressBarScrollableScrollBarShellSliderTableTableColumnTableItemTextTreeTreeItem



of 44


Functionality 2D Rendering APIs:

PaintPaintContextShapeStrokeGradientPaintRenderingHintsRenderingHints.KeyTexturePaintAffineTransformArc2DArc2D.FloatAreaCubicCurve2DCubicCurve2D.FloatDimension2DEllipse2DEllipse2D.FloatFlatteningPathIteratorGeneralPathLine2DLine2D.FloatPoint2DPoint2D.FloatQuadCurve2DRectangle2DRectangularShapeRoundRectangle2DBufferedImageOpRasterOpRenderedImageAffineTransformOpBufferedImageColorModelConvolveOpDataBufferDataBufferIntKernelLookupOpLookupTablePackedColorModelRasterRescaleOpSampleModelSinglePixelPackedSampleModelWritableRasterIIOParamControllerClassesIIOParamImageIOImageWriterImageReaderImageReadParamImageTypeSpecifierImageWriteParam

2D Rendering API:

ColorDeviceFontFontDataFontMetricsGCImageImageDataImageLoaderPaletteDataPointRectangleResourceRGB



of 44


Flexibility JSR 209 and the Swing and Java2D frameworks that they are basedon have been designed from thebeginning to provide a very highdegree of platform independenceand advanced features fordevelopers. In particular thefollowing aspects of thespecification should be noted:

The Swing specification provides aframework allowing platformindependent implementations of aUI toolkit

The Swing specification (and JSR209) allows a high level of platformcustomization in the form ofpluggable look and feelinfrastructure. This will allow boththe behaviour and appearance ofthe UI to be customized on adevice (allowing a consistent lookand feel across devices fromdifferent manufacturers asrequired).

The pluggable look and feelframework can also be used tointegrate with a native toolkit toprovide a native look and feel(using native rendering libraries) toprovide fidelity with nativeapplications (as required)

The Java 2D rendering API allowsJava devices to take advantage ofthe most advanced renderingcapabilities available on devicestoday.

The goal of the SWT project wasto provide a UI toolkit for theEclipse IDE that was tightlycoupled with the native toolkit.This philosophy allows theimplementer of the toolkit to verytightly bind an SWTimplementation to a native toolkitincluding support for platformspecific features.(http://www.eclipse.org/rcp/)Only the customization providedby the native toolkit is supportedby SWT. An implementation canonly include the look and feelprovided natively by the device.



of 44


ENGINEERING

COMPATIBILITY

Footprintrequirements

Varies based on whether Swingimplementation is built in the Javaprogramming language or a nativetoolkit.

Varies based on whether Swingimplementation is built in the Javaprogramming language or a nativetoolkit. Native toolkitimplementations can be the sameor smaller than an equivalent SWTimplementation. Java Swingimplementation would includefunctionality included in eJFace(and not part of core eSWT).

Varies depending on the nativetoolkit, target size for the bindinglayer is approximately 150k

Most of eSWT covered byexisting native code Additionalwidgets may be implemented bynative or Java.

Target size is 300-500k (Takenfrom v 0.9.2 of eSWT HLA):

· Core eSWT– 300k

· Expanded eSWT – 200k

· Mobile Extensions – 200k

Note that these numbers do notinclude eJFace which

would be required for functionalityparity with JSR 209.

Processingrequirements

Optimized for mobile phones. Optimized for mobile phones.

Availability ofimplementationsfor differentplatforms

Not yet announced. MS Windows, MS WindowsMobile, and Nokia Series 80.

Availability ofCompatibility/ConformanceTests

Conformance tests will be basedon the J2SE conformance tests.These tests have been developedand released on multiple releasesof J2SE and adapted to JSR 209.They will be released when JSR209 is released.

Compatibility tests will beavailable from the Eclipse project.They have been developedspecifically for eSWT and will bereleased for the first time witheSWT.



of 44


RELEVANCE TO

OMTPOBJECTIVES

Specificationfragmentation

JSR 209 is intended to leverage themillions of developers and toolscurrently targeting J2SE and J2EE.The Swing and Java 2D APIs whichJSR 209 is based on represent thelargest segment of the JavaDeveloper Community. Providingan API familiar to these developerswill provide operators withincreased availability of compellingcontent for the mobile platform.

JSR 209 is targeted at mid-Tierdevices and is intended to provideadvanced graphics and UI supportto developers. There is no intentionin allowing direct compatibility withLCDUI implementation, howeverintegration of JSR 209 and LCDUIimplementations has beendemonstrated.

The JSR 209 can only besupported on CDC platforms.

ESWT is based on the SWT APIswhich have had some limitednotoriety in the industry. Itsdesign is focused aroundproviding a Java binding to anative toolkit.

ESWT is only supported on CDCplatforms. (Note: From eSWTspecification overview, “eSWTprovides a core UI API that Javaapplications can rely on and canbe used in any applicationmodels or architectures that havesupport for full Java VMspecification.” (CLDC is not a fullJava VM)

SpecificationMaturity

The JSR 209 specification is basedon the J2SE Swing API’s whichhave been developed and refinedsince 1997. They have beendeveloped to insulate the developerfrom the details of the underlyingoperating environment and allowthe production of portableapplications.

SWT was first introduced in 2001as part of the Eclipse IDE project.



of 44


Applicationportability

The Swing platform was developedto provide a high degree ofapplication portability.

For instance, focus management isconsistent across implementationsof Swing on different platforms.

Although application portability isimportant to the SWT platform,the authors of SWT make clearthat developers can not dependon the platform to provide adependable level of crossplatform consistency and this isnoted as part of the design of theSWT framework. “developersneed to understand thatapplications can potentiallybehave differently to match theoperating system behaviour”(fromhttp://dev.eclipse.org/viewcvs/index.cgi/platform-swt-home/main.html?rev=1.11)

The SWT design allowsimplementations to compensatefor different behaviour in theunderlying toolkit. For instance,some toolkits may automaticallyset the focus of a UI componenton a particular platform andgenerate an event to indicate thisto the application.

Nokia does not agree with thiswording, however it representscontent from the Eclipse projectwebsite.

Support formodification ofLAF

The JSR 209 EG has reconsideredincluding support for PLAF APIs asper a request from the OMTP JavaWS. A first revision of the PLAFAPIs appeared in the PublicReview version of the JSR 209specification recently approved bythe Java Community Process.

ESWT depends on the underlyingUI toolkit to define the look andfeel of the UI.

Suitability formixed terminals/w architectures– Consistency ofthe LAF acrossthe whole device

The look and feel of the JSR 209toolkit is subject to theimplementation of the look an feel.

ESWT only allows for the nativelook and feel to be supported.

Suitability formixed terminals/w architectures– Customisationof the LAFacross the wholedevice

As supported by a look and feelimplementation.

Only as supported by the nativetoolkit.



of 44


Portability of LAF A Look and Feel can implementedin the Java Programming languagewhich would allow a consistent lookand feel across devices fromdifferent manufacturers.

The Swing architecture allows for aLaF to be defined separately fromthe toolkit implementation. Althoughnot currently part of the public JSR209 API, a look and feel could beconstructed that represented aparticular brand or company andthen be deployed on anyappropriately implemented JSR209 platform regardless of theunderlying operating system or UItoolkit. The "Metal" look and feelwhich is included in J2SE is atoolkit independent look and feeldeployed with all J2SE platforms(Windows, Mac, Linux, Solaris,etc).

In summary:

1. The UI can be independent ofthe native widget-set, therefore theJava LaF may be different form thenative LaF on the terminal (this isan implementation detail).

2. The UI will be consistent acrossall Java applications, but notnecessarily between native andJava applications (this is animplementation detail).

3. JSR 209 Public Review Draftincludes support for pluggable lookand feel.

If custom widgets are used, theywill provide the same LaFregardless of the device beingused (as long as each deviceuses the same native toolkit).eSWT APIs will be tightlyspecified to ensure consistentbehaviour across differentplatforms implementations(however the SWT architectureallows for platform differences tobe exposed to applications).

Native side and all Java UItoolkits in a technology agnosticway through JSR 258. Resultsinto operator LaF on the wholedevice and into the possibility tocombine native and Javaapplications in an optimised way.

JSR 258 when completed mayprovide some level of UI skinningof a native toolkit.



of 44


Consistency ofLAF acrossdevices

JSR 209 is based on the "Swing"user interface toolkit.

The Swing toolkit was designed toallow the implementation of a UserInterface toolkit entirely in the JavaProgramming Language. JSR 209has tightened the Swing portion ofthe specification in a way thatallows JSR 209 to be implementedboth on a native toolkit or in theJava Programming Language.

In the case where JSR 209 isimplemented in the JavaProgramming Language, theimplementation of the toolkit Lookand Feel is entirely defined by theimplementation of the specificationand not the underlying toolkit.(JavaUI implementation)

If JSR 209 is implemented with anative look and feel, the nativetoolkit provides the look and feelcapabilities. Thereforeindependence from the underlyingwidgets can only be guaranteed byJSR 209 when a Java Look andFeel is used.

SWT's architecture provides athin layer around the native toolkitand retains only the look of thenative toolkit. From eclipse.org"The Standard Widget Toolkit(SWT) is a widget toolkit for Javadevelopers that provides aportable API and tight integrationwith the underlying native OSGUI platform." In other words, theunderlying native toolkit willprovides the Look and Feelcapabilities so they can not beindependent.

If standard widgets are used,eSWT applications will inherit theLaF that is appropriate for thedevice, thereby providing a userexperience that blends withnative applications. However, aneSWT may choose to createcustom widgets that provide aspecific LaF independent of theunderlying toolkit.

eSWT can be implemented withpure-Java in the same fashion asSwing. So if a eSWTimplementation is done so thatLAF is wanted to be different thanth native implementation then it'sof course possible and eSWT canhave whatever LAF needed.Often, however, this is not adesirable implementation as itgives user non-unified userexperience of a device with therest of the device UIs.

Familiarity todevelopercommunity

The Swing UI toolkit from whichJSR 209 is based has been usedto develop hundreds of commercialapplications many of which arelisted here:http://java.sun.com/products/jfc/tsc/sightings/index.html

Few commercial applicationshave been developed for SWT.

PROCESS Standardisationprocess

The wireless industry standardprocess for the development ofJava programming interfaces, theJava Community Process. Thecurrent JSR 209 specification effortincludes software platformproviders, OEMs, and operators.

The open source communitythrough the Eclipse project.



of 44


Maturity/

timescale

Swing was first released in 1997 aspart of JDK 1.2 and refined in JDK1.3, and JDK 1.4. JSR 209 wasinitially approved by the JavaCommunity Process in March 2003.Development continues with inputfrom the Java Community and willcomplete before the end of theyear.

SWT was introduced as an opensource project in 2001 and theeSWT project began sometime in2004.

Licensing Information on licensing can befound on the JCP website:http://www.jcp.org/en/jsr/detail?id=209

Eclipse Projects are typicallylicensed under the “CommonPublic License”

Note: As stated in the Overview of this section, the OMTP JavaTM

workstream agreed only to consider technologies described in publiclyavailable specifications. When discussed in the last face to facemeeting, the JSR 258 specification was not yet publicly available. Theplanned features of JSR 258 may possibly enhance the ability tocustomize mobile terminals, and as stated in the JSR text will becompatible with JSR 209 and potentially eSWT as well.



of 44

7 ABBREVIATIONS

ABBREVIATION DESCRIPTION

3GPP 3rd Generation Partnership Project

OMTP Open Mobile Terminal Platform

OTA Over The Air

WAP Wireless Application Protocol

JCP JavaTM Community Process

JSR JavaTM Specification Request

CDC Connected Device Configuration

CLDC Connected Limited Device Configuration

MIDP Mobile Information Device Profile

JAVATM

ME JavaTM Micro Edition

JAVATM

SE JavaTM Standard Edition

MSA Mobile Service Architecture



of 44

8 REFERENCED DOCUMENTS

NO. DOCUMENT AUTHOR DATE

1 RFC2119(http://rfc.net/rfc2119.html)

RFC March 1997

omtp technology assessment · 2016. 5. 4. · 1 preface. 1.1 document purpose. this document is the...

Documents