Flutter_blue: cancelConnection might have same issue as stopScan

[brianegan]

Hey hey :) Just noticed connect and cancelConnection... quick scan looks like it might have the same issue as the other PR we merged with startScan / stopScan and thought I'd note it

[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?

[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?

[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.