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.
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.