Opening API about android-ble-library HOT 3 CLOSED

Thanks for asking! I was just about to ask about this myself. My vote would be for both 2 and 3.

I found myself wanting access to these things in my BleManager subclass:

• The readRssi() method
• The createBond() method
• The Context passed in to the constructor, which I need in order to go and get some singletons in my app.

from android-ble-library.

Our implementation follows 1)

On the one hand, it helps in keeping BT implementation details contained in 1 class, and we can expose operations with semantic meaning in our domain. On the other hand, it does end up becoming a God class. Our BleManager implementation is ~550 lines with very little tests (see #45)

Implementing 2) would helping in having smaller, domain-specific Ble classes if we were able to keep a single queue request. As I'm thinking it right now, we'd have a singleton BleManager instance and per-feature wrappers over it. This'd make smaller classes with easier testing.

SensorBleManager @Inject constructor(private val bleManager) {
    fun enableVibration(){
        bleManager.writeCharacteristic(...).enqueue()
    }
}

Which methods are you considering to make non-final? What would be the goal? Is it to facilitate testing or are there other reasons?

from android-ble-library.

Let's leave the testability to #45.

I was thinking about definaling methods that return Requests, e.g. writeCharacteristic(...), etc.
This may be useful if the BleManager instance is to be used as a generic BLE controller, not as a device API. Currently, to expose such method, you need to add some prefix/sufix to the method name, which isn't very big deal, but makes it uglier. I found it useful in 2 cases, as far as I remember, where I wanted to call those methods from outside of manager. In that case I had a TestImpl, which just had the logic of which ble operations should be done. I didn't want to include it in BleManager for some reason.

Regarding having smaller domain-specific classes, I was rather thinking about allowing to add "modules" to the manager, responsible for some part of the logic. For example, DFU module, Battery module, etc.
Currently, what we do in nRF Toolbox, is just extending the BleManager with for example Battery logic, and then extending this in other profiles. I'm not yet sure the module approach is feasible, would it increase or decrease testability, but at least would split the class logic.

So far I'm (almost) convinced to make request operations non-final. Then exposing readRssi or createBond is straightforward.

from android-ble-library.