Quick view to JxCore Thali plugin architecture (android part)

I’m going to have my summer vacation after this week, and wanted to make it a bit easier to anybody who wants to check my codes to actually understand what each parts are doing there.

And to do this I decided to draw some graphics depicting how different classes are interacting and being handled in the system.

The first part the the main view for the plugin from the part where JxCore android plugin meets the android library for Thali:

Main_stuff

The JxCore plugin is using the library through a helper class called BtConnectorHelper, which is the sole entry point  to the library. From library side, the sole entry point is the BtConnector class.

The BtConnector class then is handling two issues. It should know when to start/stop advertising & scanning. The codes for the task is handled in BtConnector_Discovery class. BtConnector_Discovery class then has its internal logic to find peers and uses simple three function interface to pass the results to the BtConnector.

The other task BtConnector has to do, is to handle connectivity to the peers. This is handled in BtConnector_BtConnection class.  BtConnector simply starts/stops the class instance, and the instance will simply tell the BtConnector when outgoing connection failed, or when it did manage to get fully connected socket connection to the remote peer.

Then lets have a look into these two classes and their internal works. The BtConnector_Discovery is rather simple.

BTConnector_Discovery

The WifiServiceAdvertiser, is simple started/stopped when the instance of BtConnector_BtConnection is created/deleted. Then the WifiServiceSearcher will have its own logic to find peers and services implemented in them, and use the three function interface to notify the instance of what it has found.

The BtConnector_BtConnection class then looks like this:

BTConnector_BtConnection

 

In essence, there is always one BtListenerThread active, and ready for any incoming connections. The one possible BtConnectToThread instance is created when there is tryConnect() call originating from BtConnectorHelper class. Error situations on incoming connections are never reported outside BtConnector_BtConnection , they simply re-start the listening process.

Once either of the previously mentioned class instances has managed to create connection successfully, they pass the connected socket to the BTHandShaker class instance.

This  instance will use its own BTHandShakerSocketThread for reading/writing to the socket to handle quick handshake. The handshake makes sure that the connection is fully working, as well as it is used for supplying the discovery data in cases where the device we are connecting to, does not have discovery data for the incoming peer yet.

The Connected callback function of the BtConnector will only be called if the BTHandShaker gets its handshake successfully done.  And once this happens the BtConnector will give the BtConnectorHelper fully connected socket, and also identify whether it was incoming connection we accepted in out listening thread, or whether it was connection we started.

The following picture then illustrates what happens in the BtConnectorHelper side for the connected socket:

BtConnectorHelper

If the socket was for incoming connection, then there is a new instance of BtToServerSocket  created for it. There can be multiple instance of BtToServerSocket , and currently the implementation does not pose any limits for the number of them, but do note that the Bluetooth performance likely drops when there are more connection to be handled.

For outgoing connection there can only be one instance of handler available at any moment. The handler is then instance of BtToRequestSocket  class.

Both BtToServerSocket  and BtToRequestSocket  are then having two instances of StreamCopyingThread class. One for copying incoming stream and one for copying data to outgoing stream.

And as the name suggest, the BtToServerSocket  is connecting the incoming Bluetooth socket streams to the NodeJs TCP/IP server streams, and the BtToRequestSocket is catching the NodeJs TCP/IP client request and connecting it to the Bluetooth streams.

Basically this is just really brief overview of the implementation, there are of course loads of things that happens when the codes are run, anyway, I do hope this article would help on understanding the internal structure of the android implementation.