Add new comment

Für die eine Woche gab es die Idee, eine Anwendung zu entwickeln, die eine Webanwendung auch ohne Internetverbindung nutzbar macht.

Damit entsteht auch schon die erste Frage: mit welcher Technologie soll die Anwendung auf den Endgeräten laufen? Native Programme? Electron-/Phonegap-ähnliche Ansätze, die mit Webtechniken und einer nativen Hülle plattformspezifische Clients zur Verfügung stellen? Da es bereits eine Webanwendung gibt, in der sich die Daten lesen und bearbeiten lassen, sind auch Progressive Webanwendungen denkbar. Damit wird eine spezielle Webseite plötzlich im Browser verfügbar, obwohl keine Internetverbindung besteht.

Also soll es eine Progressive WebApp werden. Geht nicht unter Safari. Ok, geschenkt.

Nächste Frage: eine Webanwendung mit welchem Framework? Ember, React, Vue, Backbone, etc. Die Wahl fällt auf Angular 4: es gibt Erfahrungen damit und es verwendet TypeScript.

Dann weiter mit Angular. Weil jedes Framework heute, das etwas auf sich hält, diverse Konfigurationen für diverse Tools benötigt, muss die nächste Entscheidung getroffen werden: Wieder beginnen mit dem tollen Projekt der Angular Class? Oder direkt die Angular Kommandozeile? Oder ein hipper Yeoman-Generator? Bei Angular gab es lange den Fehler, dass unterschiedliche Einstellungen zwischen Entwicklungsumgebung und Produktivumgebung nicht angewendet wurden. Die Angular-Kommandozeile ist die jüngste Entwicklung und spricht nicht davon, auch Bereiche abseits der TypeScript-Kompilierung abzudecken. Der Yeoman-Konfigurator bietet diverse CSS-Frameworks, Test-Frameworks und sonstige Tools an. Gekauft.

Damit die Webseite im Browser auch Daten vom Server laden kann, greift sie über HTTP-Verbindungen aus dem Angular-Framework darauf zu. Natürlich gibt es just in der aktuellen Fassung einen Wechsel, sodass nun statt des Http-Moduls das HttpClient-Modul zu verwenden ist. Leider sind die vielen Beispiele im Netz noch für das als veraltet gekennzeichnete Modul.

Nachdem nun die Kommunikation grundsätzlich möglich ist, soll sich die Webseite am Server anmelden. Leider gibt es dort den frischen Fehler 2903217 und die Anmeldung muss JavaScript-untypisch über formularbasierte Datenübermittlung ablaufen. Aber das Problem ist lösbar.

Nachdem die Anmeldung durchgeführt ist, sollen die Daten geladen werden. Dabei stoße ich gleich auf einen weiteren Fehler 2825204, der zwar schon behoben ist, aber erst in der nächsten veröffentlichten Fassung enthalten sein wird. Die Änderungen lassen sich aber auch auf die aktuelle Version anwenden, sodass nun endlich Daten vom Server in den Browser geladen werden.

Die geladenen Daten werden anschließend in der lokalen Datenablage des Browsers gespeichert. Beim nächsten Aufruf der Seite werden sie von dort wieder zurückgeholt, sodass sie auch ohne Serverzugriff zur Verfügung stehen. Und da ist die nächste Herausforderung: das bisherige Programmiermodell machte es einfach, eine Datenklasse abzuspeichern und wieder auszulesen. Mit der schönen neuen ES6-Welt werden plötzlich nicht mehr alle Daten an die richtigen Stellen zurückgespielt, weil es ja nun eine ordentliche Kapselung der Datenobjekte gibt. Auch hier gilt es, Integrations-Code zu schreiben.

Zusammengefasst: Es gibt diese lustigen Meme-Bilder: was denken andere, dass ich tue, was denke ich, dass ich tue, was tue ich tatsächlich. Die Wahrheit ist: wer Software entwickelt, muss ständig Entscheidungen für oder gegen eine trendige Technologie treffen, muss ständig prüfen, ob der Fehler aus einer falschen Verwendung oder der Verwendung der falschen Komponenten resultiert, muss ständig prüfen, ob die genutzten Bestandteile schon den nötigen Reifegrad erreicht haben, muss ständig prüfen, ob die me-too-Buzzwords auch in hinreichender Funktionalität münden und muss ständig prüfen, wie sich die gewählten Bestandteile letzlich zu einem Zusammenspiel überreden lassen.