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.

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