[Fmx, Android] TBluetoothLE device disconnect

[Rollo62 536]

Hi there,

 

I've try to optimize my BLE codebase from time to time, and there was always an issue with disconnecting BLE devices on mobile.
This is decribed in this article nicely, and give some more clues and insights probably.

 

I used to completely destroy my TBluetoothLE object, to get at least a working disconnect, although this sometimes may hang
for 10 sec. and needed 2-3 trials before it really was ready to re-connect a new device.
This article above gives some more explanations to the issue where the root cause of the problem may lay.

Again I tried to remove the TBluetoothLE.Free and several other harsh measures, but the disconnect issue strikes back of coarse.
I've tried to disable and re-enable BluetoothLE, which looked very good at first sight, but then made problems again on different Android devices.

 

Since my TBluetoothLE.Free code is quite "messy" and more ad-hoc, I wanted to clean up (like every year).

Maybe someone has similar issues, and found probably other solutions to the issue ?

Would be great if we could share our experiences here.

 

BTW: This issue also concerns iOS of coarse, but I think the issue with Android is harder at the moment.

Edited December 9, 2019 by Rollo62

[Lars Fosdal 1792]

Have you collected a list of devices / OS versions that have particular behaviours?

[Rollo62 536]

I'm just doing first tests on Samsung Galaxy S7 Edge, Samsung Galaxy S9 Plus, iPhone XS and iPhone 6 S.

While IOS behaves quite friendly, no need to destroy the BluetoothLE device,

on Android the devices not always get clean without destroying.

Just to make it clear, it works with the destruction mehtod more or less stable, but I would like to find a less
drastic and more reliable way.

 

I'm working on the 4th generation of my libraries now, and I really wonder if there is no right way to connect/disconnect devices.

Usually connecting once is no problem, but after disconnect sometimes work, sometimes don't sometimes need to wait about 20 sec., as described in that articla.

 

If there is a golden way to cleanup, would be great know, I just make experiments with TJBluetoothAdapter.disable,
but unfortunately Embarcadero had hidden many relevant classes in the implementation sections of the units.

 

When I use the embarcadero samples, all is fine, unless

• I call device.disconnect, or
• the device disconnects by power off, or
• the device goes out-of-range
• etc.

Connection is OK, but clean disconnection seems not really much considered in those libraries, or maybe even in the

Android/iOS SDKs itself.

 

 

 

Edited December 9, 2019 by Rollo62

[Lars Fosdal 1792]

It could be BLE version / chipset dependent. 

 

That out-of-range issue is a killer, really. Not being able to do a proper recovery there is pretty darn hopeless.

[Rollo62 536]

Yes, probably thats adding issues on top.

But I'm afraid this is a more deep issue in Android (as well as in iOS).

There are many references in the web where it leads to the same conclusions, that BLE is not very stable implemented.

https://stackoverflow.com/questions/23110295/difference-between-close-and-disconnect

https://devzone.nordicsemi.com/f/nordic-q-a/38422/android-disconnect-and-close-do-not-disconnect

https://medium.com/@martijn.van.welie/making-android-ble-work-part-2-47a3cdaade07

https://android.jlelse.eu/lessons-for-first-time-android-bluetooth-le-developers-i-learned-the-hard-way-fee07646624

https://punchthrough.com/android-ble-development-tips/

 

You have to play around with various methods, timing, callbacks, etc., to find a workable solution.

I had hope that somebody has experienced the same issues, and knows probably a good and clean way to solve this.

 

In above article from Martijn van Welie the Blessed library is recommended, as more iOS compatible and "friendly",
so I have hope that such improved library may also exist for Delphi.
If not, maybe some fixes for the BLE System libraries might exist, but I always try to avoid this, especially if they cannot be accessed easily.
I think that the main issue that Delphi is used to make fast prototypes, but not stable applications for BLE in most cases,
where these issues might be acceptable.