Flutter - Finance Overview (Framework)
Bevor wir mit der eigentlichen Entwicklung der App beginnen, arbeiten wir zuerst an der zweiten Version des SwH-Frameworks, um eine Wiederverwendbare Grundlage zu schaffen.
Inhaltsverzeichnis
Nachdem die Planung der Seiten und Daten abgeschlossen ist, beginnen wir im ersten Schritt mit der Überarbeitung des SwH-Connection-Frameworks. Diese Überarbeitung soll für ein frisches Design sorgen, aber auch fehlende Features integrieren wie Offline Support und einfacheres Entitäts-Handling. Weiterhin stellen wir die Entwicklung von Provider auf GetX um.
Framework
Die erste Version des Connection Frameworks hatten wird bereits für die Entwicklung des Resource Monitor und den App Planner verwendet. Dabei hatte das Framework verschiedene Funktionen und Datenverwaltungen zur Verfügung gestellt. Hier ein kurzer Überblick über die bisherigen Funktionen:
- Verwaltung der Zugriffe auf Web-APIs für App, sowie Web (Self-Signed-Certificates)
- Einbettung von Login und Registrierung zur Wiederverwendung
- User Verwaltungsmodell
- Funktionen zur Wiederverwendung
- App-Konfiguration
- Verschiedene Formatter
Das Framework sollte wiederverwendbare Funktionen zur Verfügung stellen, die man für jede App benötigen würde und eine saubere Verbindung zum Swh-Framework im Web herstellen. Da wir Self-Signed-Certificates für die HTTPS Verbindung nutzen, können wir auch nicht den Flutter Standard zum Zugriff auf den Server nutzen, sondern benötigen eine eigene Implementierung zur Verbindungsherstellung.
Version 2
Mit der neuesten Version des Frameworks wollen wir einige Implementierungen komplett überarbeiten, die uns aus der letzten Version als Nachteil aufgefallen sind. Deshalb hier noch einmal kurz die Umstellungen und neuen Features:
- Umstellung auf GetX
- Offline-First bei CRUD Requests
- Unit Tests
Eine große Umstellung ist dabei die Implementierung des neuen Statemanagement Ansatzes über GetX, da uns das Provider Paket zuviel Boilerplate Code erzeugt hat und an vielen Stellen keine sauberen Schnittstellen möglich waren. GetX liefert uns dabei eine bessere Architektur der App und eine einfachere Wiederverwendbarkeit.
Als nächsten Punkt wollten wir die Offline-First Strategie umsetzen, dazu mussten die CRUD Requests gegen das Framework noch einmal neu verschalt werden, um für die richtigen Einstellungen und Zielplattform auch die korrekte Aufrufreihenfolge abzustimmen.
Bisher hatten wir im Framework keine Unit Tests, die alle Funktionen und Bestandteile automatisch auf Herz und Nieren getestet haben. Um die Stabilität des Frameworks gewährleisten zu können, haben wir uns in diesem Schritt auch noch dazu entschieden, nach dem Umbau der Schnittstellen und der Herstellung der Testbarkeit, entsprechende Unit Tests zu implementieren.
Offline First
Bei dieser Strategie wollen wir das fehlende Feature für den Offline Modus nachliefern. Dazu haben wir für den Zugriff auf die verschiedenen Entitäten ein neues Klassenmodell implementiert. Wie du im UML Diagramm siehst, gibt es im oberen Teil eine abstrakte Klasse die alle CRUD Operationen zur Verfügung stellt.
Die abstrakte Klasse ist wie folgt modelliert, dabei verwenden wir für Request und Response eigene Objekte, um den Datenfluss sauber abzugrenzen:
/// CRUD operations for connection service
abstract class SwhConnectionType {
/// Get request
Future<SwhResponse> get(SwhRequest request);
/// Post request
Future<SwhResponse> create(SwhRequest request);
/// Update request
Future<SwhResponse> update(SwhRequest request);
/// Delete request
Future<SwhResponse> delete(SwhRequest request);
}
SwhEntity leitet dann die entsprechenden Aufrufe je nach Situation gegen die entsprechenden Implementierungen weiter. Dabei gibt es die verschiedenen Punkte zu beachten:
- Web und PC Anwendungen arbeiten nur Online
- Bei Only-Offline darf die Online Version nicht gerufen werden
- Hybrid reicht das Lesen im Offline Variante
Zusätzlich dazu muss ein Synchronisierungsprozess implementiert werden, der die Daten Offline und Online synchronisiert, damit diese nicht auseinander laufen. Diesen Prozess werden wir in einem separaten Artikel noch einmal beleuchten.
Fazit
Die Vorbereitungen zur eigentlichen Entwicklungen nehmen bereits einen großen Teil der Entwicklungslaufzeit in Anspruch, damit wird aber vor allem eine stabile Grundlage zur Entwicklung der eigentlichen App gelegt. Auch die Implementierung der automatischen Unit Tests zahlt in die Stabilität und die schnelle Weiterentwicklung ein.
