Boehrsi.de - Blog

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

Im Rahmen meiner Softwareentwicklung arbeite ich oft mit Serverkomponenten. Diese können von mir selbst entwickelt worden sein, z.B. Microservices die auch hier auf meinem Server laufen oder aber externe Server, welche mir Daten liefern.
Auch diesen Teil einer Software möchte oder muss man natürlich testen. Sowohl bei der Entwicklung selbst, wie auch zwischendurch im Betrieb, bei den eigenen Komponenten. Letzteres z.B. um den Status eines Servers zu ermitteln oder um zu prüfen ob ein Update erfolgreich verlief.
In diesem Kontext bin ich gerade verwundert von mir selbst, denn ich habe noch nicht spezifisch über Postman hier im Blog geschrieben. Postman ist mein Go-To Tool, wenn es ums Testen von Servern geht. Natürlich kann man auch über die Konsole, z.B. mit Tools wie curl open_in_new, einiges erreichen, aber dies ist mir zu unkomfortable.
Postman erlaubt mir mit wenigen Klicks einen Request zu erstellen, den Typ zu konfigurieren, Parameter anzugeben, Header und Body zu definieren und noch vieles mehr. Damit kann ich schnell und einfach einen Request bauen, um z.B. einen bestimmten Call zu testen.
Habe ich einen kompletten Dienst den ich testen will, kann ich die oben genannten Request auch speichern und in einer Sammlung verwalten. Dort kann ich die Requests dann sammeln, Beschreibungen angeben und zusätzlich sogar noch eine kleine Test Suite definieren. Soll heißen ich kann Requests der Sammlung nutzen, erwartete Ergebnisse definieren und alles geordnet ausführen. Anschließend erfahre ich in einer kleinen Auswertung, ob alles erfolgreich verlief.
Generell gibt es viele Alternativen, für mich persönlich läuft Postman allerdings sehr gut. Sobald man als Team arbeitet oder komplexere Aufgaben erledigen will, bietet Postman auch kostenpflichtige Versionen open_in_new mit diversen Zusatzfunktionen an, ich nutze allerdings die kostenlose, da selbige für mich ausreichend ist.
Falls ihr Tooling in diesem Bereich nutzt würde mich übrigens sehr interessieren was ihr nutzt und wie ihr die Tools nutzt, da ich mich immer über neuen Input freue. Meldungen diesbezüglich gerne direkt in die Kommentare.

• Postman 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

Ich bin täglich auf GitHub unterwegs, da ich dort sowohl privat, wie auch beruflich einiges an Git Repositories liegen habe. Für interne Projekte habe ich zwar zusätzlich Git bei mir auf dem Server laufen + Gitea als Frontend, aber GitHub ist für mich durch meine Arbeit und für Open Source Projekte eine sehr beliebte Wahl.
Da freut es mich und vermutlich auch viele andere sehr, dass GitHub nun auch für Teams kostenlos ist. Bereits vor etwas mehr als einem Jahr wurden private Repositories komplett kostenlos und nun geht es mit einem weiteren Feature weiter. Die aktuelle Änderung zielt vor allem auf die Kollaboration ab, also das gemeinsame Arbeiten an Projekten.
Kostenlos gibt es unendlich viele öffentliche und private Repositories, mit beliebig vielen Mitarbeitern. Dazu sind 2000 GitHub Actions Minuten pro Monat nutzbar und 500MB für eure GitHub Pages. Solltet ihr übrigens mehr brauchen als die angegebenen Werte, auch der Preis für GitHubs kostenpflichtiges Team Paket wurden reduziert (von 9 Dollar pro Nutzer pro Monat auf 4 Dollar).
Für viele dürfte dies sehr attraktiv und ausreichend sein, um gemeinsam an Projekten zu arbeiten. Ich persönlich werde auf jeden Fall überlegen für die nächsten gemeinsamen Projekte dorthin umzuziehen. Denn GitHub bietet ein bekanntes Interface, man hat keinen Verwaltungsaufwand, wie bei Self-Hosted Lösungen und die Plattform bietet einige Features über reines Git hinaus. Was denkt ihr zur aktuellen Entwicklung bei GitHub?

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

Aufgrund der aktuellen Situationen werden viele Events abgesagt und auch die IT / Softwareentwickler-Welt ist davon natürlich betroffen. Damit der geneigte Android-Entwickler aber weiterhin sein Wissen aufbessern und sich mit anderen austauschen kann, habe sich die Droidcon Veranstalter etwas überlegt.
Droidcon Online ist eine Event-Reihe, bei welchen ihr zu festen Terminen in den nächsten Monaten einiges neues lernen könnt. Themen wie Jetpack, Multi-Platform Development, Kotlin, Tooling, Security, CI/CD, Testing und Design werden dabei bedient.
Ein jedes Webinar besteht aus zwei 30 Minuten Sessions, einem 15 Minuten Talk und anschließend einer Q&A Runde. Hier könnt ihr euch also Wissen aneignen, euch austauschen, Fragen stellen und mit der Community in Kontakt bleiben. Diese Onlineveranstaltungen sind kostenlos und stattdessen bittet man um eine Spende an den World Health Organization COVID-19 Solidarity Fund, sofern man etwas geben möchte.
Falls ihr übrigens keine Zeit an einem der Termine habt, könnt ihr auch Aufzeichnungen von selbigen anschauen oder z.B. zum zweiten Teil einer Vortragsreihe einsteigen. Weitere Informationen findet ihr in den Related Links. Dort findet ihr die Termine, den FAQ zur Aktion und alle weiteren Informationen. Ich werde auf jeden Fall an einigen Webinaren teilnehmen und bin gespannt was es neues in im Android Land gibt, denn durch Flutter bin ich aktuell ja eher wenig in der nativen Android Welt unterwegs.

• Droidcon Online Website open_in_new
• Droidcon Online - FAQ 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?

Es ist schon wieder etwas her das ich eine News in diesem Bereich geschrieben habe, doch nun wird’s mal wieder Zeit. Denn aktuell grübele ich bezüglich einem Thema, bei welchem ich nicht zu einem optimalen Entschluss komme. Es geht um die Menge der zu verwendenden Guards bzw. Sicherheitsmechanismen, um eine fehlerfreie User Experience zu gewährleisten.
Generell sind wir Softwarenentwickler uns bestimmt einig, dass das User Interface und alles was der Nutzer darin zu sehen bekommt, eher robust sein sollte und entsprechend Fehler gut abfangen muss. Doch wie weit soll man gehen, wenn es darum geht die UI und Logik gegen fehlerhafte APIs zu schützen, die man selber mehr oder weniger unter Kontrolle hat. Ich rede hier von Schnittstellen die auf dem Gerät in Form von Bibliotheken vorhanden sind, nicht von externen APIs, die z.B. auf entfernten Servern liegen (letztere sollten definitiv umfangreich und effektiv abgesichert werdern). Denn auch selbstverwaltete Bibliotheken, welche vielleicht von einem Kollegen der aktuell keine Zeit hat gepflegt werden, können hin und wieder Fehler beinhalten.
Ich bin ein Fan von Fail Fast & Fail Often, denn meiner Meinung nach gehen ansonsten zu viele Fehler unter. Doch wie geht man mit mehr oder weniger bekannten Issues um, welche in darunterliegenden Ebenen vorhanden sind, die teilweise zum eigenen Code gehören.
Baut man Guards ein - vielleicht auch nur temporär - können selbige in Vergessenheit geraten und später das Debugging massiv erschweren. Lässt man die Fehler zu, kann es zu sichtbaren UI Fehlern kommen, was natürlich zu vermeiden ist. Ich persönlich sehe hier eine Zwickmühle, welche ich zwar nicht perfekt, aber für mich für den Moment passend lösen konnte.

Als Software-Entwickler kann man in diesen Zeiten nicht nur etwas Hardware für einen guten Zweck zur Verfügung stellen, man kann auch versuchen anderen das Leben etwas leichter zu machen. Denn ein kleines bisschen Entwicklungsarbeit kann hier und dort Dinge für verschiedene Leute einfacher und praktikabler machen.
Ebendies habe ich versucht, indem ich einen kleinen Webservice schrieb. Selbiger erlaubt es dem Verein, in welchem meine bessere Hälfte aktiv ist, zu planen wer das Gelände wann betritt. Dies ist wichtig, um zu verhindern dass eine größere Gruppe von Personen gleichzeitig da ist. Denn wie mittlerweile jedem klar sein sollte, ist dies ein sehr relevanter Schritt, um die Verbreitung von Corona zu verlangsamen.
Der Aufwand war für mich ca. ein Wochenende, inklusive Deployment und ich habe dabei noch einiges gelernt. Denn ich nutzte zufällig das Framework, welches ich ohnehin weiter ausprobieren wollte (Javalin) und Kotlin als Programmiersprache. Somit konnte ich helfen, gleichzeig etwas lernen und am Ende macht es das Leben einiger Nutzer vielleicht ein kleines bisschen weniger kompliziert, in diesen komplizierten Zeiten.
Warum ich das schreibe fragt ihr euch vielleicht, nicht um Lob einzusammeln, sondern eher um zu motivieren. Vielleicht könnt auch ihr, durch welche Fähigkeit auch immer, den Leuten helfen. Oft sind auch Kleinigkeiten eine Hilfe und auch nicht physische Hilfe dürfte für viele relevant sein. Die digitale Welt ist Fluch und Segen zu gleich, lasst uns doch versuchen noch etwas mehr Segen zu verteilen.