Android: TThread

[Der schöne Günther]

Bitte gib Rückmeldung was es nun gewesen ist - Vor allem was für Probleme. Ich habe unter Android (und iOS) mehrere TThreads welche Indy-Komponenten (TidTcpClient ) benutzen die im Hauptthread erstellt wurden. Keinerlei Probleme.

Kannst du ein Minimalbeispiel erstellen?

[SebastianZ]

Zitat von greenmile:

Dann rufe ich im Thread Daten mit IdHttpClient ab, die wird vom Constructor vom Create erzeugt. Allerdings liefert die Teileweise müll oder der Zugriff darauf stürzt ab. Geht das nicht? Kann ich kein IdHttp im Thread verwenden?

Prinzipiell würde ich mir mal als alternative zu TThread den TTask/ITask ansehen: http://docwiki.embarcadero.com/RADSt...amming_Library

Das von dir beschriebene Verhalten deutet eher auf unschöne/ungesicherte Zugriffe von Thread und Hauptthread auf die gleichen Ressourcen hin.
Kannst du mal ein Minibeispiel mit diesem Verhalten bereit stellen?

Update: Bitte bei dem Beispiel vom Emba zu TTask aufpassen: Showmessage ist hier denkbar schlecht. Dies sollte nie ohne Synchronize/Queue aufgerufen werden!

[jaenicke]

Suspended ist ohnehin finde ich keine wirklich schöne Variante. Entweder der Thread bekommt alle Daten gleich im Konstruktor oder wartet vor der Ausführung auf ein Signal. Letzteres kann man dann gleich zur mehrfachen Benutzung des gleichen Threads verwenden.

Die Parallel Programming Library mit ITask usw. bietet da aber wie SebastianZ schon geschrieben hat eine Menge an Funktionalität.

[bra]

Zitat von jaenicke:

Suspended ist ohnehin finde ich keine wirklich schöne Variante. Entweder der Thread bekommt alle Daten gleich im Konstruktor oder wartet vor der Ausführung auf ein Signal. Letzteres kann man dann gleich zur mehrfachen Benutzung des gleichen Threads verwenden.

Wenn man aber z.B. Events wie OnTerminate usw. setzen will, bringt einem ein bereits gestarteter Thread nichts und was ist jetzt der Unterschied, ob ich ein "Signal" schicke oder den Thread Suspended erstelle und über die vorhandene Funktion starte?

[Mavarik]

Zitat von bra:

Wenn man aber z.B. Events wie OnTerminate usw. setzen will, bringt einem ein bereits gestarteter Thread nichts und was ist jetzt der Unterschied, ob ich ein "Signal" schicke oder den Thread Suspended erstelle und über die vorhandene Funktion starte?

Ich sehe das so:

Wann nutze ich was...?

Für alle Hintergrundoperationen die nur "moment Ausführungen" sind -> PPL & ThreadPool der lastet mir optimal mein System aus und ich brauche mich nicht darum zu kümmern. Ich laufe auch nicht Gefahr, dass ich (besonders auf mobilen Geräten) zu viel gleichzeitig versuche... Der Thread Pool macht das alles sehr schön für mich.

Was aber wenn ich einen Thread brauche oder in wenigen Nanosekunden reagiert? Da wäre es blöd, wenn ich ggf. erst warten muss das eine Task aus dem Pool frei wird, also eigenen Thread.

Das gleiche gilt auf für "longrunner" wenn ich 10 "longrunner" habe, will ich damit nicht die PPL belasten.

Oder

Wenn das erzeugen der Threadumgebung (Benötigte Objekte usw. lange dauert) dann nehme ich auch einen eigenen Thread.

Also Thread erzeugen der auf einen Event wartet...

Wenn ich den brauche -> Daten bereitstellen -> Signal -> in wenigen Nano/Pico Sekunden startet der Thread und legt sich nach der Arbeitet wieder schlafen.

Mavarik

[greenmile]

Also ich muss dazu sagen, dass ich mich inzwischen von FMX und Android abgewendet habe, daher fließt auch nicht mehr Zeit als nötig in dieses Projekt. Es hat sich leider gezeigt, dass sich Android-FMX nur sehr schwer kontrollieren lässt, gerade was Try/Except betrifft. Es gibt so viele Fehlermöglichkeiten. Jede Android Version verhält sich auf jedem der vielen Geräte wieder völlig anders. Grausam und macht keinen Spaß

Das Problem tritt nun nicht mehr auf. Was habe ich geändert? So genau weiß ich das leider nicht. Ich habe soviel Try/Except rausgeworfen wie möglich. Es hat sich einfach gezeigt, dass XE10 (Seattle) auf einigen Geräten arg durcheinander kommt, sobald eine Exception auftritt; ganz gleich, ob die abgefangen wird oder nicht. Wenn ich z.B. auf "webbrowser.url" im Ereignis "Webbrowser.OnFinishLoad" zugreifen möchte, dann geht das teilweise nicht und sorgt für eine Exception. Egal ob ich ein Try/Except drumrum bastel, auf einigen Geräten stürzt die App dann ab, andere werden einfach instabil und spielen verrückt. Ich muss aber auf die dann aktuelle URL zugreifen.

Irgendwann, als ich die x-te Try/Except rausgeworfen und einen Workaround dafür gebastelt habe, lief es plötzlich. So als wenn es einen "Wenn-mehr-als-10-Exceptions-dann-spiele-verrückt" Counter gibt. Getestet habe ich es jetzt mit 4-5 Geräten, teilweise im Emulator, teilweise mit echten Geräten. Das wirklich schlimme ist: Auf dem einen Gerät, selbe Android Version stürzte es ab, auf einem anderen nicht, dafür spielte es irgendwie verrückt. Da war für mich keine Logik drin. Bin froh dass es nun läuft und lasse die Finger von Änderungen. Zu groß die Gefahr, dass es auf einem Gerät von übermorgen wieder nicht klappt. Ich kann die App ja schlecht auf allen erdenklichen Geräten testen.

Mein Tipp für den Rest der Welt: So wenig Try/Except wie möglich.

[bra]

Wenn du XE8 einsetzt, hast du vermutlich folgendes Problem:
https://quality.embarcadero.com/browse/RSP-12634

Also ich würde dir dringend raten, auf die neueste Version von Delphi zu aktualisieren, wenn du für iOS/Android entwickeln möchtest.

[Mavarik]

Zitat von greenmile:

Mein Tipp für den Rest der Welt: So wenig Try/Except wie möglich.

Mein Tipp... Nimm nicht XE8 sondern 10.1

Gerade die Webbrowser-Komponente hat viele Bugfixes seit dem erhalten.

Abgesehen davon : Auf Android funktioniert diese immer noch nicht fehlerfrei!