Android & Application.Run

[Mavarik]

Ich kann mich daran erinnern, das Threading Model von FMX für Android hat sich mal geändert. Aber ich kann mich nicht erinnern wann... :stupid:

Normalerweise ist ein Application.Run ein Methodenaufruf, der erst dann zurück kommt, wenn die App/Anwendung geschlossen wird...

Nicht so auf Android. :warn:

Beispiel:

Delphi-Quellcode:

program Project94;

uses
  System.StartUpCopy,
  System.Messaging,
  FMX.Forms,
  Unit70 in 'Unit70.pas' {Form70};

{$R *.res}

var
  S         : String;
  IsSet : boolean;

begin
  Application.Initialize;

  S      := 'Vorher';
  IsSet  := false;
  Form70 := NIL;

  Application.CreateForm(TForm70, Form70);

  TMessageManager.DefaultManager.SubscribeToMessage( TFormsCreatedMessage,
    procedure( const Sender: TObject; const M: TMessage )
      begin
        if Assigned( Form70 ) and not IsSet then
          begin
            Form70.Label1.Text := S;
            IsSet              := True;
          end;
      end );

  Application.Run;

  S := 'Nachher';
end.

Was steht auf dem Form? Richtig... "Nachher".

Wegen Java, wollen meine "alten" XE-Versionen nicht und ich habe leider keine VM mehr...

Hat jemand einen Idee?

Grüsse Mavarik :coder:

[jaenicke]

Wo liegt dabei denn das Problem? Es ist ja (wie du sicherlich selbst weißt) normal, dass unter Android Methoden auch zurückkehren bevor sie abgearbeitet sind, z.B. auch bei der Anzeige von Dialogen.

Beim Beenden der App etwas tun geht an der Stelle dann nicht, aber geht es dir darum?

[Mavarik]

Zitat:

Zitat von jaenicke (Beitrag 1520189)

Beim Beenden der App etwas tun geht an der Stelle dann nicht, aber geht es dir darum?

Ich hatte eine "alten" Multiplattform App die nach dem Application.Run eine Message zu einen TCP-Server sendet und nicht einfach "weg geht". Klar kann man das auch anders lösen...

Aber ich habe einen ganzen Tag einen einer Exception gesucht...

Da der Debugger aber (11.3) erst dann connected wird, wenn Application.Run zurück gekommen ist (Hatte ich leider auch nicht "mehr" auf dem Schirm - mache wenn es geht einen großen Bogen um Android) kann man keinen Source in Unit Initializations und nix debuggen, bevor das nicht passiert ist.

Mavarik

[jaenicke]

Zitat:

Zitat von Mavarik (Beitrag 1520190)

Da der Debugger aber (11.3) erst dann connected wird, wenn Application.Run zurück gekommen ist (Hatte ich leider auch nicht "mehr" auf dem Schirm - mache wenn es geht einen großen Bogen um Android) kann man keinen Source in Unit Initializations und nix debuggen, bevor das nicht passiert ist.

Mit der guten alten while true Schleife schon. Wenn die ganz am Anfang nach dem begin steht, kannst du alles debuggen, auch unter Android. (Gut, mit Delphi 11 habe ich das nicht getestet, aber ich gehe davon aus, dass das auch dort klappt.)

[Mavarik]

Zitat:

Zitat von jaenicke (Beitrag 1520193)

Mit der guten alten while true Schleife schon. Wenn die ganz am Anfang nach dem begin steht, kannst du alles debuggen, auch unter Android.

emm - What?

Wenn Du in meinem Beispiel einen Breakpoint auf

Delphi-Quellcode:

S := 'Vorher'

setzt, hält der Debugger da nie an.

Und Du hast dafür einen Workaround?

[jaenicke]

Zitat:

Zitat von Mavarik (Beitrag 1520197)

Wenn Du in meinem Beispiel einen Breakpoint auf

Delphi-Quellcode:

S := 'Vorher'

setzt, hält der Debugger da nie an.

Und Du hast dafür einen Workaround?

Ja, das habe ich ja geschrieben. :)

Das klappt genauso wie das Debuggen des Startens eines Dienstes unter Windows:

Anhang 55921

Sprich du packst nach dem begin im Projekt eine Schleife rein. Unter Windows kann das einfach

Delphi-Quellcode:

while not IsDebuggerPresent do

sein. Unter Android muss man das etwas abwandeln. Dort prüft man auf eine Variable. Setzt man dort einen Haltepunkt, kommt man trotzdem nicht an.
ABER: Wenn du nach dem Start an der Stelle bist, sprich den Startbildschirm der App siehst und es dort hängt, dann drückst du einfach auf Anhalten. Dann landest du an der Schleife und kannst dort die Variable mit Strg + F7 ändern. Wenn du dann fortsetzt, landest du bei den weiteren Haltepunkten ganz normal.

[Rollo62]

Zitat:

Zitat von Mavarik (Beitrag 1520190)

Ich hatte eine "alten" Multiplattform App die nach dem Application.Run eine Message zu einen TCP-Server sendet und nicht einfach "weg geht". Klar kann man das auch anders lösen...

Wäre nicht WillTerminate oder anderen Events die richtige Alternative ?
Habe ich nie gebraucht, aber ich meine, dass gestartete Threads noch bis zum Ende weiterlaufen, also ideal um eine Message zu TCP abzusetzen.
Bin mir aber jetzt auch nicht 100*% sicher, ob die bei Android nicht doch hart gekillt werden.

[himitsu]

Zitat:

Zitat von Rollo62 (Beitrag 1520253)

Bin mir aber jetzt auch nicht 100*% sicher, ob die bei Android nicht doch hart gekillt werden.

Im Windows laufen Threads auch ewig weiter, aber der Hauptthread (die böse RTL) schießt bei seinem Ende den ganzen Prozess ab.
Im Prinzip sind für Windows alle Threads gleich, also egal ob Hauptthread oder ein Anderer.

Ja, man könnte vielleich davon ausgehen, dass Windows den Thread, welchen es selber für die Programminitialisierung gestartet hat, eventuell anders behandelt ... aber scheinbar nö.

Hmmmm ... ob nun Unixoide (Linux oder Android) das anders handhaben ... gute Frage, aber warum sollten die denn einen der Threads (Hauptthread) bevorzugt behandeln? :stupid: