Flutter - Finance Overview (Daten)
Heute geht es um das Datenmodell der App im ersten Preview, das Design der API und die Herausforderungen dabei.
Inhaltsverzeichnis
Bevor wir die App erstellen, haben wir uns einen Funktionsumfang überlegt, was wir an Bildern und Aktionen eigentlich benötigen. Nach der Definition der Bilder haben wir das Datenmodell dazu konzipiert, um die grobe Datenhaltung durchführen zu können. In diesem Artikel wollen wir etwas näher auf die Überlegungen eingehen.
Offline First
Unsere bisherigen Projekte haben wir mit Online Verbindung durchgeführt, dass heißt die Daten werden immer Online auf unserem Server gesichert und von dort abgerufen. Dies hat den Charme, dass es nur eine Wahrheit mit den Daten gibt und eine nachträgliche Synchronisation nicht mehr nötig ist. DIes hat aber auch zur Folge, das es immer eine Online Verbindung benötigt, um mit der App arbeiten zu können.
In diesem Projekt möchten wir zum ersten Mal eine Offline-First Strategie fahren und dem Anwender die Möglichkeit geben, ausschließlich Offline zu arbeiten. Weiterhin kann auch Online zugegriffen werden, wenn dies gewünscht ist. Sollte mal keine Verbindung ins Internet verfügbar sein, dann sollen die Daten nachsynchronisiert werden und erst einmal nur Offline gesichert werden. Damit soll sichergestellt werden, dass die App auch jederzeit Offline funktioniert.
Dazu benötigen wir also zwei Dinge:
- Lokale Datenbank zur Sicherungen der Datensätze für die Offline First Strategie
- Web API zur Sicherung der Daten im Internet
Hinweis: Wenn der Anwender nicht nur Offline arbeiten möchte, dann werden die Daten online gesichert, damit auch geräteübergreifend gearbeitet werden kann. Es soll wieder mindestens eine App und eine Webversion geben.
Datenmodell
Letztes Mal hatten wir über die einzelnen Bilder und Verbindungen gesprochen, dazu benötigen wir noch das entsprechende Datenmodell mit den Entitäten und Feldern. Dazu definieren wir das Portfolio als Wurzelentität, wo auch die entsprechenden Berechtigungen des Users liegen. Dadurch haben wir die Freiheit später noch zwei weitere Features zu implementieren (Mehrere Portfolios pro User, Teilen eines Portfolios mit anderen Usern). Aktuell würde das Datenmodell entsprechend so aussehen:
Die entsprechenden Bereiche der App sind farblich hervorgehoben, sodass sie besser unterschieden werden können. Die Felder in den einzelnen Entitäten wurden zum Großteil festgelegt, aber könbnen sich im Laufe des Projektes noch erweitern oder leicht verändern.
API Designer
Dies ist die grafische Version des Datenmodells das wir zuvor in unserem "API Designer" definiert haben. Hierbei handelt es sich um ein Entwicklungstool auf Basis unseres SwH-Webframeworks, das wir entwickelt haben. Dabei geht es um die Erstellung und Pflege von Web APIs die mit der Webseite und der Datenbank verknüpft sind.
Im ersten Schritt werden über den Designer die API Grundeinstellungen festgelegt und im Anschluss die Entitäten, welche 1:1 die Tabellen wiederspiegeln.
Als zweiter Schritt werden die Felder und Datentypen in der Entität implementiert, um später dann die Datenzu halten. Die Datentypen werden entsprechend SQL angelegt. Wenn wir die Daten später in Flutter verarbeiten, dann werden diese Datentypen in Flutter Datentypen umgewandelt.
Wenn die Definition der API abgeschlossen ist, wird aus dem ganzen Modell eine Konfiguration (im JSON Format) erzeugt, die das Framework nutzt, um die Tabellen anzulegen und den Traffic auf die korrekten Entitäten zu lenken. Die vorher definierte Entität sind nun wie folgt aus:
Im Modell sind bereits die Beziehungen der Tabellen untereinander definiert, sodass spätere Prüfungen und die Anlage neuer Datensätze auf bestehenden Entitäten basiert. Die Verwaltung der Schlüssel erfolgt ebenfalls über das Framework, um die Datenhaltung so flexibel wie möglich zu halten.
Synchronisierung
Der komplexeste Teil der Datenhaltung (Online vs Offline) wird die Datensynchronisierung sein, wenn du auf einem Offline-Gerät arbeitest. In der aktuellen Phase wird diese Logik noch nicht implementiert, sondern erst einmal die grobe App Logik die benötigt wird.
Wie du dir sicher vorstellen kannst, gibt es dabei zahlreiche Punkte zu beachten, wenn es um die Synchronisation von Daten geht.
- Läuft die App im Synchronisationsmodus
- Abgleich der Datensätze Online und Offline
- Führendes System bei Änderungen
- Möglichkeit zur Nachsynchronisierung
Fazit
Das Datenmodell bestimmt die Möglichkeiten die wir später mit der App haben, legt uns aber nicht zu 100% fest, da wir immer wieder Anpassungen vornehmen können. Mit dem bereits definierten Datenmodell haben wir aber eine gute Vorlage zur Implementierung der Bilder und Logiken. Ebenfalls wird die Synchronisierung der Daten noch einmal eine große Rolle spielen, diese werden wir in einem späteren Artikel zeigen.
