cancelConnection might have same issue as stopScan about flutter_blue

[brianegan]

Ah yah, I see the dilemma...

Sorry, I think my wording was a bit brief and I was unclear! My original thought wasn't to convert the Future to a Stream, as Futures deliver a Single Value (which is what you have in this case). Rather, my idea was to add a whenComplete(cancelConnection) to the end of your Future chain that would ensure the methodChannel was closed automagically. This is essentially what we did for the scan method.

However, given the connection must remain open while using the device, I'd keep returning a Future. In that case, the cancelConnection might still be a bit confusing, because if you perform a cancelConnection on your flutterBlue instance, you might not realize that an unrelated object is now useless.

What you could do instead is add a disconnect()-type method to the BlueToothDevice instead. Then the api would look like:

final device = await flutterBlue.connect(someDeviceId)

device.doSomeStuff();

device.disconnect();

Whatcha think?

[pauldemarco]

Although the context might be similar, this needs further consideration.
Neither iOS or Android time-out their connection requests (unless autoConnect = false on Android).
This means the user must keep a handle to a connectionSubscription for as long as they would like to be connected to the device, not necessarily meaning they are connected.
It may require an android edit, but at the moment I'm not seeing any reason why this wouldn't work.

[pauldemarco]

What to return from the Stream is up for debate, I figured a BluetoothDeviceState would make the most sense. With this, the listener can kick off discoverServices once the device has connected.
Any thoughts?

[sandangel]

With current API and flutter hot reload feature, sometimes I found that the reference to the connection often gets lost between hot reload. And if the auto reconnect function is turn on, there is no way to disconnect except shutting down the app. The API that @brianegan proposed looks easier to use for me.

[wkornewald]

@pauldemarco Is there a reason why you set autoConnect to true? The problem is that this makes connect() take a very long time (often more than 30s) and our device turns itself off before the connection can be established. With autoConnect set to false the connection is established almost instantly.