Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Imperativ war gestern - Mit deklarativen UI-Frameworks in die Zukunft

Imperativ war gestern - Mit deklarativen UI-Frameworks in die Zukunft

In vielen UI Frameworks besteht die Oberfläche aus komplexen baumartigen Strukturen. Sollen Elemente hinzukommen, wegfallen, oder zum Beispiel ihre Farbe oder Text ändern, muss der Entwickler das vollständig implementieren. Apps werden schnell unübersichtlich und damit fehleranfällig. Besser ist es, die Oberfläche auf Basis des aktuellen Zustands zu beschreiben. Ob dann Komponenten manipuliert, gelöscht oder neu erzeugt werden, ist Sache des Frameworks und dem Entwickler egal. Solche deklarativen Ansätze sind leichter les- und wartbar. Man kann davon ausgehen, dass SwiftUI, Jetpack Compose, Flutter und Co. über kurz oder lang klassische imperative Frameworks verdrängen. Diese Night Session stellt die wichtigsten deklarativen Frameworks vor.

Thomas Künneth

October 26, 2020
Tweet

More Decks by Thomas Künneth

Other Decks in Programming

Transcript

  1. Imperativ war
    gestern
    Mit deklarativen UI-Frameworks
    in die Zukunft
    Thomas Künneth, MATHEMA
    1
    (c) Thomas Künneth

    View full-size slide

  2. 2
    https://www.thomaskuenneth.eu/
    [email protected]
    @tkuenneth
    https://github.com/tkuenneth/imperative_vs_declarative_uis

    View full-size slide

  3. 3
    • Viele UI-Frameworks sind
    objektorientiert

    • Zur Entwicklungszeit wird jede UI-
    Komponente durch eine Klasse
    repräsentiert

    • Zur Laufzeit ist Oberfläche ein
    Objektgraph
    (c) Thomas Künneth

    View full-size slide

  4. 4
    https://unsplash.com/photos/E75ZuAIpCzo
    • Änderungen der Oberfläche durch
    Manipulation der Objekteigenschaften

    • Für Interaktion werden Callbacks /
    Listener registriert

    • Holen und ggf. Halten von Referenzen
    auf benötigte Objekte

    View full-size slide

  5. 5
    https://unsplash.com/photos/QgeIMfZJgFs
    • Spezialisierung durch Vererbung

    • Verhaltensänderungen durch
    Überschreiben

    • ✔ Praktisch bei kleinen Anpassungen

    • ⚠ Frameworks mögen Ableitungen
    nicht immer
    java.lang.Object
    java.awt.Component
    java.awt.Container
    javax.swing.JComponent
    javax.swing.AbstractButton
    javax.swing.JButton

    View full-size slide

  6. • Enge Kopplung von Daten und Logik

    • Code zum Bau der Oberflächen bläht
    Quelltexte auf

    • Zusammenhänge schon im Kleinen
    nicht leicht zu erfassen
    7
    (c) Thomas Künneth

    View full-size slide

  7. • Trennung von Oberfläche und Code

    • Verschlankt Quelltexte

    • Macht Oberflächen leichter…

    • designbar

    • wiederverwendbar
    8
    https://unsplash.com/photos/nVqNmnAWz3A

    View full-size slide

  8. • Oberflächenbeschreibung in eigener
    Datei

    • Wird zu Objektgeflecht oder
    Datenstrukturen entfaltet

    • Referenzen auf Objekte oder
    Strukturen holen und halten

    • Nach Bedarf Objekte oder Strukturen
    manipulieren
    9
    https://unsplash.com/photos/62H_swdrc4A

    View full-size slide

  9. • Wurde von einigen sehr frühen
    grafischen Oberflächen so gehandhabt

    • GEM (Graphics Environment Manager)
    von Digital Research

    • Oberflächenbeschreibung in
    Resourcedateien (.rsc)

    • Laden mit rsrc_load()

    • rsrc_gaddr() liefert Adresse im
    Speicher
    10
    https://unsplash.com/photos/62H_swdrc4A

    View full-size slide

  10. 12
    https://unsplash.com/photos/466ENaLuhLY
    • Wirkt elegant

    • Haben viele moderne UI-Frameworks
    übernommen:

    • Android: XML

    • JavaFX: FXML

    • macOS/iOS: Storyboard

    • WPF, Xamarin: XAML

    View full-size slide

  11. 13
    • Entwicklung zeigt: 

    Löst nur Vermischung von
    Oberflächenbeschreibung und Code

    • Um Code nachhaltig zu verbessern,
    sind zusätzlich Entwurfsmuster nötig

    • Je nach Framework:

    MVP, MVVM, MVC, …
    (c) Thomas Künneth

    View full-size slide

  12. 14
    https://unsplash.com/photos/i--IN3cvEjg

    View full-size slide

  13. 16
    • Jede Änderung erfolgt durch Ändern
    von Objekt- bzw. Strukturattributen

    • Entwickler muss Weg von Ist- zu
    Sollzustand kennen

    • Und implementieren

    • Je größer die Änderung, desto
    aufwendiger (c) Thomas Künneth

    View full-size slide

  14. • Entwickler vom Wissen um
    „Wegbeschreibung“ entlasten

    • Also nicht mehr…

    • Wie muss ich Farbe von xyz ändern,
    damit…?

    • Welche Objekte muss ich hinzufügen
    oder löschen, damit…?
    17
    https://unsplash.com/photos/fteR0e2BzKo

    View full-size slide

  15. • Stattdessen:

    • Wie soll Oberfläche jetzt aussehen?

    • Welche Elemente sind zu sehen?

    • Wie sind diese beschaffen?

    • Weg dorthin Sache des Frameworks

    • Vorreiter Web: React mit Virtual DOM
    18
    (c) Thomas Künneth

    View full-size slide

  16. • Flutter (2015)

    • SwiftUI (2019)

    • Jetpack Compose (2019)
    19
    (c) Thomas Künneth

    View full-size slide

  17. 20
    • Keine nativen UI-Elemente

    • Material Design und Cupertino
    Widgets
    (c) Thomas Künneth

    View full-size slide

  18. 21
    • Gesamte Oberfläche wird aus Widgets
    zusammengesetzt

    • Bau der Oberfläche wird durch
    Zustandsänderungen ausgelöst

    • Unterscheidung zwischen
    zustandslosen und -behafteten
    Widgets
    (c) Thomas Künneth

    View full-size slide

  19. 22
    • Widgets sind Klassen

    • Um Aussehen zu ändern, nicht ableiten
    sondern kombinieren
    https://unsplash.com/photos/bu-6kNWQj6U

    View full-size slide

  20. 23
    • Zustandslose Widgets überschreiben
    build()

    • Zustandsbehaftete überschreiben
    createState()
    (c) Thomas Künneth

    View full-size slide

  21. • Alles ist eine View

    • Views bilden Hierarchien

    • Grundlegende Layouts mit HStack,
    VStack und ZStack
    25
    (c) Thomas Künneth

    View full-size slide

  22. • Views werden nicht direkt referenziert

    • UI-Änderungen nach
    Zustandsänderungen

    • Daten werden mit @State
    gekennzeichnet
    26
    (c) Thomas Künneth

    View full-size slide

  23. • Modifier ersetzen Views (z.
    B. .font(.largeTitle))

    • Ersetzungen sind auch auf Eltern-
    Views möglich

    • Kinder können Eltern „überschreiben“
    27
    (c) Thomas Künneth

    View full-size slide

  24. 29
    • Basiert auf Material Design

    • Hierarchien

    • Einfache Layouts mit Row und Column
    (c) Thomas Künneth

    View full-size slide

  25. 30
    • Grundbausteine sind composable
    functions

    • Werden mit @Compose annotiert
    (c) Thomas Künneth

    View full-size slide

  26. 31
    • Zustand mit remember { } merken

    • Änderungen führen zum Aufruf des
    Composables
    (c) Thomas Künneth

    View full-size slide

  27. • Frameworks entwickeln sich noch
    recht schnell weiter

    • Oberflächengestaltung wieder mehr
    „Entwicklersache“

    • Weniger „Feintuning“ zentrale Idee
    hinter deklarativen UIs
    33
    https://unsplash.com/photos/ij5_qCBpIVY

    View full-size slide

  28. • Schnelle Entwicklungszyklen

    • Schlanker Code

    • Vorschau in IDE oder Hot Reload

    • Statische Codeanalyse auch für
    Oberflächen
    34
    https://unsplash.com/photos/HUJDz6CJEaM

    View full-size slide

  29. • Entwickler müssen umdenken

    • Vermeiden von Fehlern durch
    Reduzieren von Boilerplate-Code

    • Nach kurzer Eingewöhnung hohe
    Produktivität
    35
    https://unsplash.com/photos/j06gLuKK0GM

    View full-size slide

  30. 36
    (c) Thomas Künneth
    Vielen Dank
    https://www.thomaskuenneth.eu/
    [email protected]
    @tkuenneth

    View full-size slide