JavaFX UI Thread block

[lam_tr]

Hallo zusammen,

irgendwie bekomme ich trotz UI Thread via Runnable, TimerTask, Task, Platform.runLater Varianten trotzdem UI Freeze, obwohl anwendungsmäßig nicht viel beansprucht wird.

Woran kann es liegen`?

Was wird gemacht? Ich habe eine ListView, sobald ich auf ein Item selektiere wird in der Datenbank ein select mit der Id gemacht und gibt eine Liste der Ergebnisse und stellt sie in eine zweite ListView dar. Die Oberfläche hängt trotzdem immer ca. 3-5 Sekunden auf.

Wenn ich den Task in ein Thread packe und per start mache, funktioniert das verzögert, aber dann müsste ich in den call methode noch Platform.runLater rein machen, sonst kann ich die zweite ListView nicht updaten.

hier ein kleiner Ausschnitt

        documentTable.selectionModel.selectedItemProperty.addListener [
            val selection = documentTable.selectionModel.selectedItem
            nameLabel.textProperty.bind(selection.nameProperty)
            createdLabel.textProperty.bind(Bindings.convert(selection.create_timestampProperty))
            statusLabel.textProperty.bind(Bindings.convert(selection.statusProperty))
            statusTextLabel.textProperty.bind(Bindings.convert(selection.statustextProperty))
            updateLabel.textProperty.bind(Bindings.convert(selection.update_timestampProperty))
            fileList.items.clear
           
            new Thread(new DocFileUpdaterTask(fileList, selection.id)).start
        ]

class DocFileUpdaterTask extends Task<Void> {
   
    ListView<DocumentFile> listView
   
    @Accessors int id
       
    new(ListView<DocumentFile> listView, int id) {
        this.listView = listView
        this.id=id
    }
   
    override protected call() throws Exception {
        Platform.runLater[
            listView.items.clear
            listView.items += ApplicationConfig.Instance.docFileDao.getDocFilesByDocId(id)
        ]
        null
    }
   
}

Bitte schaut nicht so streng auf den Code, das ist syntaktisch ein bisschen abweichend zu Java (Xtend). Es geht mir mehr oder weniger um den Inhalt wie ich das lösen kann, damit die UI beim Holen der Daten die UI nicht einfriert.

Datenmäßig sind noch nicht so viele in der Datenbank. Überschaubar ca. 20 Entries, verbraucht trotzdem 2-5 sekunden zum Laden.

Viele Grüße
lam

 

[mrBrown]

Das Abfragen aus der Datenbank sollte nicht in runLater passieren. Du kannst die Items vorher in einer anderen Liste speichern, und in runLater nur das Adden.

Ich würde da tendenziell noch weiter trennen, und mit extra Model und Listenern arbeiten, das runLater kann dann in die GUI-Klassen ausgelagert werden, und steht nicht mehr in deiner Logik

 

[lam_tr]

Hallo @mrBrown ,

ich habe das ursprünglich bei dem SelectionChange der Listview das holen der Items in eine Liste gepackt. Also in der Form

documentTable.selectionModel.selectedItemProperty.addListener [
val selection = documentTable.selectionModel.selectedItem
nameLabel.textProperty.bind(selection.nameProperty)
createdLabel.textProperty.bind(Bindings.convert(selection.create_timestampProperty))
statusLabel.textProperty.bind(Bindings.convert(selection.statusProperty))
statusTextLabel.textProperty.bind(Bindings.convert(selection.statustextProperty))
updateLabel.textProperty.bind(Bindings.convert(selection.update_timestampProperty))
fileList.items.clear

listView.items.clear
listView.items += ApplicationConfig.Instance.docFileDao.getDocFilesByDocId(id)
]

Aber die Oberfläche friert genauso ein. Ich bin mir da ziemlich sicher dass beim Abfragen der Daten das Einfrieren verursacht. Das komische ist nur dass die Abfrage nicht so lange brauchen soll, da sie noch so gut wie noch leer ist.

Vielen Dank für die Antwort.

lam

 

[mrBrown]

Weil das Holen immer noch im UI-Thread passiert.

Das ganze in einen Thread auszulagern macht schon Sinn - und der sollte die GUI benachrichtigen, *nachdem* die Daten aus der Datenbank bezogen worden sind.

 

[lam_tr]

@mrBrown
Aber diese Variante mit Auslagerung hat den selben Effekt?

documentTable.selectionModel.selectedItemProperty.addListener [
val selection = documentTable.selectionModel.selectedItem
nameLabel.textProperty.bind(selection.nameProperty)
createdLabel.textProperty.bind(Bindings.convert(selection.create_timestampProperty))
statusLabel.textProperty.bind(Bindings.convert(selection.statusProperty))
statusTextLabel.textProperty.bind(Bindings.convert(selection.statustextProperty))
updateLabel.textProperty.bind(Bindings.convert(selection.update_timestampProperty))
fileList.items.clear

val thread = new Thread(new DocFileUpdaterTask(fileList, selection.id)).run
]

 

[mrBrown]

In dem Codeteil wird doch gar nichts gesetzt?

 

[lam_tr]

Doch das Runnable wird als Parameter dem Thread übergeben und ausgeführt. In dem Runnable werden die Daten, siehe oben geholt und gesetzt.

 

[mrBrown]

Oben passiert das in runLater, und damit im UI-Thread

 

[lam_tr]

@mrBrown
Ok ich habe jetzt die Liste Initial komplett geladen und sobald etwas selektiert wird, wird die Liste gefiltert. Wirkt auf jeden Fall viel flüssiger.

Weiter hätte ich eine Frage wie man am Besten das macht. Wenn ich neue Elemente hinzufüge oder bestehende Lösche, mache ich dann ein Insert/Delete, soll dann die Entries komplett wieder in die Liste gelaen werden, oder ich mach ein add/remove auf die Liste?

 

[mrBrown]

Kommt drauf an, ist beides möglich. Wird die Datenbank denn extern verändert?

Wenn ja, führt kein Weg dran vorbei, daraus jedes Mal zu aktualisieren (außer man möchte dem Nutzer die Wahl lassen).
Wenn nein, kann man die Daten im Programm halten und diese nutzen, aber zusätzlich asynchron die Datenbank aktualisieren bzw abgleichen. UI hat dann keine Verzögerung durch die DB, aber Daten sind trotzdem aktuell.
UU bietet sich auch n einfacher Cache an.

Generell würde ich GUI und Model möglichst weit trennen, das ist in deinem Code vermutlich noch nicht genug. Dann sind die Umsetzungen für die UI gleichwertig, und du kannst auch einfach zum testen mal zwischen verschiedenen Varianten wechseln

 

[lam_tr]

Vielen Dank für diesen konstruktiven Kommentar. Das mit dem Asynchronen Aktualisierung gefällt mir.

Hast du Tipps für mich wie man GUI mit Model noch besser trennen kann? Weil ich denke dieses Prinzip habe ich auch noch nicht wirklich 100% verstanden.

Grüße
lam

 

[mrBrown]

Hast du Tipps für mich wie man GUI mit Model noch besser trennen kann? Weil ich denke dieses Prinzip habe ich auch noch nicht wirklich 100% verstanden.

Eher theoretische Tipps helfen dir dann vermutlich jetzt nicht wirklich weiter?

In dem Programm jetzt gehts um irgendwas mit Dokumenten?
Dann könnte man zB eine Klasse Documents haben, die den Zugriff auf Dokumente kapselt. Die enthält dann alle geladenen Dokumente und für diese gibt es einen getter und zB eine filter, gleichzeitig ist die Observable.
Die GUI kennt dann nur ein Objekt dieser Klasse und ist dort als Observer eingetragen, wenn sich was ändert holt sie sich jeweils die Dokumente und zeigt sie an. Wenn gesucht wird, ruft sie filter auf, das filtert im Hintergrund, und wenn die GUI dann wieder mitbekommt, das sich was geändert hat, zeigt sie es wieder an

 

[lam_tr]

Reicht mir da die Dao Klasse nicht aus um das zu kapseln?

 

[mrBrown]

Jein, ich würde DAO als Trennung von Model und DB nutzen.
Dao halte ich immer möglichst Simple, zB Synchron statt Asynchron und nur als Datenlieferant. Das das kommt erst in Model, welches die Logik enthält, und das Dao zum Beziehen der Daten nutzt.