9 Gründe, warum ich aufgehört habe als Mobile Developer zu arbeiten

Als ich noch studierte, waren Android und iOS recht neue Plattformen, und die Begeisterung und Erwartungen waren groß. Wenn es in der Universität einen Programmier-Workshops gab, wurden fast immer kleine Android-Apps entwickelt. So habe ich meine ersten Schritte im Android-Ökosystem gemacht und das war wahrscheinlich auch der Grund, warum ich direkt nach dem Studium als Mobil Developer tätig wurde.

In diesem Artikel möchte ich über die frustrierenden Erfahrungen berichten, die ich mit dem Android SDK und Flutter gemacht habe. Einige der Punkte, die ich anspreche, gelten jedoch auch für das iOS SDK. Ich habe vor einigen Jahren aufgehört, als Mobile Developer zu arbeiten und hoffe, dass sich inzwischen viele Dinge gebessert haben. Aber schon damals erschien mir die Softwareentwicklung für mobile System derart fehlgeleitet, dass ich mich nach einem alternativen Karriereweg umsehen musste.

Fragmentierung

Die größte Herausforderung eines Android-Entwicklers ist die enorme Vielfalt an Gerätekonfigurationen. Ich habe mich immer gefragt, warum der Großteil des SDK (insbesondere die UI-Komponenten) nicht einfach eine Bibliothek meiner Anwendung war, sondern in das Gerät eingebettet. Deswegen ist die Verwundung der “Support-Libraries” leider unumgänglich und die Anwendung muss für jedes unterstütze API-Level getestet werden. Darüber hinaus erlebte ich häufig Abstürze auf Samsung- oder Huawei-Geräten bei Code, der auf dem Emulator oder meinen Testgeräten einwandfrei funktionierte.

Material Design

Wenn ich auf HackerNews oder Reddit Kommentare zu Googles Material Design lese, habe ich manchmal das Gefühl, dass ich die einzige Person bin, die es wirklich mag. Ich finde es visuell ansprechend und genieße die Benutzererfahrung. Die offizielle Webseite ist ein Paradebeispiel für großartige Entwicklerdokumentation. Als Material Design dann für Android angekündigt wurde, war meine Vorfreude entsprechend groß! Leider war der Übergang vom Holo- zum Material Design auf der Android-Plattform alles andere als reibungslos. Es fühlte sich an, als wäre die Veröffentlichung überstürzt erfolgt. In der offiziellen Material Design “Support-Library” fehlten für die einige Jahre sehr grundlegende Widgets. Auch wenn man sie manchmal in Googles eigenen Apps bewundern konnte, fanden sie nicht ihren Weg in die “Support-Library”. Die Entwickler waren gezwungen, ihre eigene Implementierung zu erstellen oder eine alternative Implementierungen auf GitHub von fragwürdiger Qualität zu verwenden. Zusammen mit einer ganzen Reihe von visuellen Inkonsistenzen und Implementierungsfehlern war die Erfahrung mit der “Support-Library” für Material Design wahrscheinlich das erste Mal, dass ich innegehalten habe, um wirklich über die Entwicklungsumgebung nachzudenken und sie in Frage zu stellen.

Buttons? Date pickers? Fehlanzeige!

Best practices an die sich niemand hält

Es ist eine anspruchsvolle Aufgabe, eine stabile Android-App zu entwickeln. Das liegt hauptsächlich daran, dass das SDK entwicklerfeindlich ist. Es ist erstaunlich, dass eine Android-App theoretisch für unbegrenzte Zeit im Hintergrund laufen kann, dabei keine Systemressourcen verbraucht und direkt in ihren vorherigen Zustand zurückspringt, wenn der Benutzer es wünscht. Das ist zumindest dann der Fall, wenn der Entwickler das State- und das Lifecycle-Management erfolgreich implementiert hat.

Entwickler Hallo Internet! Meine App stürzt ab, wenn ich das Gerät drehe. Wie behebe ich das?
Internet Ganz einfach: deaktiviere “orientation changes”.

Ouch. Aber derartigen Empfehlungen begegnet man häufig.

Hast Du jemals mit Threads in Java gearbeitet? Das ist sehr anspruchsvoll in einer imperativen Codebasis mit veränderlichen Variablen an allen Ecken und Enden. Aber nun rate mal: Mit dem Android SDK ist es noch viel schwieriger. Wenn Du zum Beispiel einen Thread in einer Activity verwalten willst, öffnest du die Büchse der Pandora. Glücklicherweise wurden wir schließlich mit Fragments gesegnet, was das Ganze etwas vereinfachte. Allerdings nur für den Preis, Fragments überhaupt zu bekommen.

