Tuesday, May 7, 2013
Overview
of presentation
Introduction to Java 2
Platform Micro Edition (J2ME)
Flavours of Java Platform
·
J2SE
(Java 2 Platform Standard Edition)
·
J2EE
(Java 2 Platform Enterprises Edition)
·
J2ME
(Java 2 Platform Micro Edition)
Where
J2ME fits in the overall java specification
J2ME
building blocks
- Configurations
- CLDC (Connected
Limited Device Configuration)
- CDC (Connected
Device Configuration)
- Profiles
- KVM (K
Virtual Machine)
- CVM (C Virtual Machine)
MIDP (Mobile Information
Device Profile)
J2ME
related technologies
- Java card
- Java TV
Application of J2ME platform
The Clash of Mobile Platforms
·
ExEn
·
Mophun
·
WGE
Advantages of J2ME
Conclusion
Introduction to
Java 2 Platform Micro Edition (J2ME)
The Java 2 Micro Edition encompasses the full range of
products, technology, tools and standards needed to enable the information
appliance market. It currently includes two different implementations of the
Java virtual machine:
- A Java virtual machine
suitable for 32-bit RISC/CISC/DSP microprocessors and a few megabytes of
working memory. Typical products in this market include screen phones,
set-top boxes and high-end PDAs.
- A Java virtual machine
suitable for 16-bit or 32-bit RISC/CISC microprocessors with a few hundred
kilobytes of available memory. Typical products in this market include
cell phones, low- to mid-range PDAs and low-end set-top boxes.
Because Java 2 ME includes both in-device and off-device
elements, it provides an end-to-end architecture for device manufacturers,
service providers, and independent software vendors. The end-to-end
architecture leverages and integrates such key Sun technologies as JiniTM and Java Embedded ServerTM.
The technology leader in the mobile
space over the past year has been Sun Microsystems Inc.'s Java 2 Platform Micro
Edition, or J2ME. Industry heavy weights across the board lined up to announce
support and J2ME-capable devices now are available worldwide. Despite this, it
is clear that J2ME is emerging as the common mobile development platform for
application developers interested in writing one application and deploying that
application to multiple device types. However, we need to be clear that J2ME's
extreme portability also introduces several technical disadvantages as well.
Wireless technology is evolving at a
rapid pace. There is a lot of talk about mobile and wireless computing and
there is also a fair amount of hype. However, the one thing that is
conspicuously absent from much of these discussions on mobile and wireless
computing is a discussion on what these devices are connecting to. The fact is,
most of the value, in terms of content and capabilities of the device, is a
result of interacting with a server of some type. This is true whether we are
talking about micro browsers such as WAP and iMode, J2ME clients, or short
message service (SMS) and email. Behind the scenes these devices are
interacting with services that reside somewhere on a network. These services
handle much of the complex details of the features offered by wireless devices.
Although there are complexities that the mobile device must deal with, a
well-designed wireless architecture delegates as much complexity as possible to
the server. This is desirable because servers have more processing capabilities
and do not have the power restrictions of mobile devices (i.e., servers don't
run on batteries that are worn down by the CPU). This article examines wireless
computing from the server's perspective
Flavors of Java Platform
Summary:
q Driving forces
q Penetration in a wide variety of market segments: wristwatch, washing
machine, IP router, web server, video games etc.
q Different devices have different requirements and different expectations
of Java.
q One platform (solution) cannot address all the market segments.
q Users/developers want flexibility. They want to choose what they want to
use and what they do not.
Good strategy?
J2SE
q Feature complete Java foundation
q Client side enterprise development: stand
alone applications & web applets
q 2 binary deliverables
§ JDK: Application development
§ JRE: Runtime environment
q Example: desktop or workstation
J2EE
q Distributed applications
q Server side enterprise application
q Multi-tier application model
q Middle-tier contains business logic and
system services
q Scalability, manageability, accessibility
Examples:
JDBC, Components, CGI etc
J2ME
q Characteristics
q Limited memory: 128K to 2 Meg
q Limited computational power
q Either mobile or plug-in devices
Mobile à battery powered
q Requirements
q Built-in consistency across products
q Power of OO programming language
q Code portability
q Safe network delivery
Upward scalability (to J2EE & J2SE)
Where J2ME fits in the overall java specification
Introducing wireless devices into an
architecture comes with some challenges that are not present in a wire-based
architectures. These challenges must be managed from the server as well as the
device. Although there are a number of issues to consider, the three following
issues are most critical when connecting to Internet-based services over a
wireless connection.
- Bandwidth: The wireless networks
available today are much slower than wire-line services. Connection speeds
range from 2 kbps to about 20 kbps depending on the type of network and
signal strength.
- Service availability: Wireless networks have dead spots and limited
- coverage outside of
heavily populated areas. What's more, connections between a device and the
server can drop unexpectedly if a user moves out of coverage or steps into
a dead spot by walking into an elevator, entering a stairwell and so
forth.
- Cost of the wireless
service:
Some networks offer unlimited usage, others charge by the kilobyte while
others charge by length of time connected. Furthermore, users may move in
and out of roaming areas while operating a device. A wireless architecture
needs to take these issues into consideration in order to optimize network
usage and avoid large service bills.
Optimizing Communication
In order to optimize how the server
communicates with a wireless device, it is desirable to keep the communication
to a minimum. If possible, a connection between the server and device should be
opened just long enough to exchange some data and then close down. Modems on
mobile devices tend to consume a lot of battery power, which is a precious
resource for a mobile device. Furthermore, some network providers, such as
those operating on CDMA networks, tend to charge by amount of time connected.
Keeping the connection open longer than necessary becomes unnecessarily expensive.
The Wireless Challenge
Hopefully by now you are getting an idea of
the challenges faced by wireless applications. In the sections that follow, a
number of communication models are introduced that help manage these problems.
As with most solutions, there are pros and cons with each approach. Therefore,
it is important to understand the benefits and weaknesses of each model so the
appropriate model can be applied for a given situation.When data is transmitted
in the other direction, from the device to the server, the communication only
requires a single request, since the server's reply contains the confirmation.
If the transmission is successful, the device may take action on the
information sent to the server, such as remove it from its data store
Configurations
The Java 2 Micro Edition can be deployed in multiple
configurations. A configuration is defined as a set of optimized Java APIs,
class libraries and a virtual machine targeting a family of devices with
similar requirements on size and capabilities. Configurations include
components of the java.io, java.net, java.util, and the java.lang packages.
Sun, in conjunction with industry partners, will define
and evolve the Java 2 Micro Edition and its configurations. This is done with
the JCP (Java Community Process). The Java 2 Micro Edition includes two
standard configurations, which are subsets of the Java 2 Standard Edition core
APIs, and which will fit in 128k of ROM.
Connected Limited Device
Configuration (CLDC)
Summary:
·
160
Kbytes to 512 Kbytes of total memory available.
16-bit
or 32-bit processor.
·
Low
power consumption and often operating with battery power.
Connectivity
with limited bandwidth.
CLDC Specifications
The Connected Limited Device
Configuration (CLDC) is one of two configurations defined through the Java
Community Process as part of Java 2 Platform, Micro Edition (J2ME). CLDC is the
foundation for the Java runtime environment targeted at small,
resource-constrained devices, such as mobile phones, pagers, and mainstream
personal digital assistants. CLDC, combined with the Mobile Information Device
Profile (MIDP), is the Java runtime environment for today's
resource-constrained mobile information devices (MIDs) such as phones and entry
level PDAs.
Currently, two versions of the CLDC
specification are available:
1.
CLDC 1.0 (JSR-37)
2.
CLDC 1.1 (JSR-139)
CLDC 1.1 is a revised version of the
CLDC 1.0 specification, and includes new features such as floating point and
weak reference support, in additional to other enhancements. CLDC 1.1 is
backward compatible with CLDC 1.0, and continues to target small and
resource-constrained devices with the objective of maintaining a tight
footprint.
CLDC RI
1.1:
This version of the CLDC reference implementation is based on the CLDC 1.1
specification and is targeted at device manufacturers who want to port this
J2ME configuration to another platform.
CLDC RI 1.0.4: This
version of the CLDC reference implementation is based on the CLDC 1.0
specification and is targeted at device manufacturers who want to port this
J2ME configuration to another platform.
MIDP
RI 2.0: This
version of the MIDP reference implementation is based on the MIDP 2.0
specification and supports the CLDC RI 1.0.4. The MIDP RI is targeted at device
manufacturers who want to port this J2ME profile to another platform.
Connected Device Configuration (CDC)
Summary:
2Mbytes
or more memory for Java platform
32-bit
processor
High
bandwidth network connection, most often using TCP/IP
The JDBC Optional Package for CDC-Based J2ME
Applications
The Connected Device Configuration
(CDC) is at the heart of the Java 2 Platform, Micro Edition, supporting
applications on high-end network-connected devices such as home appliances,
set-top boxes, interactive TVs, and handheld PCs. It's natural to expect that
many applications written for these devices will need access to information in
databases, possibly from different vendors. In applications written for the
Java 2 Platform, Standard Edition (J2SE), the Java Database Connectivity (JDBC)
API provides this kind of access. To provide CDC-based applications with
database access, a subset of the JDBC 3.0 API has been defined as the JDBC
Optional Package for CDC/Foundation Profile API.
This article presents an overview of
optional packages and shows where they fit in the J2ME architecture, and then
explores the JDBC optional package in more detail, comparing and contrasting it
with JDBC 3.0. The article:
- Summarizes
the similarities and differences between the JDBC optional package and
JDBC 3.0
- Describes
briefly each of the interfaces, classes, and methods that the optional
package has inherited from JDBC 3.0
Overview of
Optional Packages
As you may already know, the J2ME
defines two main components:
- Configurations,
composed of a Java virtual machine and a minimal set of class libraries.
Think of a configuration as a vertical set of APIs that provides the base
functionality for a particular range of devices that share similar
characteristics, such as memory footprint and network connectivity. A
configuration also defines a Java virtual machine to be used on different
types of devices.
- Profiles,
a horizontal set of high-level APIs that defines the application
life-cycle model, the user interface, and access to services provided by a
category of devices.
Profiles extend configurations, and
can themselves be extended by other profiles - and by optional packages, which
offer standard APIs for using existing and emerging technologies to address
specific market requirements. Figure 1 illustrates the software stack that
includes the CDC and the Foundation Profile (CDC/FP):
At this writing, the Java Community
Process has defined two optional packages for CDC/Foundation, one for Remote
Method Invocation (RMI) and one for JDBC. The J2ME RMI Optional Package (RMI
OP) is defined by JSR 66, and the JDBC Optional Package for CDC/Foundation
Profile by JSR 169.
The RMI optional package is a subset
of the RMI technology in J2SE. It enables applications written in the Java
programming language and running on CDC-based networked devices to invoke each
other's methods, and the methods of J2SE applications running on larger
systems. The RMI optional package and JDBC 3.0 thus enable developers to create
applications distributed across a variety of Java virtual machines, running on
platforms ranging from handheld devices to network servers. The RMIOP reference
implementation can be built with implementations of CDC/FP, including those
extended by the Personal Basis Profile.
Overview of Changes
The JDBC 3.0 API of J2SE includes
functionality that is not applicable for, or not supported by, CDC/Foundation.
As a result, some APIs had to be removed. The
JDBC optional package is a strict
subset of JDBC 3.0, however, so applications built using JDBC CDC/FP are
upwardly portable to JDBC 3.0. Details appear later in this article, but here
is a summary of the changes that have been made:
- Support
for connection pooling has been removed.
- The
classical way of creating connections, using the
DriverManagerinterface, has been replaced. As a result, the interfacesDriverManager,Driver, andDriverPropertyInfohave been removed, along with the methodsDatabaseMetaData.getURL(),RowSet.setURL(), andRowSet.getURL(). You should use theDataSourceinterface, which minimizes the connection overhead, to create connections. - The
exception classes no longer write details of thrown exceptions to the log,
but driver vendors write the output of
toString()to the log. ThetoString()method is overridden bySQLExceptionand all its subclasses. - The
interface
ParameterMetaDatahas been removed. - Support
for setting parameters by name in the
CallableStatementinterface has been removed. - Support
for SQL 99 types using the interfaces
Array,Ref,Struct,SQLData,SQLInput, andSQLOutputhas been removed. - The
methods
setTypeMap()andgetTypeMap()have been removed, so you can't use them to perform custom type mapping.
Inherited Classes and Interfaces
The
JDBC optional package for CDC/Foundation has inherited from J2SE's
java.sql package the interfaces and
classes described in Tables 1, 2, and 3:
Table
1: Interfaces Inherited from the
java.sql Package
|
Table 2: Classes Inherited from the
java.sql
Package
|
Table 3: Exceptions Inherited from the
java.sql
Package
|
Table 4: Interfaces and classes
inherited from the
javax.sql
package
|
Profiles
An additional way of specifying the subset of Java APIs,
class libraries and virtual machine features that targets a specific family of
devices is the profile.
A profile is a collection of Java
technology-based class libraries and APIs and a specific configuration that
provides domain-specific capabilities for devices in a specific vertical
market.
Executive Summary (KVM)
Over the last two years Sun has introduced tailored JavaTM virtual machine technology
to serve products in the consumer and embedded markets. With PersonalJavaTM technology targeted at
screen phones, high end PDAs and set top boxes, and Java CardTM technology targeted at smart
cards, Sun has greatly extended the scope of the Java programming environment.
In the process, Sun has demonstrated the versatility of this environment and
enabled the development of many new and powerful information appliance
products.
The K virtual machine (KVM) is Sun's
newest Java virtual machine technology and is designed for products with
approximately 128K of available memory. The KVM fills a very important role in
Sun's Java virtual machine product offerings, and will form a part of a
completely new Java runtime environment. This environment is highly optimized
for small-memory limited-resource connected devices such as cellular phones,
pagers, PDAs, set-top boxes, and point-of-sale terminals.
The KVM has been developed as part of
larger effort to provide a modular, scalable architecture for the development
and deployment of portable, dynamically downloadable, and secure applications
in consumer and embedded devices. This larger effort is called the Java 2
Platform Micro Edition (Java 2 ME). Connected, personalized, intelligent tools
are becoming increasingly important in our business and private lives. Java 2
ME is an architecture designed to address the specific technical requirements
of these new information appliances.
While connected consumer devices like
pagers, cell phones and PDAs have many things in common, they are also diverse
in features, form, and function. Information appliances tend to be
special-purpose, limited-function devices, not general-purpose computing
machines like servers and desktop systems. Serving this market calls for a
large measure of flexibility in how Java technology is deployed. Flexibility in
deployment is also important because over the lifetime of any one connected
device, its applications and capabilities can change and grow to accommodate
the needs of the user. Users want the ability to purchase economically priced
products with basic functionality and then use them with ever-increasing
sophistication. Java technology enables users, service providers, and device
manufacturers to take advantage of a rich portfolio of application content that
can be delivered to the user's device on demand, by wire or over airwaves.
The Java 2 ME architecture is modular
and scalable so that it can support the kind of flexible deployment demanded by
the consumer and embedded markets. For low-end, resource-limited products, Java
2 ME and the KVM support minimal configurations of the Java virtual machine and
Java APIs that capture just the essential capabilities of each type of device.
As device manufacturers develop new features in their devices or service
providers develop new and exciting applications, these minimal configurations
can be expanded with additional APIs or with a richer complement of Java
virtual machine (Java VM) features. While the KVM is targeted at devices
containing 16- or 32-bit processors and a total memory footprint of
approximately 256K bytes, KVM can be deployed flexibly to address a range of
trade-offs between space and functionality. In addition, Java 2 ME provides a
range of virtual machine technologies, each optimized for the different
processor types and memory footprints commonly found in the consumer and
embedded marketplace.
The KVM is engineered and specified to
support the standardized, incremental deployment of the Java virtual machine
features and the Java APIs included in the Java 2 ME architecture. The Java 2
ME architecture defines a small core API which must be fully implemented in
every Java 2 ME compatible device. Java 2 ME is deployed in several
configurations. Each configuration addresses a particular "class" of
device and specifies a set of APIs and Java virtual machine features that users
and content providers can assume are present on those devices when shipped from
the factory. Application developers and content providers must design their
code to stay within the bounds of the Java virtual machine features and APIs
specified by that configuration. In this way, interoperability can be
guaranteed among the various applications and devices in a particular class.
Design Considerations for the KVM
Our design goal for the KVM was to have a small memory
footprint without loss of performance. Therefore, we implemented around a
straightforward bytecode interpreter with some optimizations of the Java
virtual machine. The representation of the internal structures is conventional
in the sense that each class has a constant pool, method table, field table,
and interface table. However, most of the structures have been implemented as
linear tables to provide faster access and to conserve memory space. We have
also taken advantage of various low-level features of the C programming
language to achieve better performance.
Portability
Portability was another important goal in the KVM
design. For this reason, non-portable code elements (including functions that
obtain information about the host computing system) have been minimized and
limited to a single file. Multithreading and the garbage collector have been
implemented in a completely platform-independent fashion. Rather than relying
on external interrupts, the multi-tasker performs thread switching on the basis
of the number of bytecodes the current thread has executed, making thread
switching more deterministic and easier to debug. This approach is practical
because we are not targeting multiprocessor platforms.
Garbage Collection
We provided a simple, non-moving, single-space
mark-and-sweep garbage collector. It operates well with heap sizes of just a
few tens of kilobytes. The collector is handle-free, because we always used
direct rather than indirect object references.
Host System Calls
To minimize memory usage, we implemented the native
functions and wrappers used to call host system functions - which would
ordinarily be implemented through the Java Native Interface - by making them a
part of the virtual machine. Currently, the native function support is very
limited.
Graphics are currently implemented by
calling platform-specific graphics functions. There is no support for AWT,
Project Swing, or any other high-level graphics libraries.
Another space-reducing tactic was
implementing the KVM in C. However, we also minimized the number of C runtime
functions that the virtual machine calls in order to ease implementation or
replacement of those functions. If any of the debugging modes in the source
code are enabled, then the target platform must support the fprintf
function in the standard C I/O library (stdio),
or a function with the same interface as fprintf.
Challenges
As we move into the future our goal for the KVM
technology is to evolve the K virtual machine and to provide tools to
accomplish the following goals:
- Optimize class file
format to reduce space requirements and to reduce time to install on the
device.
- To provide other space
and performance optimizations.
- To trim other
"generally useful" packages (like java.net and java.io) so that
they will fit better, and so that profiles can optionally specify them.
- To produce a lightweight
JNI capable of running on the small footprint of KVM technology.
- To produce a KVM capable
of supporting consumer JiniTM connection technology client
code.
- Sun will work with
vendors and content providers to develop optimal APIs for a variety of
application profiles.
To support
application development done on workstations using Java development tools.
Then, after the code is compiled and a Java technology-based classfile is
generated, the classfile would be passed through a converter designed to
support the needs of a particular application profile. The converter would
optimize the bytecode to fit within the small footprint of an embedded device,
and convert bytecode to run in the virtual machine within that embedded device.
Features of the K Virtual Machine and
its APIs
This section describes the K virtual machine (KVM). It
also describes the classes and methods included in the Java 2 ME API. Although
the latter topic is not strictly a component of the KVM technology, it is
essential to understand how the KVM is applied in resource-limited products.
The KVM Specification
The KVM evolved from a research project at Sun
Laboratories. It is a derivative of The Java Virtual Machine Specification,
written from scratch in C, with special emphasis in these key areas:
- Optimized for small size
- Easily portable to
different platforms
- Modular and extensible
- Source code base written
from scratch
- As "complete"
and "fast" as possible without significantly increasing
footprint.
Except for the differences indicated in the following
section, the KVM is identical to the Java virtual machine as specified in The
Java Virtual Machine Specification (Java Series) by Tim Lindholm and Frank
Yellin (second edition, Addison-Wesley, 1999).
The KVM Optional Features
The KVM is designed to support standardized, incremental
deployment of Java virtual machine features and Java APIs called for by the
Java 2 ME architecture. The KVM specification identifies several optional
features which can be omitted from some minimum initial device configurations,
depending on the features and capabilities of the device. The Java 2 ME
architecture includes a small number of configurations that are specified and
standardized by Sun. The KVM specification gives the guidelines that Sun uses
in defining configurations. It spells out exactly which features can be omitted
from an initial configuration.
The following features defined in The
Java Virtual Machine Specification are optional in the KVM architecture. In
each case, a feature is designated "optional" because:
- The applications
designed for a particular configuration (or class of device) do not need
the feature.
- Elimination of the
feature significantly reduces memory footprint or enables some other cost
savings or necessary functionality in the class of device targeted by that
configuration.
While these features are optional at the KVM
architectural level, they may be required at the KVM implementation level. Each
Java 2 ME configuration specifies whether or not each optional feature is
included. Any KVM implementation claiming to support a particular configuration
must implement all the features required by that configuration.
Features not explicitly identified in
the following list are required and must be implemented in all configurations.
- Large data types: long, float, and double -- many configurations
do not need the extended range and precision of the larger data types.
- Multi-dimension arrays -- many configurations do not
need to support arrays of more that one dimension.
- Class file verification -- some specified
configurations may not need to support on-device verification of class
files. Instead technology is planned to be developed to enable class files
to be efficiently verified "off-line" and delivered to the
device.
- Handling of Error classes -- when the Java virtual
machine encounters a serious internal problem, it throws an instance of a
subclass of java.lang.Error. However, because there is often no reasonable
form of programmatic recovery from these errors, a configuration may
specify the KVM to halt with a configuration-defined error indication. Or
the configuration may allow device vendors to define device-specific
behavior and recovery actions when it encounters such conditions.
- Threads and event handling -- some configurations may
require a different application execution model from the standard Java
technology-based model using the Thread class and standard event handling.
- Java Native Interface (JNI) -- many configurations might
not need the flexibility of the JNI for the way in which native methods
are linked and invoked. A configuration may use a defined alternative,
simpler mechanism to invoke native methods.
- Class loaders -- many configurations might
not need the full flexibility of Java class loaders. A configuration must
specify the mechanisms by which classes are located and loaded into the
KVM.
- Finalization -- many configurations do not need to support
object finalization.
- Maximum size limitations -- many configurations do not
need to support the full range of sizes of internal virtual machine data
structures. A configuration may specify a "maximum supported"
range for some or all of the following values:
- The number of classes
in a package
- The number of
interfaces implemented by a class
- The number of fields in
a class
- The number of methods
in a class
- The number of elements
in an array
- The number of bytes of
code per method
- The length of a string
in a CONSTANT_UTF8 constant pool entry
- The maximum amount of
stack that a method may use
- The maximum number of
locals that a method may use
- Start-up -- each configuration must specify how the KVM
locates the initial class and method to execute and the expected
attributes of that class and method.
C
Virtual Machine (CVM)
·
Slightly slimmer than J2SE JVM
·
Has the option of including all JVM
features
AWT/Swing: unnecessary
J2ME Mobile Information Device Profile (MIDP)
The J2ME Mobile Information Device
Profile (MIDP) lets you write downloadable applications and services for
network-connectable, battery-operated mobile handheld devices such as cell
phones, two-way pagers, and Palm Pilots.
Java
Consumer Software Documentation lists the programmer guides, white papers,
books, and specifications available from the Java platform documentation,
engineering, and marketing teams.
MIDP RI 1.0.3: This
version of the MIDP reference implementation is based on the MIDP 1.0
specification and supports the CLDC RI 1.0.3. The MIDP RI is targeted at device
manufacturers who want to port this J2ME profile to another platform.
J2ME Related Technologies
Java Card Technology
A smart card is a credit card sized
plastic card with an integrated circuit (IC) inside. The IC contains a
microprocessor and memory so the smart card can process and store information.
The Java Card platform lets smart card developers standardize on a common card
platform.
- Around 50K memoryThree components: JCVM, JCRE, JC API
- 2 different VM:
- Converter
- Interpreter
J2ME Applications
§
ESRI has currently developed
direct support for Windows CE in ArcPad—a
more robust offline mobile GIS vs. an LBS.
§
ESRI have extended the mobile
client offering through our business partners.
These offerings include one-off
J2ME MIDlets for concierge and navigation services.
§
MIDlets offer
OS/device-independent mapping functionality, and they are able to consume GIS
web services.
§
MIDlets standard mapping
features include zoom, pan, and local cache for offline operations.
The Clash of Mobile Platform (Cell
phone Games)
Introduction to the development of
cell phone games through some specific characteristics of this market are
analyzed and the four primary free game development platforms are described,
mentioning each one's advantages and disadvantages. This article is primarily
targeted at amateur development teams who wish to evolve to professionals in
this market.
At the moment, most programmers enter
in the videogames' world "through" the computer. Taking in
consideration the high licensing fees in the console market, it's extremely
difficult to commercially release games on these systems (at least in a legal
way). However, these last two years (and especially in 2002), another
"gateway" to professional game development has been opened: the cell
phone. The appearance of several free and device-independent development
platforms allows amateur development teams to compete head-to-head with this
sector's professionals without any notorious disadvantages. To achieve this,
one must choose the platform that best fits the intended objectives. To make
that choice easier, this article introduces the four main free platforms available
in the market: J2ME [1], ExEn [2], Mophun [3] and WGE [4]. Initially, the
reader is introduced in the specific characteristics of this market, to help
him notice the development differences regarding other systems. This
introduction is followed by an analysis of the strong and weak points of each
one of the platforms mentioned above. The last paragraph contains a short
summary on each platform, as well as an indication of what type of situation
each one fits better.
The wireless gaming
market
Unlike what happens in other systems,
the amount of people who buy a cell phone just to play is extremely reduced.
Sometimes the choice is purely based on the price, sometimes people buy
whatever the mobile operator sells them and there's also people who choose a
certain model just because his friends also have one… there are plenty of
reasons to choose a device and the available games are usually only seen as a
nice "side effect" of buying a cell phone.
With the appearance of the most recent
cell phones, which have advanced graphic and sound capabilities, this market
started expanding. Apart from the mentioned capabilities, the existence of free
device-independent development platforms played a major role in this expansion.
Looking at the success of handheld consoles (especially Nintendo's Gameboy,
which became the world's best selling console in 1999), it becomes obvious that
there's an excellent market to explore. After all, most people use their cell
phone to be reachable anywhere, anytime. This means that, usually, they always
take the cell phone with them. You can't say the same thing about a handheld
console, since its users only carry it around when they're sure that they'll go
through long waiting periods. The cell phone, on the other hand, is always
there: at the bus stop, at the dentist's waiting room or in a boring class. Its
main function (communicate) is constantly being requested, which means that its
remaining functions (where games are included) are also always available.
Another important aspect lies on the
fact that the typical cell phone user doesn't care about the technology
available in his device. "J2ME", "ExEn" and
"Mophun", for example, are words that most users don't know. Now, if
the selected term is "Snake", it's pretty certain that at least those
who usually play with a cellphone will recognize the word. Even though, at the
moment, the choice of a cellphone isn't influenced by its games, it's extremely
likely that this situation will change in the next 2 to 3 years. However, you
shouldn't expect that common users will start checking if the device they're
planning on buying supports a certain platform. What they will look for is if
that device supports a good amount of quality games at reasonable prices…
without forgetting that a cellphone's main function is communication.
A final thought goes to the game
genres with higher probabilities of achieving success in this market. Unlike
what's usual in other systems, the cellphone users don't play during long time
periods. Games which involve that necessity (like, for example, RPGs and
platforms) must have an extremely high quality level to "conquer" the
user. Puzzles are the most common genre: if they're easy to play, fun, feature
a fast action and do not demand a lot of training time, the success is almost
assured. Another genre which is starting to become famous is the action:
fighting games, shoot'em and beat'em up are now starting to enter the cellphone
gaming market. When developing a game for this system, you shouldn't forget
that there's a high probability of it being played only for 5 or 10 minutes at
a time. If it doesn't "grab" the player in this time period, its
commercial success will be quite limited.
J2ME
The "Java 2 Micro Edition"
is usually considered what Java was originally supposed to be: a cross-platform
language capable of working in devices with highly reduced capabilities. With
that in consideration, it doesn't come as a surprise the similarities between
J2SE and J2ME. As a matter of fact, J2ME is often considered a Standard Edition
stripped to the essential.
Since it wasn't initially planned for
games, its potential is quite reduced when compared with the other platforms
created specifically for that purpose. Although MIDP 2.0 already comes with a
GameAPI, the current version (MIDP 1.0) only has a few rudiments of what would
be required to produce technically advanced games. For example, there's no
support for resizing images, perform simple 2D rotations or even include sound.
However, due to the fact that it appeared first and managed to acquire a good
amount of supporters, J2ME became almost a market standard and it's the
platform that carries more games in more devices.
J2ME's development costs are extremely
reduced. The SDK is freely available and there are no licensing expenses, which
means that anyone can create a game and market it. However, unlike the other
platforms created specifically for games, there is no J2ME business model. The
developer must negotiate its commercialization with three possible
"partners": manufacturers, operators and distributors.
Negotiating a contract with a
manufacturer is usually the most difficult option. Most of the times, it's
cheaper for the manufacturer to create its own internal development team rather
than paying a third party to develop games to be included in all its devices.
Besides, considering that it's already possible to download games for the
cellphone, the number of titles initially available in the device's memory is a
characteristic losing some attention. Most of the times, these games are weaker
than those the player can obtain through a simple download.
Negotiating directly with an operator
is becoming the most common alternative. Most operators already have a service
targeted at game developers and the current indicators show that these services
will expand. The profit margins in revenue sharing are usually the highest
(around 80%). However, sometimes commercializing a game can be quite difficult.
Most of these services require a test period in which the game download is
free. If the game is successful in this period, it moves on to a
commercialization stage. The problem with this option lies in a simple fact:
when the game enters the commercialization stage, the "new game"
effect has wore out and the possible buyers already played it when it was
freely available. Another problem lies in the limitation of negotiating with
just one operator. For example, to release a game in more than one country,
negotiations with at least two operators are required. This problem thickens
when the developer wants a continental-wide or worldwide distribution. Anyway,
sometimes it can be the best option (when, for example, due to localization
difficulties, the developer wishes to target a single country and the operator
does not demand a free download trial period).
The third option, dealing with a
distributor, is usually the most appealing when what the developer wishes is a
large scale distribution. It's quite common for distributors to have agreements
with several operators. The turnoff of this lies on the lower profit margins.
Usually operators take 20% of the profits, while the remaining 80% are divided
among the distributor and the developer. Although it's possible to obtain a
revenue share between 20% and 70% (which is above the 5% to 10% from other
markets), the profit will never be as high as it would be if it was negotiated
directly with the operator. Apart from this disadvantage, the developer also
has to find a distributor interested in his application, which sometimes can be
extremely difficult (although there are cases where it's the distributor that
contacts the development team). The main advantage lies in the lack of
commercially worries for the developer, since both the operator negotiations
and the marketing are a task for the distributor.
Regarding J2ME's future, generally
speaking you could say it's excellent. Not only does it have an extensive list
of manufacturers supporting it (making it almost a standard), but it also
managed to overcome the problems of JVMs that did not follow the specifications
(which occurred due to the manufacturers' "rush" in releasing devices
supporting this technology). On the gaming market, its future is somewhat
dependent of MIDP 2.0. It's certain that it won't fade away and it should keep
the leadership during 2003… but if one or more of the remaining contenders
stays ahead in a technological level and manages to include its engine in an
amount of devices similar to J2ME's, Sun's platform will face some difficulties
in keeping the leadership in this specific market.
ExEn
"Execution Engine" (also
known as ExEn) was developed by In-Fusio to "fight" the limitations
imposed by J2ME in game development. It's also interesting to notice that
In-Fusio tried to overcome those limitations working together with Sun by presenting
the proposal of a GameAPI for MIDP 2.0.
ExEn was the first mass market
downloadable game engine to be made available in Europe. This was an important
first step that allowed ExEn to achieve the current position of leader in this
continent, making it the most used game engine (which also means that it's the
one with a wider range of games).
In early November 2002, there were 18
models which supported ExEn. In an European view, this means around one million
available cellphones. Although it's a somewhat reduced number when compared
with the five million devices which have J2ME technology, it's an impressive
amount for a "small" proprietary technology.
Nevertheless, when compared with the
remaining contenders, it's incorrect to say that such leadership is justified
by the technological capabilities. Both in graphical and processing speed
terms, ExEn is far from the lead. However, by supplying additional important
game development functions (sprite zooming, parallax scrolling, raycasting,
rotations), it easily overcomes J2ME. Adding to this a virtual machine that,
despite not being the fastest, can be around 30 times faster than a generic VM
(although usually is only 10 to 15 times) and only leaves a 5% footprint on the
device's memory, it's easy to see why this is the most widely chosen game
engine.
Another important reason that lead
several developers to choose ExEn is In-Fusio's business model. This is divided
in 2 levels: standard and premium. In the standard level (free subscription),
In-Fusio offers the SDK, an emulator, on-line technical support and the
possibility of, later on, upgrading to the premium package. The developers that
achieve the premium level have their games marketed by In-Fusio, which promotes
them in the operators who have devices supporting this engine.
Execution Engine's growth perspectives
are quite good. With a new version (2.1) released in the beginning of 2003, the
support of several influential software-houses (Handy Games and Iomo, for
example) and an attractive business model for independent producers, the number
of available games should increase considerably. In-Fusio has also started to
enter the Chinese market, which should become one of the strongest (if not the
strongest) in the next 2 to 3 years.
Mophun
Mophun is described by its creators
(Synergenix) as a "software-based videogame console". Although its
development began in late 1999, its market implantation only achieved a serious
level in November of 2002.
Its late appearance, allied to the
fact that only three devices carry this engine (Ericsson T300, T310 and T610)
made some developers discard the option of developing for this system. The
somewhat biased market analysis performed by Mophun's producers also
"scared away" some interested developers… for example, in one of
those analysis, Mophun is shown dividing the leadership of the European market
with J2ME. However, while the J2ME and ExEn information reported back to
October of 2002, the values presented for Mophun were predictions for 2003.
This fact passed on the feeling that something went wrong with Mophun at an
operator and manufacturer support level.
Technically speaking, Mophun has no
rivals. Tests performed by independent organizations showed that, in a device
where Mophun reaches 60 MIPS, J2ME only went as far as 400 KIPS (this
represents a performance 150 times higher). Synergenix also adds that, in
certain devices, part of the VM code is directly translated into native code,
meaning that it's possible to achieve 90% of the device's maximum capability (for
instance, reaching 90 MIPS in a device that reaches 100 MIPS when running
native programs). The remaining characteristics are similar to ExEn's.
Like ExEn and J2ME, Mophun is also
freely available. In some aspects, Synergenix's business model resembles
In-Fusio's: after the game is developed, Synergenix handles certification,
distribution and marketing. However, since its current network isn't very
extended, it doesn't seem to be as appealing as ExEn's, which made some
developers choose the theoretically weaker system.
Mophun's future is
"semi-unknown". If Synergenix fails to quickly acquire additional
support, it's quite likely for Mophun to be dropped in favour of less powerful
but financially more appealing development technologies. However, if the promises
that several operators and manufacturers are going to adopt Mophun briefly are
followed, this system's advanced technical skills can make it the new leader.
WGE
The "Wireless Graphics
Engine" is TTPCom's solution. Although it began being considered the main
candidate for domination of the game engines' market, the lack of support by
game developers ended up decreasing the initial appeal.
It's impossible denying that, from a
purely technical point of view, WGE has everything to win. It may be slower
than Mophun, but the several API modules make 2D and 3D programming easier
(including tile management and collision detection functionalities), allow a
simple access to networking functions and grant sound support, among other
capabilities.
As its direct contenders, the SDK
download is free and TTPCom has a business model aimed at attracting the game
development teams. To the usual revenue sharing from the games sold on a
download basis, there's the addition of a "minimum income" resulting
from selling the games directly to the device's manufacturers.
Unfortunately, despite the initially
generated "fever", the lack of support from the primary manufacturers
ended up limiting WGE's success. Most software houses avoided it, which lead
small companies and independent developers to follow that example. The result
is easy to see: the number of games available for WGE is slightly over 30. This
lack of interest shown by the majority ends up bringing an advantage for those
who want to start developing for WGE: with such small internal competition,
it's easier for a quality game to succeed. The disadvantage lies on the lower
number of possible players, which may considerably limit the profits obtained
from the game's commercialization.
Although it's wrong to say that WGE's
immediate future is dark, its perspectives have been more pleasant. Considering
the strong competition that the current market fragmentation will bring in the
next two years, if TTPCom isn't able to bring more software houses to its
catalogue, it'll hardly get the support of additional manufacturers. On the
other side, without the support of additional manufacturers, it's extremely
hard to attract more software houses. WGE's future depends on TTPCom's ability
to break this cycle. If it makes it within the next 3 or 4 months, the growth
perspectives are quite positive. Otherwise, the end is almost unavoidable.
Which should you choose?
At this point, a question arises:
which platform shall a programmer choose? Due to the high fragmentation of this
market, there isn't one answer that suits all situations. To choose the
platform that best fits the situation, it's necessary to set the objectives of
what the team wants to produce and analyze the advantages and disadvantages of
the several available platforms.
When the objective involves reaching a
wide market and it's possible to make some compromises on a performance level,
J2ME is the best option. If commercializing the game is also an objective, the
team must expect to lose some extra time negotiating the distribution deals.
If the project requires more
potentialities than those offered by J2ME and there's the option of choosing a
smaller market or if the team wishes to choose a platform that offers a simple
business model, ExEn should be selected.
When the most critical aspect lies on
the performances (both in speed and graphical terms), Mophun appears as one of
the main choices. In this case, it's important to check if taking the risk of
choosing a not yet widely spread platform is a possibility.
If the option for a platform with a
reduced market isn't a problem, if the objective is the creation of a
high-performance game and if Mophun isn't a satisfactory choice for any reason,
WGE is the best option. Once again, it's advisable to study well the choice in order
to prevent excessive expenses when compared to the expected profits.
J2ME ADVANTAGE: i.JV
Motorola's implementation of the Java™
2 Platform, Micro Edition (J2ME) is revolutionizing the wireless landscape.
This industry leading embedded Java solution delivers all the advantages of
J2ME in an easy to adapt, robust implementation specifically designed for the
wireless device market. i.JV for J2ME is fully compliant to the Connected
Limited Device Configuration/ Mobile Information Device Profile (CLDC/MIDP)
specification, and reflects the experience only a leader in the wireless
industry can provide. i.JV for Innovative Convergence platforms offers wireless
device manufacturers the following advantages:
- Rapid
time-to-market
i.JV is available today for the i.250
platform, and it can be quickly configured and customized to meet the
requirements of various market segments. Time to market is key in the wireless
landscape. Motorola has Certified and shipped several CLDC/MIDP phones with
more on the way. No one can implement a CLDC/MIDP compliant solution for your
platforms as quickly as the Motorola team.
- Optimizations
for Innovative Convergence platforms
i.JV provides optimizations such as the Optimized Byte code Interpreter (OBCI) and other performance enhancements for these platforms. Our Optimized Byte Code Interpreter (OBCI), mini-JIT, ahead of time snippet tool and other performance enhancing features, plus our real-world experience with multiple devices, OS and silicon, mean we can squeeze J2ME into tight spaces without sacrificing performance. - Java
standards leadership
i.JV leverages Motorola's
experience as the specification leader for the MIDP, versions 1.0 and 2.0. i.JV
will be upgraded to the latest J2ME standards and technologies as they emerge.
Motorola has led three Java Specification Requests (JSRs) involving J2ME:
- JSR
37: Mobile Information Device Profile (MIDP) 1.0 for the J2ME Platform
- JSR
82: Java APIs for Bluetooth
- JSR
118: Mobile Information Device Profile Next Generation (MIDP NG)
In addition, Motorola has
been instrumental in developing other J2ME technologies through JSR 30 (CLDC),
JSR 124 (J2EE Client Provisioning), JSR 135 (Multimedia) and JSR 139 (CLDC NG).
- J2ME
roadmap and APIs Motorola is aggressively pursuing new
features and functionality for i.JV. Some of our most recent features
include: improved graphics support, games optimizations, enhanced security
features, pull and push provisioning as well as many other new features.
Motorola also works with clients to develop custom APIs for their specific
needs. And we are constantly working on techniques to improve performance
and reduce the size of our implementation.
- Mobile
Media API(JSP-135) The Multimedia API (MMA) optional
package on i.JV provides a high-level interface to sound and multimedia
capabilities of a device running J2ME, enabling versatile multimedia
functionality in J2ME applications. MMA provides access to and control of
basic audio and multimedia resources, while supporting scalability and
sophisticated features.
- Wireless
Messaging API (JSR-120)
The Wireless Messaging API (WMA) optional package on i.JV provides standard access to wireless communication resources, to support intelligent, connected Java applications. WMA is designed to run on J2ME configurations and to enhance J2ME profiles with unique functionality. - Bluetooth
As the leading company on JSR 82, "Java APIs for Bluetooth", Motorola will be providing both a reference implementation and technology compatibility kit (TCK). This API will also be available bundled with i.JV for the most complete J2ME and Bluetooth solution available. - Proven
J2ME technology
Motorola's J2ME technology has been deployed in a number of handsets that are commercially available today. This proven J2ME technology is a component of the Innovative Convergence platforms. Motorola has been involved with J2ME from the very beginning. We worked very closely with Sun Microsystems to create J2ME technology from the ground up. Our Sun Certified J2ME implementation for the iDEN line of phones was the world's first shipping CLCD/MIDP compliant line of devices. Motorola brings many years of embedded programming and wireless experience to the table. Our unique combination of wireless and embedded systems experience give your projects unmatched support in adapting J2ME to handheld devices.
J2ME provides a powerful foundation for success for service
providers, content providers and device vendors and assist users to enjoy
improved services
Easy production and buy-in of contents due to abundant Java developers
Easy linking between wired and wireless services
Easy expansion to Post-PC and information appliances
Favorable in e-commerce due to excellent security functions
Differentiated multimedia services
J2ME-supported
various next generation wired/wireless services are broadening the horizon of
digital service which is convenient and beneficial.
Java-based wireless Internet services
Games, animations, videos, music files and mobile Karaoke
Multimedia service including training and lecturing
Location-based service and remote control
Electronic commerce
Games, animations, videos, music files and mobile Karaoke
Multimedia service including training and lecturing
Location-based service and remote control
Electronic commerce
Conclusion
Wireless communication posses
different challenges that are not present in browser-based and wire-line
client-server applications. There are problems with network reliability, low
bandwidth and cost of service that must be addressed. In order to deal with
these problems, several models for communication were discussed. Different
applications have different needs and therefore it is important to understand
what a communication model buys and what needs to be managed. Each of the
models discussed focus on moving data between a device and a server while
minimizing dependencies on the network and allowing the wireless application to
function while disconnected. The server plays an important role in optimizing
performance and how wireless applications use network resources.
