On The Insider: Colin Farrell Buys Pregnancy Test

Developing Bluetooth wireless applications in J2ME

Tags: Wi-Fi, Programming languages, RemoteDevice, J2ME, LocalDevice, Peter V. Mikhalenko, Bluetooth, Java, JSR 82, JSR 82 specification, Java Bluetooth API, specification, Java Tips Newsletter

  • Save
  • Print
  • Digg This
  • 0

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

Get developer tips in your inbox
Delivered each Thursday, our free Java newsletter provides insight and hands-on tips you need to unlock the full potential of this programming language.
Automatically sign up today!

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.

  • Save
  • Print
  • Digg This
  • 0

Print/View all Posts Comments on this article

Listingsptomov@...  | 03/29/07
re: l;istingsDanLM  | 03/29/07
508031205080110F1B1B1D1C100avram79@...  | 02/12/08

What do you think?

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

The Green Enterprise

advertisement
Click Here