Mobile 3D Graphics API for J2ME:
Overview of the Mobile 3D Graphics API for J2ME
JSR is the first Java-specific standard for three-dimensional graphics on mobile
devices. The JSR's 26-member expert group includes all the major players in the
mobile arena, including Sun Microsystems, Sony Ericsson, Symbian, Motorola, ARM,
Cingular Wireless, and specification lead Nokia. The API takes the form of an
optional package expected to be used with MIDP and version 1.1 of the Connected
Limited Device Configuration (CLDC). It defines low- and high-level programming
interfaces that bring efficient, interactive 3D graphics to devices with little
memory and processing power, and with no hardware support for 3D graphics or
floating-point operations. As new phones with diverse functionality appear,
however, the API can scale up to higher-end devices that have color displays, 3D
graphics hardware, and support for floating-point operations.
Application areas that will benefit from a 3D graphics API include games, map
visualization, user interfaces, animated messages, and screen savers. Each of
these areas requires simple content creation, some require high polygon
throughput, and others require high-quality still images with special effects.
To meet this wide spectrum of needs, the API supports both high-level and
low-level graphics features, with a footprint of only 150 KB. In the high-level
implementation (called retained mode), the developer works with scene graphs,
and the world renders itself based on the positions of virtual cameras and
lights. The low-level access ( immediate mode) allows applications to draw
objects directly. You can use either mode, or both at the same time, depending
on the task at hand.
The features of immediate mode are aligned with OpenGL ES standardization by
Khronos. OpenGL ES (from "OpenGL for Embedded Systems") is a low-level,
lightweight API for advanced embedded graphics using well-defined subset
profiles of OpenGL. It provides a low-level interface between applications and
hardware or software graphics engines. This standard makes it easy and
inexpensive to offer a variety of advanced 3D graphics and games across all
major mobile and embedded platforms. Because OpenGL ES is based on OpenGL, no
new technologies are needed, which ensures synergy with, and a migration path
to, the most widely adopted cross-platform graphics API, full OpenGL.
Requirements:
The JSR 184 expert group has agreed on a set of capabilities that the API must
support:
The API must support both retained-mode access (scene graphs) and immediate-mode
access (the OpenGL ES subset or similar), and allow mixing and matching of the
two modes in a unified way.
The API must have no optional parts; all methods must be implemented.
To reduce the amount of programming required, the API must include importers for
certain key data types, including meshes, textures, and scene graphs.
Data must be encoded in a binary format for compact storage and transmission.
It must be possible to implement the API efficiently on top of OpenGL ES,
without floating-point hardware.
The API must use the float data type of the Java programming language, not
introduce a custom type.
Because using integer arithmetic is difficult and error-prone, floating-point
values should be used wherever feasible.
The ROM and RAM footprint must be small; the API should be implementable within
150KB on a real mobile terminal.
The API must provide minimal garbage collection.
The API must interoperate properly with other Java APIs, especially MIDP.
JSR 184 requires version 1.1 of CLDC for its floating-point capability. Because
most mobile devices do not actually have floating-point hardware, the API
designers struck a balance between the speed obtained through integer operations
and the ease of programming provided by floating-point operations. Calculations
that require the fastest processing accept 8- or 16-bit integer parameters, and
other calculations are performed with floating-point math for easier application
programming. Figure 1 shows how the relevant APIs relate:
Contrasting JSR 184 With Other APIs
Newcomers to the Mobile 3D Graphics API for J2ME might find it all too easy to
confuse it with two other interfaces. Note these distinctions:
The Mobile Media API (JSR 135) is a high-level control API for different media
types; it doesn't address interactive 3D graphics. JSR 184 was defined to
provide core 3D graphics functionality.
Java Bindings for OpenGL ES (JSR 239), which aims to provide Java bindings to
the OpenGL ES native 3D graphics library, is still in its early stages. JSR 239
aims to provide the same functionality as JSR 184, but it caters to those
developers who are already familiar with OpenGL.
What Location-Based Services Do
Location-based services answer three questions: Where am I? What's around me?
How do I get there? They determine the location of the user by using one of
several technologies for determining position, then use the location and other
information to provide personalized applications and services. As an example,
consider a wireless 911 emergency service that determines the caller's location
automatically. Such a service would be extremely useful, especially to users who
are far from home and don't know local landmarks. Traffic advisories, navigation
help including maps and directions, and roadside assistance are natural
location-based services. Other services can combine present location with
information about personal preferences to help users find food, lodging, and
entertainment to fit their tastes and pocketbooks.
There are two basic approaches to implementing location-based services:
Process location data in a server and deliver results to the device.
Obtain location data for a device-based application that uses it directly.
This article focuses on device-based location services.
Determining the Device's Location
To discover the location of the device, LBS must use real-time positioning
methods. Accuracy depends on the method used.
Locations can be expressed in spatial terms or as text descriptions. A spatial
location can be expressed in the widely used latitude-longitude-altitude
coordinate system. Latitude is expressed as 0-90 degrees north or south of the
equator, and longitude as 0-180 degrees east or west of the prime meridian,
which passes through Greenwich, England. Altitude is expressed in meters above
sea level. A text description is usually expressed as a street address,
including city, postal code, and so on.
Applications can call on any of several types of positioning methods.
Using the mobile phone network: The current cell ID can be used to identify the
Base Transceiver Station (BTS) that the device is communicating with and the
location of that BTS. Clearly, the accuracy of this method depends on the size
of the cell, and can be quite inaccurate. A GSM cell may be anywhere from 2 to
20 kilometers in diameter. Other techniques used along with cell ID can achieve
accuracy within 150 meters.
Using satellites: The Global Positioning System (GPS), controlled by the US
Department of Defense, uses a constellation of 24 satellites orbiting the earth.
GPS determines the device's position by calculating differences in the times
signals from different satellites take to reach the receiver. GPS signals are
encoded, so the mobile device must be equipped with a GPS receiver. GPS is
potentially the most accurate method (between 4 and 40 meters if the GPS
receiver has a clear view of the sky), but it has some drawbacks: The extra
hardware can be costly, consumes battery while in use, and requires some warm-up
after a cold start to get an initial fix on visible satellites. It also suffers
from "canyon effects" in cities, where satellite visibility is intermittent.
Using short-range positioning beacons: In relatively small areas, such as a
single building, a local area network can provide locations along with other
services. For example, appropriately equipped devices can use Bluetooth for
short-range positioning.
In addition, location methods can connect to a mobile position center that
provides an interface to query for the position of the mobile subscriber. The
API to the mobile position center is XML-based. While applications can be fully
self-contained on the device, it's clear that a wider array of services is
possible when a server-side application is part of the overall service.
Some applications don't need high accuracy, but others will be useless if the
location isn't accurate enough. It's okay for the location of a tourist walking
around town to be off by 30 meters, but other applications and services may
demand higher accuracy.
The Location API for J2ME:
The Location API for J2ME specification defines an optional package,
javax.microedition.location, that enables developers to write wireless
location-based applications and services for resource-limited devices like
mobile phones, and can be implemented with any common location method. The
compact and generic J2ME location APIs provide mobile applications with
information about the device's present physical location and orientation
(compass direction), and support the creation and use of databases of known
landmarks, stored in the device.
JSR 179 requires the Connected Device Configuration (CDC) or version 1.1 of the
Connected Limited Device Configuration (CLDC). CLDC 1.0 isn't adequate because
it doesn't support floating-point numbers, which the API uses to represent
coordinates and other measurements. The Location API doesn't depend on any
particular profile -- it can be used with MIDP or the Personal Profile.
The hardware platform determines which location methods are supported. If it
doesn't support at least one location provider, LBS won't be possible.
Applications can request providers with particular characteristics, such as a
minimum degree of accuracy. Some location methods may be free; others may entail
service fees. The application should warn the user before any charges are
incurred.
It is up to the application to determine the criteria for selecting the location
method. Criteria fields include: accuracy, response time, need for altitude, and
speed. Once the application obtains a LocationProvider instance that meets the
criteria, it can use that object to obtain the location, in either of two ways:
Invoke a method synchronously to get a single location.
Register a listener and get periodic updates at application-defined intervals.
The Location class abstracts the location results. Its object contains
coordinates, speed if available, textual address if available, and a time stamp
that indicates when the location measurements were made.
Coordinates are represented by either of two classes:
A Coordinates object represents a point's latitude and longitude in degrees, and
altitude in meters.
A QualifiedCoordinates object contains latitude, longitude, and altitude, and
also an indication of their accuracy, represented as the radius of an area.