GUI Ausgaben aus Threads

[Jw456]

@kneitzel i
Ist es in Desktop Java möglich Bildschirmausgaben im Thread zumachen?

Ich denke auf der Konsole geht das,
aber wie ist das in einer GUI geht das da auch oder muss ich da in den UI.

 

[kneitzel]

@kneitzel i
Ist es in Desktop Java möglich Bildschirmausgaben im Thread zumachen?

Ich denke auf der Konsole geht das,
aber wie ist das in einer GUI geht das da auch oder muss ich da in den UI.

Das kommt ggf, auf die Sichtweise an. Ich würde sagen: Nein. Die UI Elemente in Swing und FX sind nicht threadsicher und sollten daher immer nur aus dem entsprechenden UI Thread heraus angepasst werden. Daher gibt es in den Frameworks entsprechende Hilfsmittel, Dinge in den UI Thread zu verlagern (Platform.runLater in FX und SwingUtilities.invokeLater in Swing).

Damit wird die eigentliche Ausgabe (also die Anpassung der UI) immer im UI Thread durchgeführt.

 

[Jw456]

OK danke erstmal, dachte ich mir auch so, das die meisten GUIs SingleThread sind. Zu mindestens die Ausgabe dann in UI erfolgen muss, ist in Android ja auch so.

Die Frage viel mir nur bei der Gelegenheit ein danke für die Antwort.
Gerne wieder zurück zum Thread Thema.

 

[kneitzel]

Vielleicht noch zum Thema "Sichtweise" und wo man das ggf. anders sehen könnte: Es gibt in der Regel bei den meisten UI Frameworks eine Klasse, die dann Worker, BackgroundWorker, ... heißt und die sowas mit abdeckt. Ein Beispiel ist da z.B. SwingWorker bei Swing - die Klasse bietet Möglichkeiten, daten an die UI zu geben (publish) und Daten zur weiteren Verarbeitung von der UI zu bekommen (process).
Damit sieht man von den anderen Threads nicht wirklich etwas, aber im Hintergrund findet das natürlich alles statt. Jetzt ist die Frage, ob der Aufruf von publish(T...) aus dem Workerthread schon als Ausgabe angesehen wird. Dann wäre das eine Ausgabe aus dem anderen Thread. Aber da intern in den EDT gewechselt wird, ist wieder die Ausgabe / Veränderung der Oberfläche im EDT.

 

[Jw456]

Ja das ist im Grunde das Handler Prinzip. Wollte da jetzt nicht in die tiefe gehen wenn ich das brauche mache ich einen Thread auf. Möchte den TE hier nicht zu sehr belasten.

 

[mrBrown]

Handler Prinzip

Was soll das Handler Prinzip sein?

 

[Jw456]

In Android gibt es dafür Handler die im UI Laufen. An denen auch Daten aus den Thread Übergeben werden können , während er weiter läuft, damit man sie zb auf dem auf dem Bildschirm anzeigen lassen kann.

Dachte so etwas gäbe bei Desktop Java auch.

 

[mrBrown]

In eigentlich allen Desktop-Frameworks übergibt man ein Runnable (oder was analoges) an den GUI-Thread, und der führt es dann aus. Unter Android wird das ähnlich laufen.

 

[Jw456]

Dann schaue runOnUIThread das ist ein Runnabell .

für das Thema reicht mir die Aussage von @kneitzel

 

[mrBrown]

Dann schaue runOnUIThread das ist ein Runnabell .

Ja, das ist ja auch genau das, was ich sagte: "man [übergibt] ein Runnable (oder was analoges) an den GUI-Thread, und der führt es dann aus" 🙂

Ich war nur etwas irritiert von der Benennung als "Handler Prinzip" (Event-Handler sind im GUI-Kontext ja auch völlig üblich, aber etwas völlig anderes).

 

[Jw456]

Noch mal Handler gibt es auch und die laufen etwas anders. änlich dem schon gesagten.

Wenn es für dich besser ist Event-Handler

 

[mrBrown]

Noch mal Handler gibt es auch und die laufen etwas anders.

Das es generell Handler gibt weiß ich, aber die üblichen sind halt wie du selbst sagst:

Event-Handler

Was allerdings nichts mir Threads zu tun hat, worum es ja eigentlich ging.

 

[mihe7]

@mrBrown er meint vermutlich https://developer.android.com/reference/android/os/Handler

 

[Jw456]

Was allerdings nichts mir Threads zu tun hat, worum es ja eigentlich ging.

@mrBrown Das ein Handler kein Thread ist, ist klar. Es ging um das Thema ob und wie es möglich ist in einer GUI in einem Thread direkt ohne Umwege Runnabel, Handler ... eine Bildschirm Ausgabe zumachen.

Irgendwie kommst du etwas vom Hauptthema ab.

Für mich ist das Thema beendet.