Part II: The Java APIs for Bluetooth Wireless Technology

The Java 2 Platform, Micro Edition (J2ME) and Bluetooth technology are two of the most exciting offerings in the wireless industry today. J2ME, most compact of the three Java platforms, is inherently portable because it shares the Java "write once run anywhere" philosophy and thus enhances developer productivity. Bluetooth is a short-range universal wireless connectivity standard for electronic appliances and mobile devices.
Imagine being able to use your Bluetooth-enabled mobile phone to lock and unlock your car, operate your garage door, and control your TV, VCR, DVD player, and other consumer appliances. If you want to make that kind of control available to your users, you'll need to be able to write Bluetooth applications that customize these appliances, and deploy them in a way that lets users download them, to a cell phone for example. Bluetooth and J2ME can work together to achieve this unified vision. Bluetooth allows devices to communicate wirelessly and J2ME allows you to write custom applications and deploy them on mobile devices.
Part I of this series, "Getting Started with Bluetooth," was a tutorial that covered the basics of Bluetooth, the Bluetooth protocol stack, and procedures for establishing Bluetooth connections. This article focuses on programming wireless applications using Bluetooth and J2ME. It provides a brief overview of the Java APIs for Bluetooth Wireless Technology (JSR 82), and shows you how to use these APIs.

Java APIs for Bluetooth Wireless Technology

While Bluetooth hardware has advanced, there has been no standardized way to develop Bluetooth applications - until JSR 82 came into play. It is the first open, non-proprietary standard for developing Bluetooth applications using the Java programming language. It hides the complexity of the Bluetooth protocol stack behind a set of Java APIs that allow you to focus on application development rather than the low-level details of Bluetooth. JSR 82 is based on version 1.1 of the Bluetooth Specification.
Like all JSRs, the Java APIs for Bluetooth are being developed through the Java Community Process. Its expert group has members representing 20 companies. The final specification is available for download.
JSR 82 consists of two optional packages: the core Bluetooth API and the Object Exchange (OBEX) API. The latter is transport-independent and can be used without the former.

		Note: The Java APIs for Bluetooth do not implement the Bluetooth specification, but rather provide a set of APIs to access and control a Bluetooth-enabled device. JSR 82 concerns itself primarily with providing Bluetooth capabilities to J2ME-enabled devices.

The Java APIs for Bluetooth target devices with the following characteristics:

• 512K minimum of total memory available (ROM and RAM) (application memory requirements are additional)
• Bluetooth wireless network connection
• Compliant implementation of the J2ME Connected Limited Device Configuration (CLDC)

Bluetooth System Requirements

The underlying Bluetooth system upon which the Java APIs will be built must also meet certain requirements:

• The underlying system must be "qualified," in accordance with the Bluetooth Qualification Program, for at least the Generic Access Profile, Service Discovery Application Profile, and Serial Port Profile.
• The system must support three communication layers or protocols as defined in the 1.1 Bluetooth Specification, and the implementation of this API must have access to them: Service Discovery Protocol (SDP), Radio Frequency Communications Protocol (RFCOMM), and Logical Link Control and Adaptation Protocol (L2CAP).
• The system must provide a Bluetooth Control Center (BCC), a control panel much like the application that allows a user or OEM to define specific values for certain configuration parameters in a stack.

OBEX support can be provided in the underlying Bluetooth system or by the implementation of the API. The OBEX protocol provides support for object exchanges, and forms the basis for Bluetooth profiles such as the Synchronization Profile and the File Transfer Profile.

What Is the BCC?

Bluetooth devices that implement this API may allow multiple applications to execute concurrently. The BCC prevents any application from harming another. The BCC is a set of capabilities that allow a user or OEM to resolve conflicting application requests by defining specific values for certain configuration parameters in a Bluetooth stack. It is the central authority for local Bluetooth device settings. The BCC might be a native application, an application with a separate API, or simply a group of settings that are specified by the manufacturer and cannot be changed by the user. Note that the BCC is not a class or an interface defined in this specification but an important part of its security architecture.

Capabilities of JSR 82

The API is intended to provide the following capabilities:

• Register services
• Discover devices and services
• Establish RFCOMM, L2CAP, and OBEX connections between devices
• Using those connections, send and receive data (voice communication not supported)
• Manage and control the communication connections
• Provide security for these activities

The API Architecture

The goal of the specification was to define an open, non-proprietary standard API that can be used by all J2ME-enabled devices. Therefore, it was designed using standard J2ME APIs and CLDC/MIDP's Generic Connection Framework. Some important features:

• The specification provides basic support for Bluetooth protocols and profiles. It doesn't include specific APIs for all Bluetooth profiles simply because the number of profiles is growing.
• The specification incorporates the OBEX, L2CAP, and RFCOMM communication protocols in the JSR 82 APIs, primarily because all current Bluetooth profiles are designed to use these communication protocols.
• The JSR 82 specification addresses the Generic Access Profile, Service Discovery Application Profile, Serial Port Profile, and Generic Object Exchange Profile.
• The Service Discovery protocol is also supported. JSR 82 defines service registration in detail in order to standardize the registration process for the application programmer.

JSR 82 requires that the Bluetooth stack underlying a JSR 82 implementation be qualified for the Generic Access Profile, the Service Discovery Application Profile, and the Serial Port Profile. The stack must also provide access to its Service Discovery Protocol, and to the RFCOMM and L2CAP layers.

The APIs are designed in such a way that developers can use the Java programming language to build new Bluetooth profiles on top of this API as long as the core layer specification does not change. To promote this flexibility and extensibility, the specification is not restricted to APIs that implement Bluetooth profiles. JSR 82 includes APIs for OBEX and L2CAP so that future Bluetooth profiles can be implemented in Java, and these are already being used for that purpose. Figure 1 shows where the APIs defined in this specification fit in a CLDC/MIDP architecture.

JSR 82 is Flexible

The JSR 82 APIs can work with both native Bluetooth stacks and Java Bluetooth stacks. In the latter case the APIs call the stack directly; in the former case the APIs go through the virtual machine, which will interface with the native stack. As I already noted, Java developers can expand their options by creating new profiles.
JSR 82 standardizes the programming interface. Its two optional packages can be used with any of the J2ME profiles. The minimum configuration is CLDC. Because CLDC is a subset of CDC, applications using these APIs should work on CDC devices. If the Generic Connection Framework Optional Package for J2SE (JSR 197) is implemented, the JSR 82 APIs should work smoothly with J2SE.

Packages

The Java APIs for Bluetooth define two packages that depend on the CLDC javax.microedition.io package:

• javax.bluetooth: core Bluetooth API
• javax.obex: APIs for the Object Exchange (OBEX) protocol

Again, the OBEX APIs are defined independently of the Bluetooth transport layer and packaged separately. Each of the above packages represents a separate optional package, which means that a CLDC implementation can include either package or both. MIDP-enabled devices are expected to be the kind of devices to incorporate this specification.

Application Programming

The anatomy of a Blueooth application has five parts: stack initialization, device management, device discovery, service discovery, and communication.

Stack Initialization

The Bluetooth stack is responsible for controlling the Bluetooth device, so you need to initialize the Bluetooth stack before you can do anything else. The initialization process comprises a number of steps whose purpose is to get the device ready for wireless communication. Unfortunately, the Bluetooth specification leaves implementation of the BCC to vendors, and different vendors handle stack initialization differently. On one device, it may be an application with a GUI interface, and on another it may be a series of settings that cannot be changed by the user. As an example, Atinav's Java Bluetooth solution requires the developer to initialize the stack with a series of settings like the ones in the following code snippet - note well that the APIs invoked are not part of JSR 82:

... // set the port number BCC.setPortNumber("COM1"); // set the baud rate BCC.setBaudRate(50000); // set the connectable mode BCC.setConnectable(true); // set the discovery mode to Limited Inquiry Access Code BCC.setDiscoverable(DiscoveryAgent.LIAC); ...

