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.

6233177bc63ec02060206adef9108601?s=128

Thomas Künneth

October 26, 2020
Tweet

Transcript

  1. Imperativ war gestern Mit deklarativen UI-Frameworks in die Zukunft Thomas

    Künneth, MATHEMA 1 (c) Thomas Künneth
  2. 2 https://www.thomaskuenneth.eu/ questions@thomaskuenneth.eu @tkuenneth https://github.com/tkuenneth/imperative_vs_declarative_uis

  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
  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
  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
  6. 6

  7. • 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
  8. • Trennung von Oberfläche und Code • Verschlankt Quelltexte •

    Macht Oberflächen leichter… • designbar • wiederverwendbar 8 https://unsplash.com/photos/nVqNmnAWz3A
  9. • 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
  10. • 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
  11. 11

  12. 12 https://unsplash.com/photos/466ENaLuhLY • Wirkt elegant • Haben viele moderne UI-Frameworks

    übernommen: • Android: XML • JavaFX: FXML • macOS/iOS: Storyboard • WPF, Xamarin: XAML
  13. 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
  14. 14 https://unsplash.com/photos/i--IN3cvEjg

  15. 15

  16. 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
  17. • 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
  18. • 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
  19. • Flutter (2015) • SwiftUI (2019) • Jetpack Compose (2019)

    19 (c) Thomas Künneth
  20. 20 • Keine nativen UI-Elemente • Material Design und Cupertino

    Widgets (c) Thomas Künneth
  21. 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
  22. 22 • Widgets sind Klassen • Um Aussehen zu ändern,

    nicht ableiten sondern kombinieren https://unsplash.com/photos/bu-6kNWQj6U
  23. 23 • Zustandslose Widgets überschreiben build() • Zustandsbehaftete überschreiben createState()

    (c) Thomas Künneth
  24. 24

  25. • Alles ist eine View • Views bilden Hierarchien •

    Grundlegende Layouts mit HStack, VStack und ZStack 25 (c) Thomas Künneth
  26. • Views werden nicht direkt referenziert • UI-Änderungen nach Zustandsänderungen

    • Daten werden mit @State gekennzeichnet 26 (c) Thomas Künneth
  27. • 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
  28. 28

  29. 29 • Basiert auf Material Design • Hierarchien • Einfache

    Layouts mit Row und Column (c) Thomas Künneth
  30. 30 • Grundbausteine sind composable functions • Werden mit @Compose

    annotiert (c) Thomas Künneth
  31. 31 • Zustand mit remember { } merken • Änderungen

    führen zum Aufruf des Composables (c) Thomas Künneth
  32. 32

  33. • 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
  34. • Schnelle Entwicklungszyklen • Schlanker Code • Vorschau in IDE

    oder Hot Reload • Statische Codeanalyse auch für Oberflächen 34 https://unsplash.com/photos/HUJDz6CJEaM
  35. • 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
  36. 36 (c) Thomas Künneth Vielen Dank https://www.thomaskuenneth.eu/ questions@thomaskuenneth.eu @tkuenneth