FMX + UI aktualisieren

[philipp.hofmann]

In meiner Anwendung läuft eine Uhr mit, daher habe ich eh einen Timer am Laufen und dieser updated bei Bedarf dann auch weitere Elemente der Anzeige. Wenn man so etwas wie diese Uhr nicht hat, mag der Timer ineffektiv sein. So ist es die einfachste und übersichtlichste Lösung.

[Rollo62]

Zitat:

Zitat von philipp.hofmann (Beitrag 1450480)

In meiner Anwendung läuft eine Uhr mit, daher habe ich eh einen Timer am Laufen und dieser updated bei Bedarf dann auch weitere Elemente der Anzeige. Wenn man so etwas wie diese Uhr nicht hat, mag der Timer ineffektiv sein. So ist es die einfachste und übersichtlichste Lösung.

Der Timer kann zu ungenau sein für eine Uhr.
Für eine Uhr würde ich immer die Systemzeit nehmen, z.B. mit Now();, und diese dann z.B. mit dem Timer (oder anders) aktualisiert anzeigen.

[Mavarik]

Zitat:

Zitat von Der schöne Günther (Beitrag 1450456)

Nein, wenn du ein Anzeige-Element hast das den Fortschritt aus 10 Threads anzeigt sitzt darauf ein Timer. Und den musst du auch nicht starten und stoppen, der kann ruhig immer laufen. Das kostet doch nichts.

Und wenn ich neben dem gesamt download den Fortschritt aller einzelnen Threads anzeigen möchte?
Dann ggf. noch eine Uhr, eine Statusanzeige die anzeigt, dass die Datenbank sich mit der Cloud synchronisiert.
Die Aktien chart, die upgedatet werden muss, uvm.
Und warum soll ich permanent einen Timer laufen lassen der immer wieder in einer Queue nachschaut, wenn es (wie mein Beispiel (#8) gezeigt habe) viel einfacher geht?
Ich möchte keinen Timer haben der immer läuft - schon gar nicht, wenn er permanent in einer Queue nachschauen muss die jedes mal hierfür ein locking durchführen muss.
Auf einem 5GHz PC mag das egal sein, aber sicherlich nicht in einer App die auf Batteriestrom läuft (z.B. Mobil-Device/Smartwatch).

Zitat:

Zitat von Rollo62 (Beitrag 1450483)

Der Timer kann zu ungenau sein für eine Uhr.
Für eine Uhr würde ich immer die Systemzeit nehmen, z.B. mit Now();, und diese dann z.B. mit dem Timer (oder anders) aktualisiert anzeigen.

Ich denke so hat er das gemeint.

[philipp.hofmann]

Ja, so war es mit dem Timer gemeint. Ich prüfe alle x Millisekunden, ob ich die Zeit, welche ich über NOW vergleiche, hochzählen muss. Und prüfe dann parallel, ob es sonst noch was in meiner Anwendung zu tun gibt (und das ist reichlich: UI-Updates, aktuell abgespieltes Musik/Video anpassen, …). Und drum herum passiert einiges in Threads.

Und meine Queue ist eine einfache TObjectList oder ein Dictionary (je nach Anwendungsfall), ich vermeide Locks und verhinderte auch, dass das gleiche Objekt mehrfach in der UI aktualisiert wird.
Geht sicherlich eleganter, aber funktioniert und ich vermeide synchronized und Locks, wo es nur geht.

[Mavarik]

Zitat:

Zitat von philipp.hofmann (Beitrag 1450514)

Und meine Queue ist eine einfache TObjectList oder ein Dictionary (je nach Anwendungsfall), ich vermeide Locks und verhinderte auch, dass das gleiche Objekt mehrfach in der UI aktualisiert wird.
Geht sicherlich eleganter, aber funktioniert und ich vermeide synchronized und Locks, wo es nur geht.

OK und wie? Wenn Du aus einem Thread in die Objectlist oder Dictionary schreibst musst Du verhindern, dass gleichzeitig Dein TimerEvent liest. Sicherlich ist lesen nicht so kritisch wie gleichzeitiges schreiben... Aber spätestens bei zwei threads must du locken.

[philipp.hofmann]

Sowohl beim Auslesen als auch beim Hinzufügen/Updaten von Einträgen gibt es ein try/catch, damit Fehler gefangen werden und in dem Fall bleibt dann mal ein Update der UI-Info aus. Das ist bei mir okay und spart Synchronisierungen.

[Mavarik]

Zitat:

Zitat von philipp.hofmann (Beitrag 1450525)

Sowohl beim Auslesen als auch beim Hinzufügen/Updaten von Einträgen gibt es ein try/catch, damit Fehler gefangen werden und in dem Fall bleibt dann mal ein Update der UI-Info aus. Das ist bei mir okay und spart Synchronisierungen.

Das ist kein Mittel um Threadsafe auf eine Liste oder Dictionary zuzugreifen!

[philipp.hofmann]

War wie gesagt ("das ist bei mir okay") eine bewusste Entscheidung. Mit ein paar Zeilen zusätzlichen Code würde ich es threadsafe bekommen, aber da sich die Anzeige eh alle 500ms ändert, kann ich auf einige Updates dort auch verzichten, dafür laufen die Videos in der Anzeige flüssiger. Da muss man aber die jeweilige Anwendung genauer kennen, um zu wissen, ob dies geht oder nicht.