Device Management

The Java Bluetooth APIs contain the classes LocalDevice and RemoteDevice, which provide the device-management capabilities defined in the Generic Access Profile. LocalDevice depends on the javax.bluetooth.DeviceClass class to retrieve the device's type and the kinds of services it offers. The RemoteDevice class represents a remote device (a device within a range of reach) and provides methods to retrieve information about the device, including its Bluetooth address and name. The following code snippet retrieves that information for the local device:

... // retrieve the local Bluetooth device object LocalDevice local = LocalDevice.getLocalDevice(); // retrieve the Bluetooth address of the local device String address = local.getBluetoothAddress(); // retrieve the name of the local Bluetooth device String name = local.getFriendlyName(); ...

You can get the same information about a remote device:

... // retrieve the device that is at the other end of // the Bluetooth Serial Port Profile connection, // L2CAP connection, or OBEX over RFCOMM connection RemoteDevice remote = RemoteDevice.getRemoteDevice( javax.microedition.io.Connection c); // retrieve the Bluetooth address of the remote device String remoteAddress = remote.getBluetoothAddress(); // retrieve the name of the remote Bluetooth device String remoteName = local.getFriendlyName(true); ...

The RemoteDevice class also provides methods to authenticate, authorize, or encrypt data transferred between local and remote devices.

Device Discovery

Because wireless devices are mobile they 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.
A Bluetooth device can use a DiscoveryAgent object to obtain a list of accessible devices, in any of three ways:
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 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.
These three code snippets demonstrate the various approaches:

... // retrieve the discovery agent DiscoveryAgent agent = local.getDiscoveryAgent(); // place the device in inquiry mode boolean complete = agent.startInquiry(); ...

... // retrieve the discovery agent DiscoveryAgent agent = local.getDiscoveryAgent(); // return an array of pre-known devices RemoteDevice[] devices = agent.retrieveDevices(DiscoveryAgent.PREKNOWN); ...

... // retrieve the discovery agent DiscoveryAgent agent = local.getDiscoveryAgent(); // return an array of devices found in a previous inquiry RemoteDevice[] devices = agent.retrieveDevices(DiscoveryAgent.CACHED); ...

Service Discovery

Once the local device has discovered at least one remote device, it can begin to search for available services - Bluetooth applications it can use to accomplish useful tasks. 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. Note that the API provides mechanisms to search for services on remote devices, but not for services on the local device.

Service Registration

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
• Adding the service record to the server's Service Discovery DataBase (SDDB), so it's visible and available to potential clients
• Registering the Bluetooth security measures associated with the service (enforced for connections with clients)
• Accepting connections from clients
• Updating the service record in the SDDB whenever the service's attributes change
• Removing or disabling the service record in the SDDB when the service is no longer available

The following annotated code fragment gives you a flavor of the effort involved in registering a service using the Java APIs for Bluetooth:

1. To create a new service record that represents the service, invoke Connector.open with a server connection URL argument, and cast the result to a StreamConnectionNotifier that represents the service:

   ... StreamConnectionNotifier service = (StreamConnectionNotifier) Connector.open("someURL");

   
   

2. Obtain the service record created by the server device:

   ServiceRecord sr = local.getRecord(service);

   
   

3. Indicate that the service is ready to accept a client connection:

   StreamConnection connection = (StreamConnection) service.acceptAndOpen();

   
   

   Note that acceptAndOpen blocks until a client connects.
   
4. When the server is ready to exit, close the connection and remove the service record:

   service.close(); ...

   
   

Communication

