Bluetooth ServerThread Interface Design

I've managed to work out BlueCove sufficiently enough to use it. Its syntax is identical to that of J2ME. J2ME is a version of Java that is designed to work with small devices, hence its built-in API support of Bluetooth. BlueCove, however, lets us use these same commands with J2SE (Standard Edition) and your basic computer running Windows or OSX.

I have also learned how to use these commands to write client-side and server-side algorithms to get devices to communicate. A useful, if slightly unclear, example can be found on CodeGuru.com. This gives us an input and output stream to work with. Since BlueMesh ultimately uses just an input & an output stream, this should be fine. However, BlueMesh's ServerThread currently passes a "BluetoothSocket" object instead, and that object is deconstructed to an input and output portion in the ReadWriteThread. So, BlueMesh is going to require a back-end redesign.

The ServerThread-like Interface will need to export an input and output stream. This is because the input and output streams are the lowest common denominator in the Android API and the J2ME API. The J2ME API gets these streams from the StreamConnection object, while the Android API gets them from the BluetoothAdapter object. Each object is specific to its own API, and cannot be included in an agnostic BlueMesh. So, the ServerThread will have to send only the input-output stream and some sort of device-identifying data (Device Name? Random Serial Number?) to the RouterObject. It will then be the RouterObject's job to find out if that device is already connected and to set up the ReadWriteThread for it.

Further, the way that J2ME handles clients is unusual. Specifically, it does not generate a BluetoothSocket object, so ClientThread will have to be reworked as well. The J2ME client is implemented with a virtual class, "DiscoveryListener", with four purely-virtual functions that are called when certain things happen, such as discovering a device. I am unsure as to whether or not this class is automatically a thread or really much about clients in J2ME at all. More research will have to be done.

Hopefully, I will just be able to extract from one of these functions/objects the input and output streams, so that the overall design of BlueMesh can be preserved. Otherwise, the ServerThread may be the only object able to set up communication and pass it to the router, meaning the client-side ClientThread will have to invoke the ServerThread to create two-way communication. I want to avoid this, so hopefully it won't be necessary.

Interfacing with others!

Hello, All! As detailed in the last post, BlueMesh will be trying to make the move towards greater compatibility. Specifically, we're looking towards creating a Java interface that will encapsulate all of the proprietary portions of Bluetooth. So, if you are willing to write an interface class for your platform, then BlueMesh will work on it.

That's the vision. Practically, BlueMesh will have to come with a couple of common interfaces. Luckily, I found another open-source project, BlueCove, that will allow Microsoft, OS X, and a few other platforms to do just that. Specifically, I no longer have to write code for these machines specifically; I can use this program as a bridge. More importantly, I hope that BlueCove will give me some insight as to what exactly the BlueMesh interface should expect and contain, so that any interfaces can be written easily.

This task, as large as it is, is one of my greater priorities, for two reasons.
1) It will give BlueMesh greater compatibility and intercommunication
2) It will allow for testing with the library itself to be done one any one platform, and it can be a platform of choice. The Android SDK is nice enough, but doesn't allow for easy debugging. If this interface is successfully written, then BlueMesh can be tested, and eventually operated, between any two Bluetooth-enabled devices.