Best-practice für Live Binding / Threads / Webservice

[swestner]

Hallo,

wir haben einen in Delphi geschriebenen Webservice, der Daten aus einer Datenbank "serviert".

Clients dafür laufen als App unter iOS, Android, Windows und Mac.

Wir haben in der Vergangenheit schon mehrere Apps entwickelt, diese haben aber immer nach dem prinzip funktioniert: alles im Hauptthread, Daten holen, manuell in die GUI einfüllen.

Die neue, besagte App soll es nun besser machen, also Anfragen an den Webservice in einem Thread und Anzeigen der Daten via Live Binding.

Im Prinzip funktioniert das auch nur kriegen wir teilweise sporadisch ganz komische Schutzverletzungen (nicht aus dem Delphi Code sondern z. B. irgendwo aus iOS) und dann passieren auch manchmal so Dinge wie, daß im Listview das Live Binding nur 20 der 50 datensätze aus dem Dataset anzeigt, usw.

Wir sind der Meinung, daß wir die Threads mit Synchronize usw. ausreichend synchronisiert haben. Wir nutzen Threads regelmäßig und haben da Erfahrung.

Aber in Verbidnung mit dem Live Binding scheint das hinten und vorne nicht zu funktionieren.

Frage:
Gibt es irgendwo Artikel oder Vorträge oder Frameworks mit Best Practices wie auf mobilen System Daten von einem Webservice asynchron konsumiert und mittels Live Binding präsentiert werden?

Grüße

Stefan

[Rollo62]

Ich nutze manchmal zusätzlich lokale Variablen, die dann mit TThread.Queue das UI-Schreiben weiter entkoppeln.

[swestner]

Das nutzen wir auch: Threads in Metoden zum Laden und dann ein Thread.Queue für die GUI usw. aber genau das funktioniert halt alles nicht vernünftig unter iOS.

[Rollo62]

Ansonsten Alles rigoros entkoppeln und in kleinere Module auslagern.
Größere monolitische Systeme neigen zu solchen Fehlern.

Ansonsten kann es natürlich auch ein Speicherzugriffsfehler sein.

[swestner]

Alles gemacht: Tranbsportschicht, GUI-Schicht, Businesslogik, Bussystem dazwischen, kein Durchgriff der Module untereinander, Patterns sinnvoll verwendet usw.

Wir haben die App frisch aufgesetzt unter es ist quasi ein Lehrstück sauberster Softwareentwicklung - aber es funktioniert halt nicht (zuverlässig).

Daher nochmals die Frage nach Frameworks, Best-Practices, usw....

[Rollo62]

Dann ist halt irgendwo doch der Wurm drin.
Ich versuche in solchen Fällen alles Schritt für Schritt zu de-komponieren (schreckliches Wort),
und dann separat zu Testen.

Mit etwas Glück findet man da dann die Ursache.

Bei mir hat auch schon anfangs mal ab und zu das einfache Aufräumen und Vertauschen von uses Einträgen geholfen.
Ich hatte mal den Verdacht das je nachdem wo die Units gelinkt werden evtl. Sprünge > 16 MB glaube ich entstehen, was zu solchen Fehlern (unter Android war das) führen könnte.

[Rollo62]

Was ich auch nutze ist die Vielfalt der OS.
Denn ich kann mit einem Source auf allen Plattformen Testen.
D.h. wenn ich mal ein Problem habe debugge ich auch mal zwischendurch auf Android oder Macos oder Windows.
So hab ich schon manche versteckte Fehler gefunden, die sich auf IOS nur als crash äussern,
aber auf anderen Systemen durchaus einen Stackframe zur Auswertung anbieten.
Das ist natürlich bebrenzt wenn es um mobile Hardware geht.

[Rollo62]

Und noch einen:

Ich nutze oft delayed oder lazy Initialisierungen, so das ein OS wie iOS erstmal hochfährt, und dann erst ein Location-Service o.ä. angefasst wird.
Das erleichtert die Fehlersuche ebenfalls, weil ich da schon einigermaßen debuggen kann.