Android: MessageDlg Logik

[Sir Rufo]

Es gibt zwei Aussagen, wo ich reflexartig einen Würgereiz bekomme:

• Das haben wir schon immer so gemacht
• Das haben wir noch nie gemacht

Was möchte man mir damit mitteilen?

Dass man eine Lobotomie hinter sich hat und darum nicht mehr denken kann?

Und etwas an das man sich gewöhnt hat, muss nicht zwangsläufig richtig sein. Wenn man sich den Code anschaut, der dieses blockierende ShowModal verbricht (anders kann man es nicht beschreiben) und dieses mit dem Konzept einer GUI-Anwendung abgleicht, der versteht dann auch, dass dieses neue Verhalten nun endlich dem entspricht, was das GUI-Konzept vorgegeben hat.

Manchmal schmerzt die Erkenntnis, dass man sich jahrelang auf dem Holzweg befunden hat. Mir egal, ich schlage mir einmal beherzt vor die Stirn, schreie einmal laut "Mann, logisch!" und ab dann übernehme ich das.

[Daniel]

Zitat:

Zitat von eddie11 (Beitrag 1289724)

Wer für Desktop programmiert, der ist gewöhnt, dass "modal" bedeutet, dass die Anwendung erst weiterläuft, wenn das modale Fenster geschlossen wurde

Das ist richtig. Und auf den mobilen Geräten gibt es andere Spielregeln, mit denen man konfrontiert wird. Das ist am Anfang erstmal ein Kulturschock, ohne Zweifel.
Und manchmal muss man dann komplett umdenken - diese Dialoge und der komplett geänderte Ablauf sind ein schönes Beispiel dafür. Die Ausgangsfrage war, die andere diese Thematik behandeln und Ruf hat - wenn auch ein wenig ruppig - einen schönen Weg dafür aufgezeigt, der insbesondere auch ohne Exit auskommt.

[Sir Rufo]

@Daniel

Ist es nicht eher so, dass dieses Konzept schon vom ersten Tag der Programmierung an so hätte laufen müssen? Nein auch ich habe diese "blockierenden" Dialoge eingesetzt, aber war es deswegen "richtig"?

[mkinzler]

Ich würde modale Dialoge nuicht per se als falsch ansehen aber für mobilen Anwendungen sind sie sicherlich weniger geeignet.

[eddie11]

also:

- das war schon immer so
- das war noch nie so

erzeugt bei mir auch einen Würgereiz dazu noch

- da könnt' ja jeder kommen

:):)

Die Lösung von SirRufo scheint ja wirklich besser..

Ich habe halt immer ein Problem damit, wenn ein Thread, in dem eine bestimmte Frage gestellt wurde ("MessageDlg Logik") abgleitet in "wer programmieren kann ist besser dran" oder so. Und dann lass' ich mich eben nicht gerne anmaulen... :oops::oops:

[Sir Rufo]

Zitat:

Zitat von mkinzler (Beitrag 1289738)

Ich würde modale Dialoge nuicht per se als falsch ansehen aber für mobilen Anwendungen sind sie sicherlich weniger geeignet.

Ähm, die Dialoge sind doch immer noch modal ... die blockieren nur nicht mehr.

[Daniel]

@Rufo:
Ich stimme mir Dir überein, dass die jetzige Lösung sauberer ist. Zu der Aussage, dass die alte tatsächlich falsch war, würde ich mich nicht hinreißen lassen.
Was wollten wir denn - Beispiel MessageDialog() - erreichen? Dem Anwender eine Antwort abringen und dann entsprechend fortfahren. Das bisherige, blockierende, Verhalten kam mir als Entwickler schon sehr weit entgegen. Zumal es in der damals einzigen Zielplattform - Windows - ja auch in dessen API manifestiert war und somit kein Fremdkörper war.

[Sir Rufo]

@Daniel

Den Begriff falsch habe ich (hoffentlich) in diesem Zusammenhang auch bewusst vermieden, denn es hat ja funktioniert. Und es war den Entwicklern von diesem ShowModal ja auch bewusst, denn dort wurde ja ganz bewusst mit

Delphi-Quellcode:

Application.ProcessMessages

gearbeitet und das wo jeder weiß, dass das Vorkommen von

Delphi-Quellcode:

Application.ProcessMessages

ein Design-Fehler ist.

Es wird funktionieren aber eben nicht richtig sein, aber eben auch nicht falsch.

Es ist nicht tragisch

Delphi-Quellcode:

Application.ProcessMessages

zu verwenden, wenn man sich des Workaround-Charakters dieses Ansatzes bewusst ist, der dann aus Zeitgründen oder aus (noch) fehlendem Know-How (wie denn sonst) bewusst gewählt wird. Wichtig ist die Erkenntnis, man ist dort eben noch nicht fertig und es auf die ToDo-Liste schreibt.

[greenmile]

Also sorry, modale Messageboxen machen in meinen Augen fast immer Sinn, weil man zu 99% auf etwas wartet, was im Anschluss gemacht wird, ansonsten habe ich ja wieder eine weitere Prozedure, die ich ohne diesen Quatsch nicht hätte. In XE6 (oder XE5?) ging es doch auch. Es jetzt aber so kompliziert zu machen finde ich ekelig. Und fast jeder wird sich eine Funktion wie diese zusammenpfuschen, was ja eigentlich nicht im Sinne des Erfinders ist.

@Sir: Nichts für ungut, aber man kann sich alles neue auch einfach schön reden. Ist ja wie beim Mac/iPhone: Das macht Sinn, der Hersteller hat sich schon was dabei gedacht, worauf Du halt nicht kommst. Das hat nichts mit "War immer so" zu tun, sondern "Ich möchte eine Aufgabe möglichst schnell, einfach und effektiv erledigen."

Code:

var MsgDlgResult: Integer;

function MessageDlg(const Msg: string; DlgType: TMsgDlgType;
  Buttons: TMsgDlgButtons; HelpCtx: Longint): Integer;
begin
  MsgDlgResult := -1;
  FMX.Dialogs.MessageDlg(Msg, DlgType, Buttons, HelpCtx,
            procedure(const AResult: TModalResult)
            begin
              MsgDlgResult:= AResult;
            end
          );
  while MsgDlgResult<0 do Delay(10);
  Result := MsgDlgResult;
end;

[Olli73]

Zitat:

Zitat von greenmile (Beitrag 1289778)

In XE6 (oder XE5?) ging es doch auch.

Ja, aber:

Wenn du während des Anzeigens eines solchen Dialoges in eine andere App und zurück gewechselt bist, dann war Schluss mit Lustig...