For a local device to use a service on a remote device, the two devices must share a common communications protocol. So that applications can 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.
Because the OBEX protocol can be used over several different transmission media - wired, infrared, Bluetooth radio, and others - JSR 82 implements the OBEX API (javax.obex) independently of the core Bluetooth API (javax.bluetooth). The OBEX API is a separate optional package you can use either with the core Bluetooth package or independently.
Serial Port Profile
The RFCOMM protocol, which is layered over the L2CAP protocol, emulates an RS-232 serial connection. The Serial Port Profile (SPP) eases communication between Bluetooth devices by providing a stream-based interface to the RFCOMM protocol. Some capabilities and limitations to note:

• Two devices can share only one RFCOMM session at a time.
• Up to 60 logical serial connections can be multiplexed over this session.
• A single Bluetooth device can have at most 30 active RFCOMM services.
• A device can support only one client connection to any given service at a time.

For a server and client to communicate using the Serial Port Profile, each must perform a few simple steps.
As the following code snippet demonstrates, the server must:

1. Construct a URL that indicates how to connect to the service, and store it in the service record
2. Make the service record available to the client
3. Accept a connection from the client
4. Send and receive data to and from the client

The URL placed in the service record may look something like:
btspp://102030405060740A1B1C1D1E100:5
This says that a client should use the Bluetooth Serial Port Profile to establish a connection to this service, which is identified with server channel 5 on a device whose address is 102030405060740A1B1C1D1E100.

... // assuming the service UID has been retrieved String serviceURL = "btspp://localhost:"+serviceUID.toString()); // more explicitly: String ServiceURL = "btspp://localhost:10203040607040A1B1C1DE100;name=SPP Server1"; try { // create a server connection StreamConnectionNotifier notifier = (StreamConnectionNotifier) Connector.open(serviceURL); // accept client connections StreamConnection connection = notifier.acceptAndOpen(); // prepare to send/receive data byte buffer[] = new byte[100]; String msg = "hello there, client"; InputStream is = connection.openInputStream(); OutputStream os = connection.openOutputStream(); // send data to the client os.write(msg.getBytes()); // read data from client is.read(buffer); connection.close(); } catch(IOException e) { e.printStackTrace(); } ...

At the other end, as the next code snippet shows, to set up an RFCOMM connection to a server the client must:

1. Initiate a service discovery to retrieve the service record
2. Construct a connection URL using the service record
3. Open a connection to the server
4. Send and receive data to and from the server

... // (assuming we have the service record) // use record to retrieve a connection URL String url = record.getConnectionURL( record.NOAUTHENTICATE_NOENCRYPT, false); // open a connection to the server StreamConnection connection = (StreamConnection) Connector.open(url); // Send/receive data try { byte buffer[] = new byte[100]; String msg = "hello there, server"; InputStream is = connection.openInputStream(); OutputStream os = connection.openOutputStream(); // send data to the server os.write(msg.getBytes); // read data from the server is.read(buffer); connection.close(); } catch(IOException e) { e.printStackTrace(); } ...

If you'd like to learn how to use communication protocols other than RFCOMM, see the JSR 82 specification.

J2ME/Bluetooth Development Kits

Several integrated development environments provide APIs for Bluetooth. When selecting an IDE for J2ME/Bluetooth development, make sure it complies with JSR 82. If you have access to Bluetooth devices, I'd recommend the Java Bluetooth solution from Atinav. It's JSR 82-compliant and based on an all-Java stack, it includes a KVM, and it supports RS-232, USB, PCMCIA, and other Bluetooth devices.
Esmertec, Smart Network Devices, and several other companies offer unique JSR 82-compliant solutions.
Ireland-based Rococo Software has a number of J2ME/Bluetooth products including the Impronto Simulator, which allows you to run Java applications in a simulated Bluetooth environment, where you can test and configure applications before deploying them on Bluetooth-enabled devices. All this, without the need to purchase hardware and a Bluetooth stack! Here's how it works: When an application runs on Impronto Simulator, the virtual Bluetooth stack processes all Bluetooth calls, routing them to the virtual stack of the appropriate device. A discovery server allows devices to locate one another; a GUI helps developers monitor the behavior of simulated devices and networks; an event logger logs API calls and Bluetooth events; and a device editor is used to configure virtual devices. The simulator supports the standard Java APIs for Bluetooth. One limitation is that it doesn't allow you to specify which device is a master and which is a slave. Figure 2 shows a screenshot:




