The Java Bluetooth API
The Java Bluetooth API is designed to run in J2ME environments: cell phones, PDAs, and the like. In particular, it requires the Connected Limited Device Configuration (CLDC) with at least 512K of memory available to Java. It also requires vendor support. Currently, almost all the devices that support the Java Bluetooth API are mobile phones. At the time of this writing, they include the Motorola A1000; several Nokia phones, including the 6260; the Sony Ericsson P900, P908, and P910; and the Siemens S65, S66, and SK65.
The Java Bluetooth API supports four (out of a couple of dozen) Bluetooth profiles:
Generic Access Profile (GAP)
Supplies the bare minimum of functionality all other services require
Service Discovery Application Profile (SDAP)
Enables clients to find out which services the device supports
Serial Port Profile (SPP)
Uses the RFCOMM protocol to emulate an RS-232 serial port
Generic Object Exchange Profile (GOEP)
Uses OBEX to transfer data such as contact databases, pictures, and phone logs between devices
These primarily enable networking use cases such as uploading pictures from camera phones and downloading games to phones. The Java Bluetooth API doesn support any of the other profiles, such as the Advanced Audio Distribution Profile or the Basic Printing Profile. However, many of these services may be available through other APIs and the host operating system.
|
.2.1. UUIDs
Bluetooth uses Universal Unique Identifiers (UUIDs) to identify protocols and service classes. A UUID is a 128-bit number that is almost certainly unique among other 128-bit numbers, barring deliberate attempts to create clashes. For example, the UUID for the RFCOMM protocol is 0x0000000300001000800000805F9B34FB.
Because space is at a premium in many Bluetooth devices, many services are identified with only 16 or 32 bits rather than the full 128 a UUID requires. For example, the 16-bit UUID for the RFCOMM protocol is 0x0003. The Bluetooth specification converts these shortened UUIDs into full 128-bit UUIDs by starting with the 16-byte base address 0000-0000-0000-1000-8000-0080-5F9B-34FB (in hexadecimal) and then replacing the third and fourth bytes with the two bytes of the 16-bit UUID.
The javax.bluetooth.UUID class recognizes all three widths of UUID (16-bit, 32-bit, and 128-bit) and can convert between them as necessary. Most methods in the Bluetooth API that take a UUID as an argument expect to see it in the form of a UUID object rather than a string or a number.
|
To create a Bluetooth-savvy UUID, just use one of these two constructors:
public UUID(long uuidValue) public UUID(String uuidValue, boolean shortUUID)
The first constructor is used for the 16- and 32-bit short forms of UUIDs. A long is ironically not long enough (at 64 bits) for a full 128-bit UUID, so just pass a String argument containing its hexadecimal form to the second constructor instead and pass false for the second argument. Pass TRue for the second argument if the first argument uses the short form.
Other than these constructors, this UUID class merely defines the usual equals( ), hashCode( ), and toString( ) methods, which are used to properly compare the short and long UUIDs.
.2.2. The Bluetooth Control Center
One of the least well-defined parts of the Java Bluetooth API is the Bluetooth Control Center (BCC). The BCC is a class, program (possibly native), default set of properties, or something that enables the user, vendor, or developer to:
- Specify security preferences.
- List previously known remote Bluetooth devices.
- List trusted remote Bluetooth devices.
- Pair two devices.
- Authorize connection requests.
Some BCCs offer additional functionality, such as changing the Bluetooth device name, setting timeouts, resetting devices, initializing the stack, and listing the services on the local device.
The Java Bluetooth API specification deliberately doesn say much about what the BCC really is. It varies from one implementation to the next. It can even be a fixed set of unchangeable defaults compiled into the implementation-specific code.
.2.3. Initialization
There are many different implementations of the Java Bluetooth API from many different vendors. Atinav has one. Rococo has one. Blue Cove has an open source implementation, and there are others. Some run on PDAs and cell phones. Some run on standard desktop hardware. They are available for a variety of operating systems, including Linux, Windows, Mac OS X, Palm OS, PocketPC, and Symbian OS. While working on this chapter, I mostly used Avetana GMBHs implementation from http://www.avetana-gmbh.de/avetana-gmbh/produkte/jsr82.eng.xml. An open source version of this stack for Linux can be found at http://sourceforge.net/projects/avetanabt/.
Some of these implementations require initialization before any of the classes and methods discussed in this chapter will work. This initialization is normally done once in any given program. For example, if you e using Atinavs aveLink BT SDK for Java, you have to place the following static initializer block in the class that starts the application:
static {
BCC.setPortNumber("COM1");
BCC.setBaudRate(57600);
BCC.setConnectable(true);
BCC.setDiscoverable(DiscoveryAgent.GIAC);
}
In this implementation, BCC is the class that represents the Bluetooth Control Center. However, this part varies from one implementation to the next. Youll need to consult the documentation for your implementation. (One of the nice features of the Avetana implementation is that its self-initializing. No explicit initialization is required.) This means most code you write will have at least some platform-dependent details.
