Android: TThread

[bra]

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]

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]

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:

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]

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]

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]

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]

Habe Berlin gerade nicht zur Hand. Hast Du zufällig beide installiert und kannst mal schauen, ob es da nennenswerte Unterschiede gibt?

[bra]

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.