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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

2 https://www.thomaskuenneth.eu/ questions@thomaskuenneth.eu @tkuenneth https://github.com/tkuenneth/imperative_vs_declarative_uis

Slide 3

Slide 3 text

3 • Viele UI-Frameworks sind objektorientiert • Zur Entwicklungszeit wird jede UI- Komponente durch eine Klasse repräsentiert • Zur Laufzeit ist Oberﬂäche ein Objektgraph (c) Thomas Künneth

Slide 4

Slide 4 text

4 https://unsplash.com/photos/E75ZuAIpCzo • Änderungen der Oberﬂäche durch Manipulation der Objekteigenschaften • Für Interaktion werden Callbacks / Listener registriert • Holen und ggf. Halten von Referenzen auf benötigte Objekte

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Slide 7

Slide 7 text

• Enge Kopplung von Daten und Logik • Code zum Bau der Oberﬂächen bläht Quelltexte auf • Zusammenhänge schon im Kleinen nicht leicht zu erfassen 7 (c) Thomas Künneth

Slide 8

Slide 8 text

• Trennung von Oberﬂäche und Code • Verschlankt Quelltexte • Macht Oberﬂächen leichter… • designbar • wiederverwendbar 8 https://unsplash.com/photos/nVqNmnAWz3A

Slide 9

Slide 9 text

• Oberﬂächenbeschreibung in eigener Datei • Wird zu Objektgeﬂecht oder Datenstrukturen entfaltet • Referenzen auf Objekte oder Strukturen holen und halten • Nach Bedarf Objekte oder Strukturen manipulieren 9 https://unsplash.com/photos/62H_swdrc4A

Slide 10

Slide 10 text

• 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

Slide 11

Slide 11 text

Slide 12

Slide 12 text

12 https://unsplash.com/photos/466ENaLuhLY • Wirkt elegant • Haben viele moderne UI-Frameworks übernommen: • Android: XML • JavaFX: FXML • macOS/iOS: Storyboard • WPF, Xamarin: XAML

Slide 13

Slide 13 text

13 • Entwicklung zeigt:   Löst nur Vermischung von Oberﬂächenbeschreibung und Code • Um Code nachhaltig zu verbessern, sind zusätzlich Entwurfsmuster nötig • Je nach Framework:  MVP, MVVM, MVC, … (c) Thomas Künneth

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

• 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

Slide 18

Slide 18 text

• Stattdessen: • Wie soll Oberﬂäche jetzt aussehen? • Welche Elemente sind zu sehen? • Wie sind diese beschaﬀen? • Weg dorthin Sache des Frameworks • Vorreiter Web: React mit Virtual DOM 18 (c) Thomas Künneth

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

21 • Gesamte Oberﬂäche wird aus Widgets zusammengesetzt • Bau der Oberﬂäche wird durch Zustandsänderungen ausgelöst • Unterscheidung zwischen zustandslosen und -behafteten Widgets (c) Thomas Künneth

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 • Zustandslose Widgets überschreiben build() • Zustandsbehaftete überschreiben createState() (c) Thomas Künneth

Slide 24

Slide 24 text

Slide 25

Slide 25 text

• Alles ist eine View • Views bilden Hierarchien • Grundlegende Layouts mit HStack, VStack und ZStack 25 (c) Thomas Künneth

Slide 26

Slide 26 text

• Views werden nicht direkt referenziert • UI-Änderungen nach Zustandsänderungen • Daten werden mit @State gekennzeichnet 26 (c) Thomas Künneth

Slide 27

Slide 27 text

• Modiﬁer ersetzen Views (z. B. .font(.largeTitle)) • Ersetzungen sind auch auf Eltern- Views möglich • Kinder können Eltern „überschreiben“ 27 (c) Thomas Künneth

Slide 28

Slide 28 text

Slide 29

Slide 29 text

29 • Basiert auf Material Design • Hierarchien • Einfache Layouts mit Row und Column (c) Thomas Künneth

Slide 30

Slide 30 text

30 • Grundbausteine sind composable functions • Werden mit @Compose annotiert (c) Thomas Künneth

Slide 31

Slide 31 text

31 • Zustand mit remember { } merken • Änderungen führen zum Aufruf des Composables (c) Thomas Künneth

Slide 32

Slide 32 text

Slide 33

Slide 33 text

• Frameworks entwickeln sich noch recht schnell weiter • Oberﬂächengestaltung wieder mehr „Entwicklersache“ • Weniger „Feintuning“ zentrale Idee hinter deklarativen UIs 33 https://unsplash.com/photos/ij5_qCBpIVY

Slide 34

Slide 34 text

• Schnelle Entwicklungszyklen • Schlanker Code • Vorschau in IDE oder Hot Reload • Statische Codeanalyse auch für Oberﬂächen 34 https://unsplash.com/photos/HUJDz6CJEaM

Slide 35

Slide 35 text

• 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

Slide 36

Slide 36 text

36 (c) Thomas Künneth Vielen Dank https://www.thomaskuenneth.eu/ questions@thomaskuenneth.eu @tkuenneth