Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Cross-Platform-Entwicklung (https://www.delphipraxis.net/91-cross-platform-entwicklung/)
-   -   Android: TThread (https://www.delphipraxis.net/190783-android-tthread.html)

greenmile 7. Nov 2016 14:03

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?

bra 7. Nov 2016 14:12

AW: Android: TThread
 
Zitat:

Zitat von greenmile (Beitrag 1352882)
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?

Warum sollte das unter Android nicht gehen? Machen wir auch so (TBaseThread ist von TThread abgeleitet):


Delphi-Quellcode:
constructor TBaseThread.Create(...);
begin
  inherited Create(true);
end;

greenmile 7. Nov 2016 14:22

AW: Android: TThread
 
Ja, dann läuft es (hatte ich bishger auch so), aber ...

Zitat:

Zitat von greenmile (Beitrag 1352882)
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?

Zum Beispiel gibt es für den Thread ein TIdHTttp, erstelle ich im Constructor mit DL := TIdHTTP.Create(nil);
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.

himitsu 7. Nov 2016 14:26

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. http://www.indyproject.org/support.en.aspx

greenmile 7. Nov 2016 14:29

AW: Android: TThread
 
Alles klar, ich checke das mal ... Danke.

bra 7. Nov 2016 14:32

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.

Mavarik 7. Nov 2016 15:43

AW: Android: TThread
 
Zitat:

Zitat von greenmile (Beitrag 1352882)
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?

Da stellen sich mir direkt mehrere Fragen...

Warum manuell einen Thread erzeugen? Dann sowas
Warum nicht die System.Threading?
Warum Indy und nicht die neuen Http Routinen?

Mavarik

Der schöne Günther 7. Nov 2016 15:50

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:
TidTcpClient
) benutzen die im Hauptthread erstellt wurden. Keinerlei Probleme.

Kannst du ein Minimalbeispiel erstellen?

SebastianZ 7. Nov 2016 16:04

AW: Android: TThread
 
Zitat:

Zitat von greenmile (Beitrag 1352882)
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 7. Nov 2016 17:36

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.

bra 8. Nov 2016 09:08

AW: Android: TThread
 
Zitat:

Zitat von jaenicke (Beitrag 1352917)
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 8. Nov 2016 10:24

AW: Android: TThread
 
Zitat:

Zitat von bra (Beitrag 1352955)
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 :coder:

greenmile 8. Nov 2016 11:26

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.

bra 8. Nov 2016 11:53

AW: Android: TThread
 
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 8. Nov 2016 11:55

AW: Android: TThread
 
Zitat:

Zitat von greenmile (Beitrag 1352976)
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!

greenmile 8. Nov 2016 12:17

AW: Android: TThread
 
Zitat:

Zitat von bra (Beitrag 1352977)
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.

Komme leider nicht die Seite, nimmt mein Login nicht. Kannst Du kurz schreiben was da drin steht?

greenmile 8. Nov 2016 12:20

AW: Android: TThread
 
Zitat:

Zitat von Mavarik (Beitrag 1352978)
Zitat:

Zitat von greenmile (Beitrag 1352976)
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!

Verschrieben, nutze XE 10 (Seattle) dafür. Berlin möchte ich nicht, da gibt es Probleme mit 2 Multiview's (eins links, eins rechts); geht damit nicht.

Mavarik 8. Nov 2016 12:32

AW: Android: TThread
 
Zitat:

Zitat von greenmile (Beitrag 1352982)
Verschrieben, nutze XE 10 (Seattle) dafür. Berlin möchte ich nicht, da gibt es Probleme mit 2 Multiview's (eins links, eins rechts); geht damit nicht.

Dann nimm den WebBrowser Source der 10.1 in 10 rein

greenmile 8. Nov 2016 12:38

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?

bra 8. Nov 2016 14:03

AW: Android: TThread
 
Zitat:

Zitat von greenmile (Beitrag 1352981)
Komme leider nicht die Seite, nimmt mein Login nicht. Kannst Du kurz schreiben was da drin steht?

Das war ein von mir gemeldeter Fehler, dass unter Android 6.0 die App bei einer beliebigen Exception (z.B. auch einem Assert) abstürzt:

Code:
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
Gefixt wurde das erst mit Seattle.

greenmile 8. Nov 2016 14:05

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.

greenmile 8. Nov 2016 14:16

AW: Android: TThread
 
Zitat:

Zitat von Mavarik (Beitrag 1352984)
Zitat:

Zitat von greenmile (Beitrag 1352982)
Verschrieben, nutze XE 10 (Seattle) dafür. Berlin möchte ich nicht, da gibt es Probleme mit 2 Multiview's (eins links, eins rechts); geht damit nicht.

Dann nimm den WebBrowser Source der 10.1 in 10 rein

Habe die DCU und PAS. Kann ich die einfach ins Source/FMX Verzeichnis kopieren?

bra 8. Nov 2016 14:42

AW: Android: TThread
 
Zitat:

Zitat von greenmile (Beitrag 1352992)
@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.

Ja, seit Seattle funktioniert zumindest unsere App unter Android 6.0 ohne Probleme.

bra 8. Nov 2016 14:45

AW: Android: TThread
 
Zitat:

Zitat von greenmile (Beitrag 1352993)
Zitat:

Zitat von Mavarik (Beitrag 1352984)
Zitat:

Zitat von greenmile (Beitrag 1352982)
Verschrieben, nutze XE 10 (Seattle) dafür. Berlin möchte ich nicht, da gibt es Probleme mit 2 Multiview's (eins links, eins rechts); geht damit nicht.

Dann nimm den WebBrowser Source der 10.1 in 10 rein

Habe die DCU und PAS. Kann ich die einfach ins Source/FMX Verzeichnis kopieren?

Die DCUs bringen dir i.d.R. nichts, die sind nicht kompatibel zwischen verschiedenen Delphi-Versionen. Du kannst du entsprechende PAS-Datei bei dir in dein Projekt einbinden und versuchen, ob das funktioniert. Ins Delphi-Source-Verzeichnis würde ich die aber nicht legen.


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