Boehrsi.de - Blog

Nun geht es in die vollen, denn heute bauen wir unsere erste richtige Logik. Am Ende des vierten Teils dieser Tutorialreihe soll die initiale Logik zum Start der App und die RSS Feed Logik implementiert sein. Zur Umsetzung erstellen wir den MainBloc (lib/main/main_bloc.dart open_in_new), der die Datenbank lädt und später z.B. das Laden der Konfiguration übernehmen kann. Sobald dieser Vorgang abgeschlossen ist, sollen alle RssFeed Objekte mit Hilfe des FeedListBloc (lib/feed_list/feed_list_bloc.dart open_in_new) aus der Datenbank geladen werden.
Damit die Datenbank auch mit Inhalt gefüllt ist, soll es über die UI möglich sein einen neuen Feed anzulegen. Sowohl für das Laden der RssFeeds, wie auch für das Hinzufügen wird der FeedListBloc genutzt. Außerdem erstellen wir geeignete Widgets zur Darstellung der Liste (lib/feed_list/feed_list.dart open_in_new) und des Formulars (lib/feed_list/feed_list_change.dart open_in_new), wobei letzteres im nächsten Teil der Reihe umgesetzt wird.
In diesem Zuge habe ich auch eine kleine Umbenennung vorgenommen, denn unser RssList Widget (nun FeedList Widget) und alle damit verwandten Klassen, befinden sich nun im FeedList Kontext open_in_new (Namen und Pakete). Dieser Name gefiel mir einfach besser und ist gleichzeitig kürzer und deutlicher. Die Bezeichnung für den Typ bleibt allerdings unverändert bei RssFeed.

Damit das Verstehen der folgenden Schritte leichter fällt, beginne ich mit einem schnellen Einblick in das BloC Konzept. Ich empfehle euch allerdings die offizielle Dokumentation open_in_new zum Thema anzuschauen, wenn ihr das Ganze aktiv nutzen wollt. Sie ist übersichtlich, gut gemacht und bietet außerdem diverse gute Beispiele.
BloC oder auch Business Logic Components ist mein aktuell favorisierter Weg, um Logik von UI und wiederum von Daten zu trennen. Dafür wird sehr intensiv auf das Konzept von Streams open_in_new gesetzt. Ein BloC interagiert immer mit zwei Streams, einem für den Input (Events) und einen für den Output (States), dabei sollte jedes Event zu mindestens einem passenden State führen. Im konkreten Library Kontext wird dafür die mapEventToState() open_in_new Methode genutzt. Sofern ihr einen BloC erstellt und Bloc open_in_new erweitert, müsst ihr sowohl die akzeptierten Events dieses BloC, wie auch die dazugehörigen States angeben. Diese definiert man meist in einer gesonderten Datei, wodurch ein übersichtlicher klarer Rahmen von erlaubten Eingaben und Ausgaben definiert wird.
Events können von der UI, z.B. durch einen Tap auf einen Button, kommen oder aber von anderen BloCs, bzw. tieferliegenden Komponenten. States werden vom BloC erzeugt und meist von der UI verarbeitet und führen zu automatischen Anpassungen von selbiger. Allerdings können auch andere BloCs auf State Änderungen hören und entsprechend Aktionen durchführen. Es ist außerdem erlaubt im Laufe der Verarbeitung mehrere States zu liefern. So macht es bei längeren Aktionen zum Beispiel Sinn, am Anfang einen Loading State zu übergeben und nach Abschluss einen State der die finalen Daten zurückgibt.
Entsprechend gibt es verschiedene Quellen für Events und verschiedene Ziele für States, auch mehrere gleichzeitig sind möglich. Streams bieten hier viele Freiheiten und Flexibilität, es ist allerdings extrem wichtig alles ordentlich zu dokumentieren und klare Flows zu etablieren. Denn mit großer Flexibilität kommt sonst großes Chaos.

• Tutorial App Repository auf GitHub open_in_new
• Flutter Website open_in_new

Beim Programmieren ist es wichtig bestimmte Regeln einzuhalten, dabei geht es nicht nur darum das der Code kompiliert, sondern auch das er verständlich, übersichtlich und dadurch wartbar ist und auch bleibt. Diese Dinge erzielt man meist indem man sich an bestimmte Guidelines hält. Diese gibt es oft von den Entwicklern der Sprache selbst, von großen Organisationen oder aus anderen Quellen. Woran man sich konkret hält ist zwar Geschmackssache, aber man sollte auf jeden Fall einen konsistenten Pfad verfolgen.
Da wir aber alle nur Menschen sind, dadurch Dinge vergessen oder einfach übersehen, ist eine technische Hilfe durchaus willkommen. Lint Checker open_in_new helfen uns mit Warnings und teilweise bietet die dazu passende IDE sogar Autokorrekturfunktionen an. Im Flutter Kontext habe ich zuletzt die genannten Dinge kombiniert.
Ich habe mir das Pedantic Package open_in_new geschnappt, welches die Lint Regeln von Googles Dart / Flutter Entwicklern beinhaltet, selbige mit meinen privaten Projekten in Android Studio verknüpft und somit mit extrem wenig Aufwand, noch einmal diverse kleine Baustellen aus der Welt geschafft.
Das Package selbst wird wie gewohnt als Dependency eingebunden, meinem Fall aber im dev Bereich der pubspec.yaml Datei, da ich nur die Checks während der Entwicklung nutzen möchte.