Während meiner Zeit als Mobile Developer habe ich eine ganze Reihe von Senior Android-Entwicklern interviewt, die bis auf wenige Ausnahmen damit zu kämpfen hatten, mit diesen grundlegenden Themen korrekt umzugehen.

Ich habe mir immer gewünscht, dass Google diese Probleme anerkennt und mit der Community and Lösungen arbeitet. Die Situation hat sich mit Kotlin wahrscheinlich gebessert, aber das fragwürdige Fundament des Android-SDK lauert noch immer unter den neuen Abstraktionsebenen.

Entwurfsmuster und “Annotations” für gescheiterte Abstraktionen

Entwickler erkannten schnell, dass es unmöglich ist, eine komplexe Anwendung auf den vom Android SDK bereitgestellten Abstraktionen aufzubauen. Die Lösung waren neue Entwurfsmuster, die wahrscheinlich immer noch wöchentlich auftauchen: MVC, MVP, MVVM und MVI sind die, an die ich mich erinnere. Und da wir keine gewöhnlichen Konstruktoraufrufe verwenden können, um Abhängigkeiten zu verwalten, müssen wir “Annotations” über die gesamte Codebasis verstreuen. Nichts davon wäre wirklich notwendig gewesen. Java und mehr noch Kotlin sind ausdrucksstark genug, um all diese Dinge auf transparente und unkomplizierte Weise zu modellieren. Aber Android bevorzugt riesige XML-Definitionen und “reflection”-basierte Instantiierung, so dass Entwickler ihren Code mit “Annotations” und fragwürdigen Entwurfsmustern verschleiern müssen. Mir fehlen ehrlich gesagt die Worte, um auszudrücken, wie katastrophal das ist.

Ungenutzter Vorteil des Besitzes der Plattform

In gewisser Weise konkurrieren die native iOS- und Android-Entwicklung mit dem Web als Plattform. Sie haben jedoch den enormen Vorteil, zu einem einzigen Unternehmen zu gehören, während das Web viele Stakeholder hat, die seine Entwicklung nach ihren Bedürfnissen beeinflussen wollen. Dennoch ist das Web ein lebendigeres und innovativeres Ökosystem. Werfen wir nur mal einen Blick auf die Erfolgsgeschichte von React: Es ist unbestreitbar, dass dessen komponentenbasierter Ansatz für Benutzeroberflächen die beste Abstraktion ist, die bisher entstand ist. Android schaffte es jedoch diesen Trend jahrelang zu verschlafen, bis schließlich “Jetpack Compose” angekündigt wurde, das immer noch nur als “Developer Preview” erhältlich ist. So ziemlich das Gleiche passierte in der iOS-Welt. Hier sind wir also: erben immer noch von einer 15k LOC android.view.View Klasse mit dutzenden von “Lifecycle methods”, während wir irgendwie versuchen, unsere <merge />-XML-Dateien zu injizieren. iOS und Android könnten hier die wahren Pioniere und treibende Kraft sein, aber stattdessen hat die Konkurrenz sie komplett hinter sich gelassen.

In diesem Sinne, herzlichen Glückwunsch Android!

UI Entwicklung: bitte lass deine Erwartungen vor der Tür

Der Schlüssel zu einer gelungen App ist die Benutzeroberfläche. Nun habe ich mich bereits darüber beschwert, dass komponentenbasierte Entwicklung noch in den Sternen steht, aber es gibt noch mehr zu diesem Thema. Hast Du jemals einen Fehler auf einer Website behoben? Du öffnest die Entwicklungswerkzeuge Deines Browsers, klickst auf das betroffene Element und spielst so lange mit den CSS- und HTML-Eigenschaften, bis alles sitzt. Im Vergleich dazu ist Android eine völlig unzugängliche Blackbox. Um ehrlich zu sein, habe ich die Android “Theming”- und “Styling”-Mechanismen nie ganz verinnerlicht. Die Werkzeuge zum Debuggen der Benutzeroberfläche einer Android-App schienen mir im Vergleich zu den Browser-Wekzeugen regelrecht nutzlos.

Du möchtest einen Schlagschatten um diese Box herum? Klar, nimm einfach diese merkwürdige .9.png-Datei oder nutze direkt API-Level 21, wo du Schatten richtig rendern kannst (also nur für konvexe Formen versteht sich 😀).

Tut mir leid, du hast vergessen, einen der vier Konstruktoren in deinem “custom View” zu implementieren. Aber ich halte doch nicht mit einem Kompilierfehler auf, ich stürze stattdessen einfach zur Laufzeit ab!

Es gibt jetzt Telefone mit dieser superhohen Pixeldichte. Kannst Du bitte die entsprechenden xxxhpi-Grafiken zu Deiner App hinzufügen? Nein, Vektorgrafiken werden nicht unterstützt, so was machen wir hier nicht.

— Nächtliche Monologe mit dem Android SDK

Vektorgrafiken

Vor Android 21 (5.0) wurden Vektorgrafiken schlichtweg nicht unterstützt. Begründet wurde das damit, dass die Vielfalt der Android-Geräte Grafiken erfordert, die sorgfältig auf die Anforderungen der jeweiligen Gerätekonfiguration abgestimmt sind. Natürlich erstellten pragmatische Entwickler Werkzeuge, die mein logo.svg in eine ldpi/logo.png, mdpi/logo.png, hdpi/logo.png, xhdpi/logo.png,xxhdpi/logo.png und natürlich xxxhdpi/logo.png umwandelten. Glücklicherweise hat Google schließlich seine Meinung geändert und uns mit VectorDrawable gesegnet, das allerdings nicht alle Features von SVG unterstützt und eine schlechte Abwärtskompatibilität aufweist. Es war zugegebenermaßen aber gut genug, um die Schmerzen zu lindern. Es ist mir jedoch völlig schleierhaft, wie eine Entwicklungsumgebung, die sich rühmt, auf beliebigen Gerätekonfigurationen zu laufen, überhaupt so lange ohne Unterstützung für Vektorgrafiken existieren konnte.

Sackgasse

Im Laufe der Jahre begann ich mir immer mehr Sorgen zu machen, dass mein Wissen in absehbarer Zeit veraltet sein würde. Die meisten Dinge, die ich lernte, waren sehr spezifisch für Android und nur selten im allgemeinen Bereich der Software-Entwicklung anwendbar. Angesichts seiner Macken glaube ich nicht daran, dass die native mobile Entwicklung auf lange Sicht Bestand haben wird, und so begann ich mir Sorgen über die Nützlichkeit der erworbenen Fähigkeiten zu machen.

Flutter

Als Flutter angekündigt wurde, war ich sofort voller Erwartungen und Vorfreude. Es versprach einige der größten Schwächen des Android-SDK zu beheben und dabei obendrein plattformübergreifende Apps zu generieren. Also begannen wir bei meinem damaligen Job tatsächlich mit der Migration unserer nativen Android-App zu Flutter. Und ich muss sagen: Flutter hält sein Versprechen.

• Die Probleme mit Androids Fragmentierung schafft Flutter mit seiner integrierten “Rendering-Pipeline” komplett aus der Welt
• Von Anfang an verfügte Flutter über eine umfassende Bibliothek mit hochwertigen Material Design Widgets
• Die Schnelligkeit der “Hot-Reload” Funktion hat mich umgehauen
• Man erhält eine “Cross-Platform” App mit beispiellos guter Qualität

Aber leider war nicht alles toll. Und es ist schade, denn die Probleme von Flutter hätten bei so einem neu aufgesetzten Projekt leicht vermieden werden können.

• Dart ist schrecklich: Es ist eine vergleichsweise junge Sprache, aber sie wiederholt viele der Fehler ihrer Vorgänger (schlechtes Typsystem, null, Statements statt Expressions, …)
• Fragwürdige Design-Entscheidungen im Flutter-SDK: Anstatt ein besseres React zu schaffen, machten sie es schlechter. Was ein einfacher Funktionsaufruf hätte sein können, wir bevorzugt durch zustandsbehaftete OOP-Monstrositäten gelöst (ich erinnere mich dunkel, dass das Routing und Dialog-Widgets diesbezüglich besonders schlecht umgesetzt wurden).

Schlussfolgerung

Irgendwann war mir klar, dass dies nicht die Art von Technologie ist, mit der ich meine Zeit verbringen möchte. Ich schwor mir selbst, nie wieder für mobile Plattformen zu programmieren. Eine gut gestaltete, mobile Website bringt einen heutzutage ziemlich weit, und deshalb ist dies auch meine Standardoption. Es ist eine einzige Code-Basis und funktioniert einfach auf jedem Client. Wenn ich unbedingt eine mobile Anwendung erstellen müsste, würde ich mich immer noch für Flutter entscheiden, selbst wenn sie nur auf Android laufen müsste. Entwickeln mit dem Android SDK kommt für mich nicht in Frage.

Nun möchte ich allerdings noch klarstellen, dass ich eine gut gemachte native Anwendung (sowohl auf dem Handy als auch auf dem Desktop) sehr bewundere und schätze. Ich habe den größten Respekt vor den Entwicklern, die diese mit den verfügbaren Tools umsetzen. Ich möchte schlichtweg nicht mehr einer von ihnen sein.

Dies ist eine Übersetzung aus dem Englischen. Den originalen Artikel “9 reasons why I gave up on being a Mobile Developer” findest du hier.