[#165] Added support for native BluetoothGattCallback usage in custom…

[uKL]

Added support for native BluetoothGattCallback usage in custom operations.

Really silly performance test:

• based on JUnit
• invoke onCharacteristicRead like the system would do 1000000 times
• assert on number of read events received from RxJava based implementation and the native one
• test does not include load and delay introduces by the ExecutorService, wrapping emissions through the RxJava API

RxJava API @ 1000000 calls => 7905ms (0.008ms/call)
Native API @ 1000000 calls => 2076ms (0.002ms/call)

[dariuszseweryn]

Looks good.

[6bangs]

Cool! Can this be used for a long-running task concurrently with other usages of RxBleConnection (writing and reading characteristics, etc)?

[uKL]

@6bangs no, it's not recommended. When the operation is completed we are releasing the radio lock. Having multiple bluetooth operations not synchronized may cause abnormal behaviors.

Anyway, the native callback is automatically released when the operation is finished. Is there any reason you wanted to use it that way?

[6bangs]

Yep. We deliver OTA updates transparently to our users while the device is otherwise in use (reading heart rate, etc). It works great currently, but it takes 4-6 hours to complete.

Maybe we could use this if we opened a second RxBleConnection to the device specifically for OTA. Is there any reason that wouldn't work?

[dariuszseweryn]

Hello @6bangs
Could you explain in a bit more detail how do you achieve that? You want to have a constant stream of Heart Rate with a fixed interval - do you perform a read operation once every second (or a different amount of time) for that or do you use notifications? The library is implementing a priority queue but it is not available through the API. It would be possible to add for instance a low priority characteristic write to the next API.
Again if you would describe your use-case in greater detail - I will be able to think about how to make it possible.

Edit: And to answer your question - it is only possible to have a single RxBleConnection to a specific device at any given moment. You will get BleAlreadyConnectedException if you will try to open a new connection to the same device when it is already established.

[6bangs]

Of course. Our device uses characteristics not defined in the BLE spec for both OTA and heart rate measurement (among other things). We set up notifications for heart rate measurement via the usual setupNotification method of RxBleConnection. Most traffic happens via notifications, but during OTA we do a lot of writing until the OTA process is complete. We also write occasionally to update the state of the device (set the heart rate monitoring interval, etc).

We can perform all of these operations concurrently, and it's working really well. OTA just takes forever due to RxJava overhead.

With regard to BleAlreadyConnectedException, is that a limitation of RxAndroidBle or the platform? I haven't actually tried connecting multiple BluetoothGatts to the same device with the same app, but I assumed it must be possible since multiple apps can connect to the same device at the same time.

[RobLewis]

@6bangs Are you using the ConnectionSharingAdapter to multiplex your various reads and writes with a single RxBleConnection? I recently switched to this from my somewhat lame home-brewed solution and it seems to be working well. More here.

[6bangs]

Yep, exactly. Sorry, I forgot that detail; wrote that code almost a year ago. If I recall, I found it in an RxAndroidBle example. I bet it's something that's useful enough it should probably be called out in the README.md.

[dariuszseweryn]

@6bangs The BleAlreadyConnectedException is a conscious decision to prevent people from interfering with their own interactions with the connection from different places in the code. This decision was taken because it is impossible to create BLE connections in the same stateless manner as HTTP.

It is possible to achieve what you want but you would need to put the OTA and updating the state of the peripheral in the same RxBleRadioOperationCustom and manage writes all by yourself.

[6bangs]

Ah, cool. Will look into that.