dev_dependencies:
  pedantic: ^1.8.0

Neben eurer pubspec.yaml benötigt ihr eine weitere Datei. Falls noch nicht vorhanden erstellt die analysis_options.yaml im Root Verzeichnis eures Projektes und fügt die folgende Zeile ein.

include: package:pedantic/analysis_options.yaml

Ich führte anschließend noch einmal ein flutter pub get aus und schon flogen mir die Warnings nur so um die Ohren. So schlimm war es nicht, aber den einen oder anderen Tipp gab es dann doch noch für mich. Tatsächlich alle nachvollziehbar und mit wenigen Klicks via Android Studio Quick Fix behoben. Meiner Meinung nach ein einfacher Weg, um die Codequalität eines Projektes weiter zu heben. Alternativ gibt’s übrigens auch noch das Effective Dart Package open_in_new , welches direkt alle Regeln des Effective Dart Guides anwenden soll. Selbiges werde ich in der Zukunft auch noch ausprobieren.

• Pedantic Package open_in_new
• Effective Dart Guide open_in_new
• Customizing Static Analysis Guide open_in_new

Nach dem der letzte Teil ein sehr langes Intro war, erstellen wir nun die Typen und die Datenbank, inklusive Wrapper-Objekten, welche uns die einfache Nutzung der Datenbankinhalte innerhalb der BloCs erlauben sollen. Neben einer sehr kleinen Basisklasse (lib/types/database_entry.dart open_in_new) für die Typen, gibt es zwei Haupttypen. Einmal den RssFeed (lib/types/rss_feed.dart open_in_new) und den RssEntry (lib/types/rss_entry.dart open_in_new). Diese beiden bilden die initiale Datenbasis, mit welcher ich arbeiten möchte. Im folgenden findet ihr Code-Teile der genannten Klassen und einige Erklärungen dazu.

lib/types/database_entry.dart (Code auf GitHub open_in_new)

abstract class DatabaseEntry {
  Map<String, dynamic> toMap();

  int get id;
}

Diese kleine Basisklasse zwingt unsere Typen dazu, sowohl ein Mapping Funktion zur Verfügung zu stellen, wie auch einen Getter für die Id. Die Mapping Funktion ist relevant, da unsere Datenbank JSON open_in_new als internes Format nutzt und entsprechend gerne mit Key-Value-Maps arbeitet. Ich hätte hier gerne noch Wrapper-Funktionen für die Erstellung der jeweiligen Objekte hinzugefügt, aber dafür wäre Generic-Black-Magic nötig gewesen, welche den Umfang dieses Tutorials sprengen würde.

• Tutorial App Repository auf GitHub open_in_new
• Flutter Website open_in_new

Womit geht es in Teil zwei weiter habe ich mich gefragt. Sowohl die UI, wie auch die eigentliche Architektur könnten ein Thema sein. Ich persönlich bevorzuge erst die Logik, dann die UI und entsprechend machen wir heute auch weiter. Bevor wir jetzt aber alles selber schreiben, binden wir erst einmal relevante Libraries ein. Denn es gibt ein paar Dinge die man nicht unbedingt selber schreiben möchte.

pubspec.yaml (Code auf GitHub open_in_new)

name: fss
description: Fluttery Site Summaries - RSS the Flutter way

version: 1.0.0+1

environment:
  sdk: ">=2.7.0 <3.0.0"

dependencies:
  flutter:
    sdk: flutter
  bloc: ^4.0.0
  flutter_bloc: ^4.0.0
  flutter_html: ^0.11.1
  http: ^0.12.0+4
  intl: ^0.16.1
  path_provider: ^1.6.7
  sembast: ^2.4.2
  url_launcher: ^5.4.5
  webfeed: ^0.4.2

dev_dependencies:
  flutter_test:
    sdk: flutter
  pedantic: ^1.9.0

flutter:
  uses-material-design: true

• Tutorial App Repository auf GitHub open_in_new
• Flutter Website open_in_new

Wie man es im Leben kennt, hat alles wesentlich länger gedauert, sowohl die Planung für diese Newsreihe, wie auch die Entwicklung der App und die eigentliche Erstellung der Beiträge, doch heute geht es nun wirklich los.
Diese Tutorialreihe richte sich an Entwickler die bereits einige Erfahrungen sammeln konnten, bzw. die ein Grundverständnis für Dart open_in_new und Flutter open_in_new haben. Ich werde versuchen alles so umfangreich wie möglich zu erklären, allerdings werde ich nicht jeden Parameter eines jeden Widgets beschreiben. Dieses Tutorial soll vor allem auch Einblicke in Konzepte und Ideen geben, aber explizit kein Copy & Paste One-Page Tutorial sein. Geschriebener Code wird nach Möglichkeit gemäß den Effective Dart Style Guidelines open_in_new entwickelt.
Das gesamte Repository open_in_new ist im finalen Zustand bereits auf GitHub hinterlegt. Im Laufe der Tutorialreihe haben sich einige interne Strukturen und Bezeichnungen geändert, dies wird in den jeweiligen Beiträgen erläutert.
Ein neues Flutter Projekt startet immer mit einem kleinen Counter-App Beispiel. Dieses soll vor allem komplett neuen Entwicklern etwas Arbeit abnehmen und eine grundlegende Idee von Strukturen und dem Aufbau einer Flutter App vermitteln. Generell eine gute Idee, für uns nicht wirklich hilfreich, also räumen wir erstmal auf.
Ich werde, aufgrund meines Android Hintergrunds und weil es eines der wenigen Designkonzepte ist die selbst ich wirklich nachvollziehen kann, auf Material Design open_in_new setzen. In Flutter nutze ich entsprechend eine MaterialApp open_in_new.
Zudem werde ich in der App keine Übersetzungslogik einbauen und sie nur auf Englisch anbieten. Allerdings möchte ich explizit darauf hinweisen, dass ihr Apps, welche jemals produktiv genutzt werden sollen, von Anfang an lokalisiert entwickeln solltet. Zu diesem Thema findet ihr hier im Blog bald mehr. Dies gesagt möchte ich von jeglicher Form von Magic-Strings abraten, egal ob für Text den der Nutzer sieht oder für interne Inhalte. Strings sollte immer konstant definiert werden, ansonsten beißt man sich früher oder später ins Hinterteil.
Doch nun zum eigentlich Code. Als erstes entferne ich erklärende Kommentare aus der pubspec.yaml open_in_new und lib/main.dart open_in_new, denn selbige brauchen wir nicht. Ich versuche übrigens bei jeder ersten Erwähnung einer Datei den gesamten relativen Projektpfad anzugeben und anschließend nutze ich nur noch den Dateinamen. Ich hoffe dies hilf euch beim Finden der jeweiligen Dateien, überfrachtet den Beitrag selbst aber nicht zu sehr.

• Tutorial App Repository auf GitHub open_in_new
• Flutter Website open_in_new

Meine Flutter Newsreihe hängt gerade noch am letzten Feinschliff und ein paar Code Updates fehlen auch noch, da gerade relevante Libraries in einer neuen Major Version erschienen sind und ich dies gerne abbilden möchte. Damit euch aber nicht langweilig wird, an dieser Stelle eine andere erfreuliche News.
Bereits nächste Woche soll die nächste stabile Flutter Version erscheinen. Diese wird ein neues klareres Release-Modell verfolgen und um besser planen zu können, ist das Ziel von nun an regelmäßige Releases einmal pro Quartal durchführen. Weitere Informationen zu den Plänen gibt es in den Related Links.
Zusätzlich interessant finde ich, dass sich mittlerweile über zwei Millionen Entwickler mit Flutter befasst haben und derzeit ca. eine halbe Million aktive Entwickler pro Monat mit Flutter Projekten arbeiten. Damit das miteinander noch weiter verbessert wird und z.B. kritische Framework-Bugs besser behoben werden können, sind diverse kleine Optimierungen an Abläufen und ähnlichem geplant.
Sollte euch Flutter auch interessieren und ihr hattet noch keine Zeit euch damit auseinander zu setzen, gibt es neben diversen guten Online-Kursen open_in_new, bald wie oben erwähnt eine kleine Newsreihe zum Thema hier direkt im Blog. Bei Interesse schaut also gerne wieder vorbei.

• News im Flutter Blog zum Thema open_in_new
• Flutter Website open_in_new

