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. 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
  2. 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
  3. 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
  4. 6

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

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

  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
  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
  12. 15

  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
  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
  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
  16. 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
  17. 22 • Widgets sind Klassen • Um Aussehen zu ändern,

    nicht ableiten sondern kombinieren https://unsplash.com/photos/bu-6kNWQj6U
  18. 24

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

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

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

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

    Layouts mit Row und Column (c) Thomas Künneth
  24. 31 • Zustand mit remember { } merken • Änderungen

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

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

    oder Hot Reload • Statische Codeanalyse auch für Oberflächen 34 https://unsplash.com/photos/HUJDz6CJEaM
  28. • 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