![]() |
Android: TThread
Irgendwie komme ich nicht so recht weiter. Ich benötige unter Android einige Threads. Die Beispiele, die ich auf Anhieb finde, sind entweder für XE5 oder enthalten nur 1-2 zeilen Code innerhalb des Threads. Ich erstelle also einen TThread, Vorfahre ist TThread und hier schon die erste Frage: Beim Inherited möchte er ein "CreateSuspended", das ist ja unter Android nicht erlaubt. Nutze ich die falsche Elternklasse? Ist TThread falsch?
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? |
AW: Android: TThread
Zitat:
Delphi-Quellcode:
constructor TBaseThread.Create(...);
begin inherited Create(true); end; |
AW: Android: TThread
Ja, dann läuft es (hatte ich bishger auch so), aber ...
Zitat:
Im .Execute kann ich aber über DL.Get nicht mehr drauf zugreifen, so als wenn die Variable ins Nirvana zeigt. DL ist natürlich im Thread Code declariert. |
AW: Android: TThread
Es gibt Komponenten, die sind threadafine.
Der Constructor läuft im erstellenden Thread und das Execute dann in einem Eigenen. Threadafine Komponenten können nur in dem Thread verwendet werden, wo sie erstellt wurden. Man muß sie dann also im Execute erstellen und feigeben. Ich vermute einfach mal, dass das bei den Indy zutrifft. Und dann gibt es Komponenten, die sind nicht nur nicht threadsave, sondern sie dürfen nur im Hauptthred verwendet werden. Ich hoffe mal dass das hier nicht auf die Indy zutrifft. Ansonsten wird sich bestimmt bald ein Indy-Profi finden (hier tummeln sich paar rum), der sich hier melden wird. Wenn nicht, dann bleibt immernoch der direkte Weg zur Hilfe. ![]() |
AW: Android: TThread
Alles klar, ich checke das mal ... Danke.
|
AW: Android: TThread
Wir haben in unserer App das Indy auch im Thread laufen und das funktioniert ohne Probleme. Wir haben es auf einem DataModule und erstellen das jeweils im Execute des Threads.
|
AW: Android: TThread
Zitat:
Warum manuell einen Thread erzeugen? ![]() Warum nicht die System.Threading? Warum Indy und nicht die neuen Http Routinen? Mavarik |
AW: Android: TThread
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 (
Delphi-Quellcode:
) benutzen die im Hauptthread erstellt wurden. Keinerlei Probleme.
TidTcpClient
Kannst du ein Minimalbeispiel erstellen? |
AW: Android: TThread
Zitat:
![]() 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! |
AW: Android: TThread
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. |
AW: Android: TThread
Zitat:
|
AW: Android: TThread
Zitat:
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 :coder: |
AW: Android: TThread
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. |
AW: Android: TThread
Wenn du XE8 einsetzt, hast du vermutlich folgendes Problem:
![]() Also ich würde dir dringend raten, auf die neueste Version von Delphi zu aktualisieren, wenn du für iOS/Android entwickeln möchtest. |
AW: Android: TThread
Zitat:
Gerade die Webbrowser-Komponente hat viele Bugfixes seit dem erhalten. Abgesehen davon : Auf Android funktioniert diese immer noch nicht fehlerfrei! |
AW: Android: TThread
Zitat:
|
AW: Android: TThread
Zitat:
|
AW: Android: TThread
Zitat:
|
AW: Android: TThread
Habe Berlin gerade nicht zur Hand. Hast Du zufällig beide installiert und kannst mal schauen, ob es da nennenswerte Unterschiede gibt?
|
AW: Android: TThread
Zitat:
Code:
Gefixt wurde das erst mit Seattle.
An App on Android 6.0 (Nexus 7) crashes instantly on any exception:
10-14 18:35:09.642 602 2824 I WindowState: WIN DEATH: Window {8808908 u0 com.embarcadero.Test03/com.embarcadero.firemonkey.FMXNativeActivity} 10-14 18:35:09.690 206 206 I Zygote : Process 18663 exited cleanly (231) 10-14 18:35:09.739 602 652 I ActivityManager: Process com.embarcadero.Test03 (pid 18663) has died 10-14 18:35:09.740 602 652 W ActivityManager: Force removing ActivityRecord {6114c33 u0com.embarcadero.Test03/com.embarcadero.firemonkey.FMXNativeActivity t1150} : app died, no saved state 10-14 18:35:09.860 602 652 W InputMethodManagerService: Got RemoteException sending setActive(false) notification to pid 18663 uid 10535 |
AW: Android: TThread
@bra
Weißt Du, ob der Fehler in Seattle gefixt wurde? Ich habe leider in Berlin einige viele Probleme, weshalb ich nicht einfach so springen kann. Da funktioniert einiges nicht mehr oder nicht mehr so, wie es vorher funktioniert hat. |
AW: Android: TThread
Zitat:
|
AW: Android: TThread
Zitat:
|
AW: Android: TThread
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:33 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz