Access to low level bluetooth callback in custom operations

[uKL]

In order to improve throughput more, I'd like to have more direct access (skipping Rx overhead) to BluetoothGattCallback.

Let's discuss how.

[dariuszseweryn]

First idea - add a callback listener for every possible callback of BluetoothGattCallback

[uKL]

This was my first idea, with a few assumptions:

1. Only one callback listener can be plugged in at time
2. It sticks to a custom operation paradigm
3. The callback listener is disposed (null) at the end of the custom operation automatically to prevent leaks.

What do you think?

[dariuszseweryn]

Why 1. Only one callback listener can be plugged in at time?

[uKL]

To simplify the whole thing and avoid list iteration. In the scope of a single custom operation, I think it will be enough. What's your opinion?

[dariuszseweryn]

Ah, one at a time in this meaning. That's reasonable. I first thought of a Callback Listener per callback type (one callback for onCharacteristicWrite() other for onCharacteristicChanged() and so on) and that one could not set both at the same time.

[uKL]

Nope, I'm thinking about some abstract class implementing BluetoothGattCallback providing default, empty methods as templates. The user would be able to implement whichever callback required and only that one.

[dariuszseweryn]

Is available in 1.4.0-SNAPSHOT

[RobLewis]

This sounds interesting. Is there any documentation of how it fits into the RxAndroidBle overall scheme? Usage example?

[uKL]

Hey Rob,
all you need can be found in RxBleGattCallback#setNativeCallback Javadoc. The BluetoothGattCallback interface is documented in Android’s documentation.