Android Patch für 10.2 Tokyo verfügbar

[Mavarik]

Zitat:

Zitat von Rollo62 (Beitrag 1375250)

Ansonsten immer noch recht zäh, es reagiert nicht immer auf Klicks, man muss manchmal zweimal klicken

Machst Du auch schon im OnButton Click nix und führst den Code darin beim nächsten OnIdle aus oder im Thread?

[Rollo62]

Ich habe viele Units über TMessageManager entkoppekt, Entkopplung über Interfaces, viel mit Threads gearbeitet, etc.
Viel mehr Aufwand als unter Windows nötig wäre, das musste ich aber schon machen damit es überhaupt stabil läuft.
Natürlich sind da jede Menge Tricks nötig gewesen um die Sache überhaupt ans Laufen zu bekommen.

Von den Fmx Features nutze ich prinzipiell nur die einfachsten Controls (Layout, Tectangle, Label, Button), bis hin zu TListView), weil ich gar nicht erst bei komplexren Controls die Fehler bekommen möchte.
Das Dumme ist jetzt wohl das Emba beim Threading das unterste zuoberst gekehrt hat, und jetzt muss
ich vermutlich Alles nochmal komplett einzel checken wo die Probleme sind.

Mobile ist noch extrem fragil an zig Stellen, deshalb würde ich solche großen Umwälzungen bei Kernfunktionen ungerne sehen.
Aber was soll man machen, es muss halt mal was optimiert werden, dagegen will ich gar nichts sagen.
Aber wenn noch nichtmal die eigenenn Fmx-Demos mehr sauber ablaufen dann sollten Emba den Release lieber verschieben, oder zumindest eine klare Warnung oder Hinweise rausgeben.

iOS läuft auch noch nicht sauber, was aber im Wesentlichen an dem Umbau beo XCode liegt.
Dafür hätte ich mir auch schon jetzt ein Update gewünscht, damit man nicht immer mit Umschaltung der XCode-Versionen frickel muss.

Rollo

[mensch72]

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 :)

[himitsu]

Problem ist IMHO auch, dass Exceptions in Threads standardmäßig abgefangen und dann einfach fahrlässig verworfen werden, anstatt sie im laufenden Programm auszugeben.

Am Einfachsten ist es, wenn man sich eigene TThread-Ableitungen bastelt, wo nach dem Terminate Diese ausgegeben werden.
Problem, dass die meisten, welche sowas bei sich nicht einbauen auch jene sind, die scheinbar nicht wissen wofür man den Debugger nutzt, denn standardmäßig werden solche Exceptions nur da angezeigt.
Aber Codegear/Embacardero hört zu selten auf die Community, anstatt mal ein ordentliches Standardverhalten direkt ab Werk anzubieten.

[Rollo62]

Hallo Mensch72,

ja genauso mache ich das auch.
Um BLE habe ich eine Menge Threads und Queues rumgebaut damit es sauber funktioniert.
Ein paar kleinere Bugfixes inklusive in den Libraries.
Es lief bis zuletzt dann auch sehr sauber, obwohl Emba seit XE8 da nicht mehr viel dran geändert hat.
Die Demos sind meistens proof-of-concept, da scheint Niemand tiefer in die Problematik einzutauchen.
Das muss man halt selber machen.

Übrigens läuft die gleiche App unter iOS / OSX noch perfekt so wie sie soll mit Rx10.2.
Also sollte Android wieder FMX-Kompatibel gemacht werden.

Aber danke für den kleinen Hinweis das es ja nur ein "Patch" ist und
die Regel lautet "Warten bis Update 1".
Ich hoffe das in Upd1 die Fehler dann moderat beseitigt werden, und nicht noch eine neue Baustelle bei iOS aufgemacht wird.

Rollo