Sony Ericsson
Thursday, 21 April 2005
Last week we looked at Project Professional, an application which used the Sony Ericsson P910i's Java support for project management. Sony Ericsson have a comprehensive Java strategy, from their Symbian OS powered phones down. This paper from Sony Ericsson explains the strategy.Sony Ericsson has adopted a Java platform strategy for its mobile phones which we believe is key to supporting content developers in their struggle to create applications for a multitude of phones. Currently, there are five Java Platform versions used for Sony Ericsson feature and mass-market phones, and two for Sony Ericsson smartphones. By making Sony Ericsson's Java Platform Strategy public to the developer community, our aim is to help developers concentrate on enhancing the game-playing experience for the end-user instead of spending all of their time on porting issues. When new Java Platform versions are introduced in the future, we plan on making these public also.
Below we present the background to this Java Platform Strategy as well as the contents of each Java Platform version used in Sony Ericsson phones.
Background - Opportunities & Challenges for Java Content Market
The Java™ technology enabled handset and mobile games market is booming. New games and Java enabled handsets are released across the globe on a daily basis (there will be a total of about 2 billion mobile phone users in the world within the next year or so, of which, according to Ovum, there are today 450 million Java-enabled handsets globally), representing potentially the biggest platform for electronic games in the world The anticipated growth in mobile Java applications is tremendous, the latter driven by the increased availability of J2ME MIDP 2.0 and JSR-184 enabled phones.
For Java content developers this represents a great market opportunity: to establish new brands and titles, and to make money. But however great these market opportunities seem, mobile game developers are faced with one major challenge: how to get their games to work on hundreds of devices for many different mobile operators and languages worldwide.
The challenge consists not only in that the phones are based on different JSR's, but also that different handset manufacturers have implemented the same JSR's differently, in some cases even doing unique implementations for each new device. Most developers start by programming their game for one or two key phones on the market, based on either volume considerations or key technology features supported, or a combination of both. But then each game must be ported to and quality assured on a broad range of phones to maximize market value. Developers in general have to either spend a lot of time on porting issues in order to publish their applications for as many handsets on the market as possible, or settle for a sub-set of the phones.
To summarize, content developers may find themselves in one of the following dilemma:
- They end up spending a major part of their work learning the specifics of each phone and J2ME platform implementation, and then doing porting work. Less time is available for development of new games and applications which are needed to secure future income and growth.
- They must consider the least common denominator working feature-set across phones in order to have truly portable content. Since the quality of implementation and the number of features of J2ME enabled phones differ a lot, it prevents innovation and effective use of new features.
- They are forced to focus on a sub-set of phones available on the market in order to optimize the outcome of their work.
Porting work facilitated through platform strategy
Even though many handsets support the same API set, interoperability is not guaranteed. The detailed behavioral semantics of a J2ME enabled phone normally differ between each handset. It can be anything from screen size, execution speed, memory management, 2D and 3D graphics sub-systems, networking system, Bluetooth sub-system, etc, and even implementation issues - the list can be made long. The reason is that the major part of the behavior is defined by the mobile hardware and software platform in which the Java environment resides. And in many cases this represents a device unique platform.
Sony Ericsson actively works to minimize the differences in behavior between its J2ME enabled phones by having a platform strategy and an evolutionary approach to its Java implementations. This effectively means that we minimize the number of platforms for developers to work with. The idea is to maximize interoperability and minimize differences between Sony Ericsson phones supporting J2ME, with the objective of minimizing the effort and learning required to program for different Sony Ericsson phones once you have programmed for one of them.
Some by-now rather old porting help how to adapt your MIDlets from Nokia Series 40 to Sony Ericsson phones, and a recent paper on how to port games and other applications from BREW to J2ME and to Sony Ericsson phones can be found here>>
Sony Ericsson Java Platforms
Sony Ericsson has two main J2ME platform paths for its phones; one for its Symbian OS based smartphones and another one for its feature and mass-market phones, i.e. the non-Symbian OS based phones. Both of these J2ME platform paths are implemented through an evolutionary approach in order to maximize backwards and forwards compatibility between platform versions. Normally each platform version is used in several phone models, e.g. the K300, K500, K700 and S700 series share the same J2ME platform version. This means that both quality assurance and end-user experience is shared between these phones to a very large extent. It also means that porting applications is made much easier for content developers.
A list of Sony Ericsson J2ME platform versions and which phones that are based on them can be found below. This will help content developers plan, program and target their Java applications to the greatest number of phones possible.
Sony Ericsson has made some Java features in its Java Platforms optional, i.e. configurable. These optional features are added when it makes sense to do so, for example, the Bluetooth API's (JSR-82) are only enabled for a specific phone based on a specific Java Platform version when the phone actually supports Bluetooth radio communication.
Java Platforms for Sony Ericsson feature and mass-market phones
JP = Java Platform
JP-1
Phones
Features
CLDC 1.0, MIDP 1.0, JSR-135
T610/T616/T618, Z600/Z608, T628/T630/T637
Optional
JSR-120
T616, T637
JP-2
Phones
Features
CLDC 1.1, MIDP 2.0, JTWI (JSR-185), JSR-120, JSR-135, Nokia UI API 1.1
Z1010
JP-3
Phones
Features
CLDC 1.1, MIDP 2.0, JTWI (JSR-185), JSR-120, JSR-135, Nokia UI API 1.1, JSR-184, Mascot Capsule Ver. 3
K700, K500, K506, K508, F500, S700, S710a, K300, J300, Z500
JP-4
Phones
Features
CLDC 1.1, MIDP 2.0, JTWI (JSR-185), JSR-120, JSR-135, Nokia UI API 1.1, JSR-184, Mascot Capsule Ver. 3
V800, Z800
Optional
VSCL 2.0
V800
JP-5
Phones
Features
CLDC 1.1, MIDP 2.0, JTWI (JSR-185), JSR-120, JSR-135, Nokia UI API 1.1, JSR-184, Mascot Capsule Ver. 3, JSR-75
K750, W800, K600, D750
Optional
JSR-82
K750, W800, K600, D750
Java Platforms for Sony Ericsson smartphones (Symbian OS phones)
JP-1 Symbian OS
Phones
Features
CLDC 1.0, MIDP 1.0
Sony Ericsson P800
JP-2 Symbian OS
Phones
Features
CLDC 1.0, MIDP 2.0, JSR-135, JSR-120, JSR-82
P900, P910
Optional
JTWI (JSR-185)
P910
For a complete technical description, refer to the Java Developers' Guidelines.
Harmonization of screen sizes
Another challenging porting issue for content developers is usually the varying screen sizes on the market. To facilitate porting to and between Sony Ericsson phones, we have decided to support the following five screen sizes:
Phone segment
Screen size
Phones available
Entry - low
128x128 pixels
K300, J300
Entry - mid
128x160 pixels
T610/616/618, T628/630/637, Z500, Z600/608, K500, K506, K508, F500
Mid - High-end feature phones
176x220 pixels
K750, D750, W800, K600, K700, Z1010, V800, Z800
QVGA
240x320 pixels
S700, S710a
Smartphones
208x320 pixels
P800, P900/902/908, P910
|