This is a test message to test the length of the message box.
Login
Flutter Finance Overview Framework
Erstellt von Software-Heroes

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.

Werbung

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.


Enthaltene Themen:
Finance OverviewFlutterSwh-Framework
Kommentare (0)

Flutter - Finance Overview (Daten)

Kategorie - Flutter

Heute geht es um das Datenmodell der App im ersten Preview, das Design der API und die Herausforderungen dabei.

16.06.2021

Flutter - Finance Overview (Projekt)

Kategorie - Flutter

Wir starten ein neues Projekt und nehmen dich mit durch die verschiedenen Stationen von der Planung, über die Entwicklung bis hin zum Release. In diesem Artikel die Erklärung was hinter dem Projekt steckt.

02.06.2021

Flutter - #FlutterEngage

Kategorie - Flutter

Das FlutterEngage Event ist zu Ende und es gab wieder viele hilfreiche und interessante Informationen für alle Flutter Entwickler unter uns. Wir wollen hier kurz die wichtigsten Punkte zusammenfassen.

05.03.2021

Flutter - Lernquellen

Kategorie - Flutter

In diesem Artikel wollen wir dir einige aktuelle Lernquellen vorstellen, die du als Inspiration und zur Weiterbildung nutzen kannst. Hier werden wir vor allem auf YouTube Kanäle eingehen und einige vorstellen.

29.01.2021

Flutter - Webseiten

Kategorie - Flutter

Die Erstellung von Webseiten und PWAs ist bereit seit einer ganzen Weile in der Beta- Phase, heute zeigen wir dir ein kleines produktives Beispiel.

16.10.2020