Lasst uns doch kurz noch das Framework / die Library aktualisieren. Ein Satz den sicherlich der eine oder andere Softwareentwickler schon häufiger von sich gegeben hat. Vermutlich auch kurz vor einem Release, selbst wenn man eigentlich weiß, dass das vielleicht riskant ist. Aber man testet ja, überprüft nochmal die bekannten Flows und eigentlich sieht ja alles ganz gut aus oder?
Nein, einfach nur nein. Auch wenn es vielleicht von Zeit zu Zeit funktioniert, vor einem Release machen wir sowas einfach nicht. Egal ob es ein Update auf die nächste IDE Version ist, eine aktualisierte Library oder gar eine frische Framework Version, am Ende gibt es immer etwas was man nicht überprüft hat.
Erst heute habe ich diese Lehre wieder gezogen. Denn ich arbeite seit langem mit der aktuellen Beta Version des Flutter Frameworks, um einige Funktionen bereits testen zu können. Nun ergab sich das für ein Projekt, welches eigentlich auf dem Flutter Stable-Branch lebt, eben dieser Beta-Branch ein Problem löst. Da ich schon lange auf selbigem unterwegs bin, entschied ich - wenn auch mit einem mulmigen Gefühl - wir versuchen es mit dem Beta-Branch. Alles in allem habe ich ja schon viel getestet und was soll schon passieren?

Falls ihr gerne neues lernt und im Flutter-Universum unterwegs seid, kann ich euch eine Videoreihe der Flutter-Entwickler ans Herz legen. Die Videos sind wenige Minuten lang und erklären jeweils ein Widget. Widgets open_in_new sind Flutters View-Komponenten, welche ihr nutzt um das User Interface zu bauen.
Dabei gibt es High-Level-Widgets, welche quasi vollwertige Inhalte darstellen, z.B. gemäß dem Material Design Konzept open_in_new oder aber Low-Level-Widgets, welche genutzt werden, um darauf aufbauend eigene Strukturen zu erstellen.
Die Flutter Widget of the Week Youtube-Reihe open_in_new bietet Einblicke in beide Ebenen. Dies geschieht wie erwähnt kurz und knapp, aber sehr hilfreich erklärt. Alleine das Wissen das bestimmte Widgets existieren ist manchmal Gold wert. In der Video-Reihe gibt es alles vom Expanded open_in_new Widget, bis hin zum StreamBuilder open_in_new und auch komplexe Dinge wie ClipRRect open_in_new oder DraggableScrollableSheet open_in_new werden gezeigt.
Ich habe hier zuletzt das generische Builder open_in_new Widget kennen gelernt, welches im Prinzip nur eine weitere Ebene in Bezug auf den BuildContext etabliert. Klingt nach unnötiger Schachtelung, aber gerade im Zusammenhang mit dem Provider Package open_in_new oder InheritedWidgets open_in_new generell ist dies extrem praktisch und erspart die Erstellung unnötiger neuer Widget-Strukturen.
Mittlerweile gibt es fast 75 Videos in der Playlist, welche einen schönen Überblick über verfügbare Widgets und generelle Ansätze des Frameworks liefert. Meiner Meinung nach auf jeden Fall einen Blick wert.

• Flutter Widget of the Week Youtube-Reihe open_in_new
• Flutter Website open_in_new

Flutter ist aktuell sehr präsent bei mir, wenn es um die Entwicklung von Software geht. Aus diesem Grund habe ich mir nun auch die Flutter Web Integration angeschaut, welche aktuell auf dem Flutter Beta Channel verfügbar ist.
Nebenbei sei übrigens erwähnt, dass dies mein letztes Projekt war, welches meiner Flutter App Development Newsreihe im Wege steht. Doch nun zu meinen Erfahrungen mit dem Flutter Web Support. Generell funktionieren die meisten Dinge der bekannten App-Entwicklung auch im Web-Kontext, allerdings sollte man vor allem bei Third-Party-Libraries open_in_new darauf achten das Web-Support gegeben ist. Doch selbst dann sollte man lieber noch einmal konkret testen.

• Flutter Web open_in_new
• Flutter Website open_in_new

Meine Flutter Newsserie geht endlich weiter oder sollte man sagen sie startet nun wirklich? Nachdem ich vor einigen Monaten angefangen habe, schlief das ganze Projekt aus Zeitgründen leider sehr schnell ein. Nun geht es weiter, die Pläne sind geschmiedet und selbige werde ich heute mit euch teilen.
Voraussetzung für die App, die ich entwickeln und für Tutorial-Zwecke nutzen möchte, ist das sie einen Nutzen haben soll. Ich möchte nicht To-Do App 1337 entwickeln und da ich nur begrenzt Zeit zur Verfügung habe, möchte ich bei der Entwicklung Spaß haben. Anders könnte ich nicht ausreichend Motivation aufbringen.
Doch nun zum Thema, entwickelt wird ein RSS Reader, mit moderner leichtgewichtiger Persistenz, ordentlicher Architektur die zum Flutter Framework passt und einer flexiblen UI, welche sich im Rahmen des Projekts entwickeln wird. Vor allem im Bereich Animationen möchte ich das eine oder andere ausprobieren.

• Flutter Website open_in_new
• Flutter auf GitHub open_in_new