Da meine Neugierde und Leidenschaft für Technik und Softwareentwicklung weiterhin scheinbar unerschöpflich ist, habe ich mich auch in diesem Jahr mit neuen Technologien auseinandergesetzt. Dabei haben vor allem Flutter und Elixir meine Aufmerksamkeit erregt.

Swift

Vorab muss ich sagen, dass weiterhin die iOS Entwicklung meine Leidenschaft ist und ich der Schönheit von Swift verfallen bin. Insbesondere die Mächtigkeit der enums sorgt dafür, dass Swift weiterhin mein Favorit ist.

Jedoch ist es auch nicht zielführend sich nur auf seine Lieblingssprache einzuschießen.

Elixir

Elixir ist eine funktionale und nebenläufige Programmiersprache, die auf der virtuellen Maschine von Erlang läuft.

Das erste mal wurde ich auf Elixir aufmerksam als der Freak Show (Podcast) vom Anliegen erzählt hat, den Podlove Podcast Publisher mit dem Elixir Web-Framework Phoenix neu zu schreiben. Zunächst in meiner reading list versunken, bin ich einige Zeit spätere wieder darauf aufmerksam geworden.

Da Elixir eine moderne funktionale Programmiersprache ist lässt sich wunderschöner, testbarer Code schreiben. Und da es auf der Erlang Virtual Machine aufsetzt, profitiert es von der OTP, den zahlreichen Libraries und der unglaublichen Performance (von der es heißt, dass sie WhatsApp zum Erfolg gebracht hat).

Lernen

Meine Lernkurve war recht interessant.
Die Grundlagen sind wie bei auch jeder anderen Sprache und somit sofort verständlich. Selbst Konzepte wie pattern matching findet man in der funktionalen Welt. Spannend wird es dann mit Erlang/OPT Besonderheiten wie Processes, Agents, GenServers und Application Supervisors.

Dabei muss ich betonen, dass mir der hervorragende Guide zu einem guten Einstieg verholfen hat. Siehe https://elixir-lang.org/getting-started/introduction.html

Nebenläufigkeit

Concurrency ist build in. Mit den Erlang-VM Prozessen (nicht System Prozesse) und deren Messages ist das Actor Model fest in der Sprache eingebaut. Swift-Entwickler kennen dieses sicherlich schon von Chris Lattners Swift Concurrency Manifest.

Phoenix

An Hand vom MVC basierten Web-Framework Phoenix erkennt man schon die Schönheit von Elixir und für funktionalen Sprachen typische Einführung von DSLs.

Als Beispiel nehme ich den Router:

defmodule HelloPhoeni.Router do
  use HelloPhoenix.Web, :router

  pipeline :browser do
    plug :accepts, ["html"]
    # ...
  end

  scope "/", HelloPhoenix do
    pipe_through :browser # Use the default browser stack

    get "/", PageController, :index
  end
  
  scope "/api", HelloPhoenix.Api, as: :api do
    pipe_through :api
    resources "/users",   UserController
  end
end

Wobei resources endpoints für die CRUD Operationen bereitstellt.

Da diese Sprache funktional und immutable ist, wird man in Phoenix zu einem eleganten unidirektionalen und fehlertoleranten Code gezwungen. Hier zeigt sich wieder wie mächtig und vorteilhaft Limitationen sind.

Flutter

Flutter ist ein Open-Source SDK für mobile Anwendungsentwicklung, das von Google erstellt wurde.

Von Flutter habe ich das erste mal in einem iOS-Dev Newsletter gelesen. Nach einem kurzen Blick habe ich dies jedoch naiv als yet another cross platform framework abgetan. (Weshalb ich nichts von den bisherigen cross platform Ansätzen halte kann ich ja mal in einem separaten Artikel erläutern).

Doch mein Arbeitskollege Frederik Schweiger, hat mich noch mal auf dieses Projekt aufmerksam gemacht und meine Leidenschaft dafür angefacht.

Flutter verkauft sich selber zwar als Tool um iOS und Android Apps mit nur einer Code-Basis zu erstellen, jedoch sehe ich dies nicht als den selling point.

