Here I want to give a short summary of the transport methods that could be used for the mobile transport layer and what I found out by research and testing.

One of the use cases for the mobile transport layer describes how the data is sent from the mobile device to the via an intermediate station. This is necessary in cases when the mobile has no direct internet access. This so called intermediate station could be any laptop or desktop PC. It has to queue the received data and later on, when there is an internet connection available, forward it to it’s final destination (i. e. the server). There are several ways how data could be transferred between a laptop/PC and a Java-enabled mobile device:

• Cable: Mobile and PC can be connected by a cable. From the programming side this means to establish a serial connection between the two devices. The following has to be considered:
  • Support for serial connections on J2ME devices is not mandatory. Some mobile devices may support serial connections, some may not.
  • On the mobile, the COM port has to be selected. First tests showed, that there may be listed dozens of available COM. So far I found no way to determine the right COM port automatically. To let the user chose from the list won’t be practicable, I guess.
  • On the other side of the connection (the PC), problems arise because Java’s poor support for serial connections. The standard SDK does not provide an API to access the serial port. There is the JavaComm API, an extension to the SDK, but it does not support the Windows platform. A 3rd party library for serial connections is RXTX, which supports a larger number of platforms including Windows. Anyhow, some installation of the required DLLs would be necessary.
• Internet: Data can be send from the mobile to the server directly by HTTP. This transport method was easy to implement and HTTP support is mandatory for all J2ME devices. However, in cases the mobile is not configured for internet access, alternate transport methods may be used to send the data to an intermediate station first, which has the ability to connect to the internet.
• Sneaker net: This term means to save the data to a removable storage media and then carry it to it’s destination. In case of mobile devices this seems to be a good options, since many mobiles come with slots for SD cards. Access to the file system on mobile devices using Java is provided by the PDA Optional Packages for the J2ME Platform, a.k.a JSR-75. At the other side (the PC) the SD card can be inserted into a card reader.
• Bluetooth: Sending the data through a wireless Bluetooth connections turned out to be fairly easy. Most mobile devices nowadays are equipped with Bluetooth hardware and the optional API, namely JSR-82, is already widely supported by Java-enabled smartphones. This transport method is implemented in the transport layer and has been tested successfully by sending data from one mobile phone to another. Unfortunately, the Java SE does not include Bluetooth support, so connecting to a PC requires additional software.
• Native synchronization: An appealing way to exchange data would be using the native synchronization feature of the device. As for Palm OS PDAs, this feature called HotSync, while PDAs running Windows CE come with ActiveSync. But, as these are native features, there doesn’t seem to be a Java API available to access them. Still, after some research I found an interesting article, that describes how to sync up Palm OS with J2ME. The idea behind is to save the data to a record store and implement a conduit (something like a plugin for the HotSync manager) capable to understand the file format of the saved record. It seems possible to implement such a conduit, but some effort will be necessary.

It has been nearly two months since the project started and it’s already high time for my midterm update post. Let’s summarize what I have achieved so far:

I have developed a working demo which is able to send data from a mobile directly to a server using an internet connection (HTTP POST to be precise). The mobile keeps the data in persistent storage and keeps track of the status of the message sent. This demo is implemented as a MIDlet and can be run on any mobile supporting MIDP 2.0 and CLDC 1.0. Almost every smartphone and PDA should meet these requirements. The main target devices are PDAs (which can be expected to support even CDC). But as the CLDC is a subset of the CDC, there shoudn’t be any compatibility issues. Anyhow, tests will show later.

As a second transport method I implemented a connection via bluetooth. Almost every mobile is equipped with bluetooth nowadays. Even the Java bluetooth API (a.k.a. JSR-82) is widely supported by mobile devices. Bluetooth dongles for the PC are not expensive and the connection is set up easily. That makes it a good way to send data from a mobile to a PC or laptop. After some trying with the device and service discovery mechanisms, I finally managed to send data from one mobile to another.

The goal for this week is to get a bluetooth connection to work between a mobile and and a PC. Unfortunately, there is no bluetooth support within the Java SE, so I have to evaluate 3rd party Java bluetooth, who can give access to the native bluetooth stack through Java. I have started with bluecove, an open source bluetooth implementation. Bluecove is at least partially compatible with JSR-82, the bluetooth API used on mobile devices. Possibility of using the same API on both sides would simplify things a lot. According to the documentation, bluecove requires Windows XP having the Microsoft Bluetooth Stack installed. Hm, so much for platform independency..

The term Mobile Data Collection Tools refers to a set of tools for mobile devices such as smartphones and PDAs, which are

The part I am working on over the summer is a transport layer, which is responsible for the transport of the data either from a mobile device to the server or in the opposite direction. The transport layer has to make sure the data reaches it’s destination in a reliable and secure way.

A couple of things have to be considered: There are various different way for a mobile to communicate with other devices. A mobile might open an internet connection to a server or be connected to a device nearby by cable or bluetooth. Also, data must not necessarily transferred to it’s destination directly. Think of a mobile device without direct internet access. It may as well transmit the data to a laptop first, which will then forward the data to the destination on behalf of the sender.

This year I am (proudly) participating in Google’s Summer of Code program. So, over the summer, I will be working on a project for OpenMRS: Mobile Data Collection Tools. I will describe the project in detail later. It is recommended by our organization to document the progress we are making in our blog. So, I have no excuse anymore to setting up my own blog — and here it is.

Over the next weeks, I will try to give updates on the progress of my project twice a week. Hope it will be interesting for you to read.