Developing Bluetooth wireless applications in J2ME
Takeaway: Peter Mikhalenko reviews the principles of Java development for Bluetooth on mobile devices and describes how to write a Java application for Bluetooth communications.
A growing number of cellular phones support Java applications, but did you know that many devices can also run Java 2 Micro Edition (J2ME)-compliant applications?
The Java APIs for Bluetooth wireless technology (JABWT) standard, defined by the JSR 82 specification, supports rapid development of Bluetooth applications that are portable, secure, and highly usable. Wireless device manufacturers have responded to the JABWT specification by announcing that mobile phones and other products will run JABWT applications.
This article reviews the principles of Java development for Bluetooth on mobile devices and describes how to write a Java application for Bluetooth communications.
Java Bluetooth API
The Java Bluetooth API relies on the Java Generic Connection Framework, which limited it to J2ME for a long period of time; however, there is a proposal for it to include GCF into J2SE. The Java Bluetooth API can be made accessible for a broader range of systems.
The Java APIs for Bluetooth define two packages: javax.bluetooth for the core Java Bluetooth API and javax.obex for the Object Exchange (OBEX) protocol. According to the JSR 82 specification, the underlying Bluetooth system must support a Bluetooth Control Center (BCC), which is a control panel much like the application that allows a user or OEM to define specific values for certain configuration parameters in a stack. In particular, it will be used in a stack initialization. Any Bluetooth application has these components: stack initialization, device management, device discovery, service discovery, and communication.
Stack initialization
Prior to starting wireless communication, you need to initialize the
Bluetooth device in a vendor dependent way. (The exact steps for stack
initialization are beyond the scope of the Bluetooth API specification.)
In a java.net article about Getting started with Java and Bluetooth, Bruce Hopkins (author of Bluetooth for Java) shows how in Atinav Java Bluetooth SDK it is done by several settings (see Listing A). It is important that these calls are not part of the JSR 82 specification. Other JSR 82 implementations may incorporate other ways to initialize the stack.
Device management
The JSR 82 specification introduces
two classes that you can use for device management: LocalDevice
and RemoteDevice.
- LocalDevice allows you to request static information about the Bluetooth device. It depends on the javax.bluetooth.DeviceClass class to retrieve the device's type and the kinds of services it offers.
- RemoteDevice allows you to retrieve information about devices in the Bluetooth neighborhood (e.g., a remote device Bluetooth Address). It represents a remote device (i.e., a device within a range of reach) and provides methods to retrieve information about the device, including its Bluetooth address and name.
Every Bluetooth device has a unique hardware address, like a MAC address for computers. You can set the level of device discovery, enabling other Bluetooth devices to find the current device by calling the setDiscoverable() method in the LocalDevice object (see Listing B).
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 other 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 that were found in a previous inquiry, or a list of pre-known devices that the local device has told the Bluetooth Control Center it will contact often. Listing C shows the simplest approach, where DiscoveryAgent is asked for an object to notify you 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. DiscoveryAgent 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 or advertised on a Bluetooth server device. The server is
responsible for a number of things, including creating a service record that
describes the service offered, accepting connections from clients, and adding a
service record to the server's Service Discovery Database (SDDB). In general,
it works like Web services.
Listing D
is an example of service registration.
Communcation
The two
devices must share a common communications protocol. In order for applications to access a wide
variety of Bluetooth services, 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 address 508031205080110F1B1B1D1C100. Device addresses are similar to physical addresses of computers. Listing E shows what simple RFCOMM connections looks like.
Peter V. Mikhalenko is a Sun certified professional who works for Deutsche Bank as a business consultant.
Print/View all Posts Comments on this article
SponsoredWhite Papers, Webcasts, and Downloads
- Watts and Volt-Amps: Powerful Confusion American Power Conversion (APC)
- Seeing the Big Picture: A Corporate Guide to Better Decisions through IT SAP
- The Economist: A new mandate for IT SAP
Article Categories
- Security
- Security Solutions, IT Locksmith
- Networking and Communications
- E-mail Administration NetNote, Cisco Routers and Switches
- CIO and IT Management
- Project Management, CIO Issues, Strategies that Scale
- Desktops, Laptops & OS
- Windows 2000 Professional, Microsoft Word, Microsoft Excel, Microsoft Access, Windows XP,
- Data Management
- Oracle, SQL Server
- Servers
- Windows NT, Linux NetNote, Windows Server 2003
- Career Development
- Geek Trivia
- Software/Web Development
- Web Development Zone, Visual Basic, .NET


Harnessing the power of waves
Planting solar gardens
Fill your car for $1.10 a gallon?