Für mich ist Flutter eine neue und moderne Art (iOS) Apps zu entwickeln. Die cross platform Eigenschaft sehe ich lediglich als schönen Nebeneffekt an.
Jedoch finde ich auch, dass Flutter die erste benutzbare cross platform Lösung ist.

Die eigentlichen selling points sind:

• Fast Development
• Expressive and Flexible UI
• Native Performance

Siehe: https://flutter.io

Fast Development

Die Entwicklung geht unglaublich schnell. Die compile Zeiten sind jenseits von Swift, quasi instantan. Zu dem gibt es das Features des stateful Hot Reloads, dass einem ermöglicht die UI zu verändern und interaktiv zu entwickeln ohne immer wieder zur selben View zu navigieren und den gewünschten Zustand manuell herbeizuführen.

Widget UI

Die UI in Flutter is Widget basiert. React(-Native) Entwickler kennen dies bereits in form von components.

Auch wenn leider in der iOS-Entwicklung massive view controller recht verbreitet sind, habe ich immer gerne diesen kleinteiligen wiederverwendbaren Komponenten Ansatz verfolgt.

Alles sichtbare und interaktive ist ein Widget, selbst der root der App. Die Widgets sind in einem Tree strukturiert. StatelessWidget sind unveränderlich, was bedeutet, dass sich ihre Eigenschaften nicht ändern können. Alle Werte sind endgültig. StatefulWidget behalten ihren Zustand bei, der sich während der Lebensdauer des Widgets ändern kann.

Dieser code ist eine ganze App.

import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Welcome to Flutter',
      home: Scaffold(
        appBar: AppBar(
          title: Text('Welcome to Flutter'),
        ),
        body: Center(
          child: Text('Hello World'),
        ),
      ),
    );
  }
}

Eigene Widgets

Eigene Widgets baut man aus bestehenden Widgets zusammen (Composition). Dies können sichtbare Elemente wie Text sein aber auch reine Layout Elemente wie z.B. Center oder Row/Column (UIStackView).

Dabei unterscheidet man zwischen Stateful- und Stateless Widgets.
StatelessWidget erzeugen die UI auf basis der Konfiguration. StatefulWidget hingegen bestehen aus dem veränderlichen State und dem eigentlichen Widget. Wenn der State sich ändert, wird die UI neu gerendert.

Animation

Animationen sind in Flutter recht einfach umzusetzen.

Dazu braucht ein StatefulWidget einen AnimationController und Tweens. Der AnimationController definiert die interpolation der Frames. Ein Tween erzeugt die werte für einen Frame. Diese Werte können dann im Widget zur Konfiguration der UI genutzt werden. Die strikte Trennung führt zu einem sauberen code.

Expressive and Flexible UI

Flutter hat von Haus aus zwei Design Bibliotheken. Einerseits das in Android angewandte Google Material Design und Cupertino, welches eine (exakte) Kopie der iOS UIKit Elemente ist. Somit hat man ein natives look and feel, anders als es bei Frameworks wie Ionic ist, bei dem man das HTML direkt erkennt.

Native Performance

Da das rendering mittels der C++ Library Scia umgesetzt ist, steht die performance den ORM Implementierungen in nichts nach. Dabei stellt die host App nur einen UIViewController (iOS) oder eine Activity (Android) bereit in der Scia dann rendert.

Dart

Wie man bereits erkennen konnte, setzt Flutter auf Dart als Programmiersprache. Auch wenn ich dart nicht besonders schön finde (Semikolons?!), habe ich ja bereits eingangs erwähnt das man sich nicht auf seine Lieblingssprache festbeißen sollte und die Zweckdienlichkeit im blick haben muss.

Fazit

Meine anfängliche Skepsis ist in Begeisterung für Flutter umgeschwenkt. Mich würde es nicht wundern, wenn dies die Zukunft der (mobilen) App Entwicklung ist. Ich habe hier lediglich einen kleinen Überblick niedergeschrieben.

Am schönsten finde ich, wie elegant der Modulare Komponenten basierte UI code ist. Und wie schnell man zu Ergebnissen kommt. Da zeigt sich auch die stärke für das Prototyping.

Was sind eure DevTrends 2018 und wie findet ihr Elixir und Flutter? Schreibt mir doch auf Twitter @ugoarangino.