Device Discovery
Wireless devices need a mechanism that allows them to find other devices and gain access to their capabilities. The core Bluetooth API's DiscoveryAgent class and DiscoveryListener interface provide the necessary discovery services. There are three ways to obtain a list of accessible devices. The DiscoveryAgent.startInquiry() method places the device into an inquiry mode. To take advantage of this mode, the application must specify an event listener that will respond to inquiry-related events. DiscoveryListener.deviceDiscovered() is called each time an inquiry finds a device. When the inquiry is completed or canceled, DiscoveryListener.inquiryCompleted() is invoked. If the device doesn't wish to wait for devices to be discovered, it can use the DiscoveryAgent.retrieveDevices() method to retrieve an existing list. Depending on the parameter passed, this method will return either a list of devices found in a previous inquiry or a list of preknown devices that the local device has told the Bluetooth Control Center it will contact frequently. The most simple approach is shown in Listing 3 where DiscoveryAgent is asked for an object to notify us via the DiscoveryListener interface whenever it detects a new Bluetooth device.

Service Discovery
Service discovery allows you to find nearby services, regardless of what devices are offering them. Because service discovery is much like device discovery, DiscoveryAgent also provides methods to discover services on a Bluetooth server device and to initiate service-discovery transactions. Before a service can be discovered, it must first be registered - advertised on a Bluetooth server device. The server is responsible for creating a service record that describes the service offered, accepting connections from clients, adding a service record to the server's Service Discovery Database (SDDB), etc. In general it works similar to Web services. Listing 4 provides an example of a service registration.

Communication
The two devices must share a common communications protocol. Applications can access a wide variety of Bluetooth services because the Java APIs for Bluetooth provide mechanisms that allow connections to any service that uses RFCOMM, L2CAP, or OBEX as its protocol. If a service uses another protocol (such as TCP/IP) layered above one of these protocols, the application can access the service, but only if it implements the additional protocol in the application using the CLDC Generic Connection Framework. The URL used as a service record consists of digits and symbols and may look something like btspp://508031205080110F1B1B1D1C100:8. This means that a client should use a Bluetooth Serial Port Profile (btspp://) to establish a connection to server channel 8 on a device with the address 508031205080110F1B1B1D1C100. Device addresses are similar to the physical (MAC) addresses of computers. Simple RFCOMM connections look like Listing 5.

Resources

• Figure 1
• Source Code