Link: file:///D:/usb/gihan-BLOG/Web%20Site/Bluetooth/Part%20II%20%20The%20Java%20APIs%20for%20Bluetooth%20Wireless%20Technology.htm

Motorola V3 + GPS

Over the last week I’ve been contemplating on other devices which could implement our framework once built.

One of these devices is so abundant in today’s society that nearly everyone has one – the phone.

You take a  phone, or a PDA and couple it with a GPS device. Either inbuilt or via Bluetooth and you have a cheap tracking device.

There are two benefits associated with this.

1.       If Daniel dupes us on the WebTrac, which going by his past record of not coming up with the good is quite likely

2.       This can be used as a proof of concept of other devices integrating with the system.

I believe the actual communication interface is fairly simple, as all a ‘device’ is to do is use a http POST/GET coupled with the login information and a descriptor of the devices location – and voila – point on a map.

Now. If this was to be integrated with a phone. I thought why not use my phone for a PoC.  

Here’s what I need:

-          Gps device

-          Time

So what I did earlier in the week is purchase a Bluetooth GPS device off eBay for $103.53AUD. It’s a Holux GPSlim 236. Then added $24.99AUD for shipping.

Use my phone (Motorola V3) to interface it with the Holux via Bluetooth. Then utilize a Simple J2ME NMEA parser to get the co-ordinates out.

Then write or find something that will  use GPRS to send a http query to a server.

I hope to do all this within the Java Micro-Edition. This is where the secord requirement comes in – time.

Hopefully I will find the necessary code pieces and won’t have to write too much from scratch.

I have been able to find the RAZR V3 (CLDC 1.1) Developer Guide on developer.motorola.com – which has some great code samples, for both Network + Bluetooth communication

Hopefully I’ll find what I need inside.

Also I have located a NMEA parser

With all the pieces set – I need to find a way to put them all together in an elegant and bugfree [can only hope] way.

Link: http://csci321project.blogspot.com/2006/05/motorola-v3-gps_27.html

Mobile GMaps

Mobile GMaps is a FREE application that displays maps from Google Maps, Yahoo! Maps, Windows Live Local (MSN Virtual Earth), Ask.com, Open Street Map and other sources on Java J2ME-enabled mobile phones, PDAs and other devices. MGMaps can connect to a GPS receiver over bluetooth or use internal GPS features on some phones in order to automatically display the map for your current position. You can pre-download maps and store them on your memory card in order to use them on the go without accessing the internet.
Mobile GMaps is distributed under the Attribution - NonCommercial - NoDerivs Creative Commons license. You may download, use and distribute the application free of charge only for personal, non-commercial purposes.

LocateMe - Free J2ME GPS Tracking Software

.

This simple application requires a Bluetooth GPS and will show you the direction to a given GPS location (a "target") without maps, using a pulsing direction arrow. You can request the location of other LocateMe users by text message, send your own location, or just simply save a location for directions back to it later.

The features:

• "Target" other LocateMe users' locations via a request text message


• Send your location to other LocateMe users via text message (can use your contacts list)


• Record your last location as a target


• View all the satellites around you on a "radar" style view


• Display RAW GPS data (suitable for testing)


• Connects to any bluetooth GPS


• Saves your bluetooth GPS and last set target settings

For developers the fully commented source code is a good example of:

• Design patterns, i.e. lazy initialization, command, strategy patterns


• 2 Tier system


• How to use PushRegistry (JSR 118)


• How to use the Record Store (JSR 118)


• How to use Bluetooth (JSR 82)


• How to use Text Messaging (JSR 120)


• How to use the PIM (and hack to minimise the security notices - JSR 75)


• How to use the Location Based API (JSR 179 - Nokia lapi.jar included)


• How to use simple graphics (not using a Game Canvas however)


