ich empfehle bei BLE Sachen einen Blick in das BLEscannerDemo von Delphi... man sieht z.B. Emba das was ein True/False zurückgibt löst per Aufruf in
"TThread.CreateAnonymousThread(procedure..."
DiscoverServices in diesem Beispiel. Und man sieht auch wie man IN dem ThreadTeil auf Fehler(False Rückgabe) reagieren soll.
Witzig ist, das die Funktion des Bespiels nur exakt einmal funktioniert... ohne NeuScan klapp im org. Beispiel kein 2. Aufrauf !?
Dabei müsste man doch nur per vorherigem "UpdateOnReconnect:=True" dafür sorgen, das es wieder geht wie früher.
Da der "Fehler" ja aktuell in dem AnonymousThread nur eine nichtssagende Exeption wirft, braucht es viel Geduld sowas zu finden. Und das ist nur der erste Step.
Nach Connect sollte man sich hüten in den OnRead/OnWrite Events zu versuchen weitere WriteCharacteristic Aufrufe "direkt" zu machen... die müssen in einen "TThread.CreateAnonymousThread(procedure...", sonst gibt es nach mehr wie ca 16 Aufrufen je nach Androidversion die seltsamsten (wohl Rekursions) Efekte.
Wer schnell viel hintereinander senden will, sollte dennoch nicht im OnWrite gleich das nächste "Threaded Write" aufrufen, besser "merken" und schnell raus aus allen OnXXX Events(weil diese wohl blocked synchron zum Android-
OS-BLEstack laufen und allergisch auf große Verzögerung oder gar Rekursion reagieren). OnIdle geht ja jetzt wohl wieder, ich hatte zwischendurch versuchsweise auf einen 20ms Timer umgestellt... das macht so alles keinen Spaß.
Bei unkontrollierten Verbindungsabbrüchen beenden einige Androidversionen gerade eine FMX APP hart... man kann es testen wenn man bei aktiver Verbindung einfach mal seine Gegenstelle "hart abschaltet", ober wer MicroChip BLE-Module ala RN4020/RN4871 einsetzt dort einen "Reboot" per "R,1" Kommando auslöst wenn die Verbindung noch besteht. (Rollo62 wird das kennen)
Gut ist, man kann in Tokyo viel mit Aufwand irgendwie lösen oder umgehen, aber man kann auch weiter Berlin 10.1u2 einsetzen, bzw. sich eben einen eigenen Merge aus Berlin&Tokyo
RTL FMX-Sourcen basteln(den man dann aber bei so Stückwerk wie jetzt auch wieder nachführen und neu testen muss).
Trotzdem hoffe ich auf Tokyo 10.2u1 mit/für IOS11
