bluetoothDevice.discoverServices() doesn't return anything about flutter_blue

[ened]

This should be a lot simpler. I noticed it sometimes works fine, which may be related to how BLE service discovery works internally on a phone. My Samsung S5 may cache the list of discovered services, which then causes onServicesDiscovered to be called right away (e.g. before the StreamHandlers onListen method has been called).

My workaround looks like this:

var services = await device
    .discoverServices()
    .timeout(Duration(seconds: 10), onTimeout: () => <BluetoothService>[]);

if (services.length == 0) {
  print("Service list empty, flutter_blue race condition?");
  services =
      await device.services.catchError((error) => <BluetoothService>[]);

  if (services.length == 0) {
    print("no services advertised!");
    _cleanupAndCancel();
    return;
  }
}

[dturing]

So my proposed patch seemed to fix the issue, but it's not all reliable. Before, the "sink:null" issue would occur most of the time; after the patch, it occurs much more rarely, but still does. I'll keep investigating, but am grateful for any help.

[dturing]

I now think the problem is way deeper than just this.

It seems all Bluetooth operations should be queued as to avoid the otherwise common "PlatformException(read_characteristic_error, unknown reason, may occur if readCharacteristic was called before last read finished.".

If i want to read a number of characteristics, i have to await each of them before submitting the next. While this can work (although i'd want to dispute putting the "queueing burden" on the flutter_blue user), in the case of setNotification i don't think there's an easy way. There's no reply EventChannel set up, and in fact there are two operations (writing the CCCD and setting notify) that both return asynchronously from gattServer, so it's unclear how one could even wait for the setNotification to finish.

So to me it seems maybe the java FlutterBluePlugin should return results to those method calls only when they actually finish (their respective BluetoothGattCallback method is called), and also queue them up so only one such operation is attempted at any time? This way a user of flutter_blue wouldn't have to care about running only one method at the same time, and it might clean up the somewhat awkward setting up of extra response channels. It might also tune in well with #11.

Now, i'm not quite sure i can find the time to attempt this somewhat bigger operation. But if- @pauldemarco, do you agree with my rationale?

[pauldemarco]

Hi @dturing,
Sorry for the delay, I'll be looking into this soon, any updates?

[dturing]

Cannot reproduce with current version from git, thank you.

[Mojachieee]

I'm still getting this error on the latest git version.

This will never print services:
List services = await _device.discoverServices();
print("Services");

The app also prints (if that's related)
onServicesDiscovered: 5 sink:null

I'm using Flutter Channel beta, v0.5.1

Let me know if you need any more details

Edit:
It looks like it might be a race condition.

I'm running it in the callback for FlutterBlue.connect, running the code in Future.delayed(Duration(milliseconds: 100) resolves the issue most of time

[Bakhoj]

I also have the problem with sink:null.
My solution for now is making the discoverService into a recursive method.
I call the method when the state changes to BluetoothDeviceState.connected when subscribing to BluetoothDevice.onStateChanged().listen().

BluetoothDevice device;
bool isServicesDiscovered = false;
List<BluetoothService> services = new List();

_discoverServices() {
  device.discoverServices().then((s) {
    services = s;
    _updateServices();
    isServicesDiscovered = true;
  });
  Future.delayed(Duration(milliseconds: 100), () {
    if(!isServicesDiscovered && device != null)
      _discoverServices();
  });
}

The _discoverServices() calls itself every 100ms until the services is found or the connection is no longer established (if you set device = null when you disconnect).
From the few test I've done it doesn't go further then till 2nd discoverServices before it is succesful.

[bjornwilliam]

I am experiencing an issue where services are discovered every time when I first connect to a bluetooth device. But if I turn the bluetooth device off and then on again, device.discoverServices() will never return.