• How to multi thread effectively


• Provide a basic understanding into Graphical and GPS trigonometry

Known Issues:

• The application is not security signed (this costs money!), so you will be shown numerous security popups.


• As your phone is not a compass the direction target arrow will only point to the correct direction once you start walking, and the phone can determine which way relative to North you are going, i.e. when you are stood still your phone doesn't know which direction you are facing! :)


• On first run there can be some delay discovering the bluetooth devices in busy areas (i.e. it may display "Waiting for GPS..." on first run for some time). This is down to the bluetooth device discovery picking up a large number of devices and querying them. Once you have located your GPS, future connections to the GPS do not require this discovery period and will be relatively quick

This software has been tested on Nokia Series 40 3rd edition phones at a minimum resolution of 128x128 pixels and Sun WTK emulator at 240x320

The software is licenced under the CPL 1.0 licence which is included with the distributions.

Link: http://silentdevelopment.blogspot.com/2008/03/locateme-free-j2me-gps-tracking.html

LOADSTONE GPS - FREE GPS SOFTWARE FOR YOUR MOBILE PHONE

This web site hosts information relating to Loadstone GPS - Free satellite navigation software developed for Symbian Mobile/phones using the Series60 platform. Although Loadstone-GPS is a useful navigational tool for everyone, it is particularly useful for blind and visually impaired people using screen readers such as Talks (TM) (a Nuance product) and Mobile Speak (TM) (a Code Factory product).


To make the most of the Loadstone GPS program, you need technology such as:

• A Symbian (Series 60) mobile (cellular) phone
• A Bluetooth GPS receiver
• A USB Bluetooth dongle (optional)
• A Bluetooth headset (optional)
• A Multimedia card (MMC) reader (optional)
• A high-capacity Multimedia Card (MMC) (optional)

What is Loadstone-GPS worth to you?

Has Loadstone GPS helped you gain independence? Please consider making a donation so it can continue to make a difference.
If you would like to purchase any items or technology to improve your Loadstone GPS experience, the following retailers may be able to help.
In addition, a handy search box is available at the bottom of every page where you may directly search for suitable products or content from the Loadstone GPS web site.

Latitude and Longitude Getting Started

The fundamental work of a geographer begins by describing the location of the topic under study. In order for us to identify the location of some place on a map we need a locational reference system.
Latitude and longitude comprises a grid system of lines encircling the globe and are used to determine the locations of points on the earth. Lines of latitude, also called parallels, run east - west. Latitude lines always run parallel to each other, and hence, they are always an equal distance apart. Latitude lines never converge or cross. The equator is referred to as 0^o latitude, and the North and South Poles are located at 90^o north and 90^o south latitude respectively. In other words, values for latitude range from a minimum of 0^o to a maximum of 90^o.

Lines of latitude measure distance north or south of the equator. The latitude of a particular location is the distance, measured in degrees, between that place and the equator. This distance is measured along a meridian, or line of longitude. If the earth were a perfect sphere (which it isn’t), the distance, or the length, of 1^o of latitude would be constant everywhere. In reality, the earth is slightly flattened at the poles, so the length of 1^o of latitude at the poles is slightly more than at the equator. At the equator, the length of 1^o of latitude is equal to 110.6 km (68.7 mi.) and at the poles, the length of 1^o of latitude is equal to 111.7 km (69.4 mi.). For our purposes, we will assume the length of one degree of latitude is 111 km.

Lines of longitude, also called meridians, run north - south. Meridians are farthest apart at the equator, and converge at the North and South Poles. The prime meridian, which runs through Greenwich, England, is referred to as 0^o longitude. Points are measured east or west of the prime meridian until one reaches the opposite side of the prime meridian, which is referred to as the International Date Line. This is considered 180^o longitude, and is the highest value which longitude can take. In other words, values for longitude range from a minimum of 0^o to a maximum of 180<sup>o

for more Link : http://www.digitalmobilemap.com/latitude-and-longitude-getting-started</sup>