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
   

   View Slide

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

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

6. View Slide

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
   

   View Slide

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

   View Slide

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
   

   View Slide

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
    

    View Slide

11. View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

15. View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

24. View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

28. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

32. View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide