Los ging mein Flutter-Check als Nicht-Entwickler mit dem Studieren der Dokumentation. Dann durchsuchte ich Stackoverflow nach Flutter. Kämpfte um das gewünschte UI-Verhalten. Und bekam (Alb-)Träume vom Code. Hier meine Erkenntnisse über das neue Framework.

Was ist Flutter?

Flutter ist ein Open-Source-Framework, das von Google entwickelt wurde. Damit kann man mobile Anwendungen für iOS und Android (zukünftig auch für Desktops und Web) mit einer Code-Basis entwickeln. Das heißt: Die Entwicklung findet nicht plattformspezifisch statt, sondern in einer Programmiersprache und in einer Programmierumgebung.

Programmiersprache: DART

Im Falle von Flutter ist die Programmiersprache DART, die auch von Google entwickelt wurde. Sie ist perspektivisch relevant, wenn Googles Fuchsia OS auf den Markt kommt. Denn die Anwendungen für dieses Betriebssystem sollen mit DART entstehen.

DART ähnelt den etablierten objektorientierten Programmiersprachen wie C#, Swift oder Java. Als Programmierumgebung reicht theoretisch ein Texteditor. Sinnvoller ist natürlich die Verwendung von z. B. Android Studio oder Visual Studio Code.

Echte native Anwendung für Endgeräte

Die mit Flutter entwickelte Anwendung wird vor der Veröffentlichung / Installation auf dem Endgerät für die ARM-Architektur kompiliert. Das heißt: Es handelt sich um eine echte native Anwendung für die Endgeräte. Für die Funktionen wird also kein JavaScript Bridge benötigt (wie z. B. im Falle von React Native).

Das Rendering erfolgt über eine C++ 2D Rendering Engine Skia, die auch in Google Chrome, Mozilla Firefox und vielen anderen Produkten zum Einsatz kommt. Damit können auch umfangreiche programmatische (UI) sowie vorgefertigte vektorbasierte Animationen implementiert werden. Die Vektor-Animationen lassen sich z. B. mit Hilfe von Flare so gestalteten, dass sie auf unterschiedliche Zustände der Anwendung reagieren können. Clever!

Wie in React Native beeinflussen die Funktionen die UI nicht direkt, sondern verändern den Zustand (State) des Widgets oder der ganzen Anwendung (unidirectional Data Flow bzw. reactive Programming). Damit wird grundsätzlich nur der Teil des Interfaces neu gerendert, der von der Zustandsänderung beeinflusst wird.

Die SDK bietet eine große eigene Bibliothek anpassungsfähiger Widgets, mit denen die UI direkt implementiert werden kann. Diese Widgets sind zum Teil plattformsensitiv und setzen betriebssystem-typische Interaktionen automatisch um (z. B. Edge-Swipe auf iOS). Darüber hinaus gibt es eine große Auswahl an zusätzlichen Modulen von Drittanbietern, die über Dart Packages bezogen und in die App integriert werden können.

Alles ist ein Widget

Die Widget-Denke ist das Besondere an Flutter. Die App selbst ist ein Widget. Ein Button ist ein Widget. Sogar der einfache Text ist ein Widget.

Mitgelieferte Widgets im iOS- und Android-Stil

So kann jedes Element der Anwendung verändert und angepasst werden. Auch komplett eigene Widgets können mit relativ wenig Aufwand entwickelt werden. Bestehende Widgets lassen sich um zusätzliche Features erweitern. Sie werden wie Objekte behandelt. Können auf Veränderungen der Status reagieren. Und mit Datensätzen arbeiten.

Obwohl dieses Widget-Denken anfangs nicht intuitiv ist und das Feature-Set einiger Elemente sich stark unterscheidet, erlaubt es große Flexibilität in der Entwicklung der Anwendung.

Die Entwicklung mittels Widgets hat zur Folge, dass alles zum Bestandteil des Quelltextes wird. Die UI-Elemente werden in derselben Datei beschrieben wie die Funktionen der Anwendung. Es gibt leider auch kein visuelles Layout-Tool. Nicht-Entwickler wie ich müssen sich den Kopf zerbrechen, wenn das Layout nicht so will, wie man es vorgesehen hat. Ein Storyboard- bzw. Layout-Tool wie in Xcode oder Android Studio würde den Zugang zum Framework deutlich vereinfachen.

Ich habe bereits mit der Bewertung des Frameworks angefangen. Hier sind die Vor- und Nachteile von Flutter, die mir aufgefallen sind.

Vorteile von Flutter

Im aktuellen Release bringt Flutter einige sehr gute Features und Workflow-Ideen mit. Mir sind folgende besonders aufgefallen:

  • Basiselemente der UI wie Navigation Drawer, Tab-Leiste, Button etc. sind Bestandteil der SDK
    Sie müssen nicht entwickelt werden.
  • Vielfältige mitgelieferte UI-Module
    Diese unterstützen erwartete Interaktionsmuster und sind ansprechend gestaltet.
  • Die App-Performance ist in meisten Fällen gut
    Da der JS-Bridge entfällt, ist die CPU-Nutzung nahe an nativen Anwendungen dran. Flutter-Apps zeichnen sich jedoch durch einen höheren Arbeitsspeicher-Verbrauch aus – gerade im Vergleich zu nativen und React-Native-Anwendungen. Ob eine Flutter-App allerdings wirklich so umfangreich werden kann, dass die RAM-Nutzung (abgesehen vom Stromverbrauch) zu einem Problem wird, ist fraglich.

  • Einfache Implementierung der Daten-Streams mit dem BLOC-Muster
    Damit können schnell Anwendungen implementiert werden, die dem Nutzer stets aktuelle Daten präsentieren (im Stil von Instagram, Dribbble und ähnlichen Apps).
  • Hot Reload
    Die Änderungen im Quelltext werden übernommen, ohne dass man die App komplett neu starten muss. Das war neu für mich, der von der Unity3d- und C#-Entwicklung kommt. Und: Ich finde es großartig.
  • DART ist eine angenehme und vollständige Programmiersprache
    Sie weist genügend Ähnlichkeiten zu anderen objektorientierten Sprachen aus – in der Syntax und in grundsätzlichen Entwicklung-Mechaniken. Dadurch ist der Zugang angenehm einfach. Man kann sofort loslegen.

Nachteile von Flutter

Nicht alles ist rosig in der Flutter-Entwicklung. Manche Momente sind der Architektur geschuldet. Man muss lernen, damit zu leben. Andere Momente sind einfach nur nervig. Hier eine kurze Liste der Nachteile, die mir aufgefallen sind:

  • Mitgelieferte Module werden kompiliert
    Wenn also ein Update des Betriebssystems mit neuer UI-Designsprache kommt, muss erst Flutter aktualisiert werden, dann die App. Diese muss anschließend als neue Version im Store veröffentlicht werden, um die neue Designsprache zu berücksichtigen.
  • Derzeit kein Code-Sharing mit Web-Projekten möglich
  • Stark verschachtelter Code mit vielen Wrapper-Elementen
    Nur so erzielt man das gewünschte UI-Verhalten. Der Funktionscode ist in derselben Datei. Dadurch leidet die Übersichtlichkeit stark. Grundsätzlich kann klassenweise ausgelagert werden, aber die Quelltext-Ordnung ist nicht auf Architekturbasis vorgegeben.

  • Oft kryptisches Debugging
    Es zeigt nicht die fehlerhaften Code-Zeilen, sondern Fehler auf der Framework-Ebene.
  • In der SDK-Dokumentation fehlen Nutzungsbeispiele
    Sie ist zwar sehr ausführlich. Doch manchmal wird es mau – vor allem bei der Entwicklung der Funktionen, die über die Basis-Implementierung hinausgehen.
  • Das Framework ist noch recht neu
    Daher sollte man nicht jederzeit mit dem Community-Support rechnen. Auch gilt: Je maßgeschneiderter die Funktion, desto schwerer wird es, Hilfe zu bekommen.
  • Die Implementierung eigener Stile ist schwierig
    Man kann z. B. schnell und einfach die Farben der Standard-UI-Elemente definieren(Navigationsleiste, Buttons). Dieses muss jedoch in jeder separaten Klasse (lese in jedem View) einzeln geschehen. Globales Stilisieren der Textelemente schien unmöglich. Dort mussten Inline-Stile herhalten. Die Flexibilität und Einfachheit des CSS fehlte sehr. Mir wäre es deutlich lieber, eine separate Themen-Klasse zu definieren, die das komplette Erscheinungsbild der App um eigene CI erweitert.

Flutter in der Zukunft

Die SDK wird aktiv weiterentwickelt. So kann und wird sich noch einiges ändern. Vor allem diese Entwicklungen werde ich im Auge behalten:

  • Projekt Hummingbird
    Die nächste vorgestellte Erweiterung –soll das Code Sharing mit Web-Komponenten in Flutter ermöglichen. Dadurch wäre das Framework deutlich universeller einsetzbar und käme dem näher, wie React Native derzeit funktioniert.
  • Kompilierung der Projekte für Desktop
    Unklar ist noch, wie und ob diese gelöst wird.

Einsatzbereiche

Aufgrund der relativ einfachen Entwicklung und dem damit verbundenen geringeren Zeit- und Ressourcen-Aufwand eignet sich Flutter insbesondere für folgende Einsatzgebiete:

  • Konzeptioneller Beweis einer App-Idee, der auf einem Endgerät geprüft werden kann. Also eine Art Click-Dummy mit Platzhalter-Inhalten, der die Idee interaktiv vermittelt.
  • Erstellung eines Funktionsprototypen, erweitert um tatsächliche Datensätze, Netzwerk-Ressourcen und eigene Funktionen aus dem Click-Dummy. Dieser eignet sich besonders gut zur Kommunikation der Idee. Er liefert Aufschluss über den zu erwartenden Entwicklungsaufwand.
  • Modul-Entwicklung, wenn eine existierende native Anwendung um zusätzliche Elemente erweitert werden soll. Vor allem, wenn diese Module sich in aktiver Testphase befinden und ständigem Wandel unterliegen, profitiert man von kurzen Entwicklungszeiten.
  • Anwendungen mit überschaubarem Umfang, die voraussichtlich eine eher kleine Nutzerbasis aufweisen werden. Diese lassen sich komplett in Flutter entwickeln.
  • Ideen mit viel Potenzial und First-Mover-Advantage, deren Finanzierung noch nicht vollständig gesichert ist (Start-ups, Firmenprojekte). Flutter gewährleistet, dass man initial eine maximale Zielgruppe erreicht (iOS und Android).

Ausblick

Cross-Plattform-Frameworks haben grundsätzlich großes Potenzial. Sie eignen sich hervorragend für bestimmte Einsatzzwecke. Das trifft auch auf Flutter zu.

Auch als Nicht-Entwickler war ich in der Lage, in (vergleichsweise) sehr kurzer Zeit einen funktionsfähigen Prototypen zu entwickeln. Der ab Werk gut implementierte Umgang mit Netzwerk-Ressourcen und die einfache Integration der Datenbaken sind eine gute Grundlage für die Entwicklung einer Production-Ready-App mit Flutter – für eine nicht allzu große Zielgruppe. Auch für firmeninterne oder B2B-Anwendungen eignet sich Flutter gut, da der Fokus nicht auf ausgefallener UI liegt. Mögliche technische Probleme werden eher toleriert und im direkten Kontakt mit dem Nutzer gelöst.

Zielt eine Anwendung aber darauf ab, eine sehr große Nutzerbasis zu bedienen? Haben Skalierbarkeit, Performance, Stabilität und UX absolute Priorität? Dann sollte man weiterhin zu einer nativen Entwicklung greifen.

Artyom Tokarev

Artyom ist Art Director für AR, VR und Bewegtbild bei New Communication – und wird von allen nur Arti genannt. Der studierte Multimedia Producer hat schon so einigen Kunden mit seinen Mixed Reality Kunststücken die Köpfe verdreht. So überzeugend, dass er unserer Meinung nach eigentlich Sm-Arti heißen müsste. Oder Einzig-Arti. Kurz gesagt: Wir lieben ihn einfach, unseren Arti Director.

Heiß auf Insider-Infos?

Immer up to date: Unser Newsletter versorgt dich einmal monatlich mit brandneuen Trends und Innovationen aus der Kommunikationswelt.

Newsletter bestellen