Deklarativ vs. Imperativ
Apples neues UI-Framework SwiftUI geht in vielerlei Hinsicht neue Wege. Eines der wohl auffälligsten Merkmale stellt hierbei die neue deklarative Syntax dar, mit der Views in SwiftUI erstellt werden.
Doch manch einer mag sich an dieser Stelle fragen: Was soll „deklarativ“ eigentlich konkret bedeuten? Und wie unterscheidet sich dieser Ansatz – auch in technischer Hinsicht – von dem, was man bisher aus der Arbeit mit AppKit, UIKit und WatchKit her kennt?
Status Quo: Imperative Programmierung
Bevor wir uns weiter mit dem Begriff „deklarativ“ auseinandersetzen, möchte ich ein paar Worte darüber verlieren, wie Views unter AppKit, UIKit und WatchKit erstellt werden. Hier tut sich nämlich bereits der große Unterschied im Vergleich zur Programmierung mit SwiftUI auf.
Erstellen wir Views auf Basis der altbekannten Frameworks wie UIKit, gehen wir hierbei imperativ vor. Imperativ bedeutet in diesem Kontext, dass wir Views durch die Ausführung verschiedener Befehle erstellen. Durch Aneinanderreihung mehrerer solcher Befehle entsteht eine View.
Man denke hierbei nur an die Methode addSubview(_:) der Klasse UIView. Erstellt man eine UIKit-View im Code, nutzen wir diese Methode, um nach und nach die verschiedenen Bestandteile für unsere View zu definieren und hinzuzufügen. Wir nutzen diese Befehle aktiv und bestimmen durch ihre Aufrufe das Aussehen und Verhalten einer Ansicht. Genau dieses Vorgehen bezeichnet man als imperativ.
Kurz zusammengefasst: Wir rufen Methoden auf, über die eine View erzeugt wird.
Der SwiftUI-Weg: Deklarative Programmierung
Wer schon einmal mit SwiftUI gearbeitet hat, weiß, dass das Vorgehen beim Erstellen von Views damit ein wenig anders ist. In SwiftUI rufen wir keine Methoden auf, um Ansichten zu konfigurieren und zu erstellen. Stattdessen definieren wir durch Gruppierung der gewünschten Elemente, wie eine View aussieht und wie sie aufgebaut ist.
Ein sehr wichtiges Element nimmt in diesem Konzept der Status einer View ein. Ein solcher ist maßgeblich für das Aussehen und die Funktionsweise einer View in SwiftUI verantwortlich. Ändert sich der Status, wird die zugehörige View automatisch vom System neu erzeugt.
Durch dieses Prinzip müssen wir selbst nicht aktiv einen Refresh von Views anstoßen, wie es bei der Arbeit mit AppKit, UIKit und WatchKit notwendig ist. Betrachten wir als Beispiel den Einsatz eines Schalters, der einen bestimmten booleschen Wert steuert. In der imperativen Programmierung müssen wir, nachdem der Schalter betätigt wurde, selbsttätig alle Views aktualisieren, die auf diese Änderung mit einem Update reagieren müssen. Hier zeigt sich wieder der klassische imperative Ansatz: Wir müssen selbst aktiv werden, um das Aussehen unserer Views korrekt festzulegen.
In SwiftUI hingegen übernimmt der Status automatisch jede notwendige Aktualisierung für uns. Ist der im beschriebenen Beispiel genannte Schalter mit einem entsprechenden Status verknüpft, werden alle zugehörigen Views automatisch aktualisiert, wenn sich jener Status durch Betätigen des Schalters ändert; es muss keinerlei Aktualisierung händisch von uns selbst angestoßen werden.
Genau das ist ebenfalls ein wichtiger Bestandteil des deklarativen Ansatzes von SwiftUI. Views sind ein Zustand ihres Status und werden automatisch aktualisiert, sollte sich jener Status ändern.
Fazit
Hat man einmal den grundlegenden Unterschied zwischen der imperativen und der deklarativen Programmierung von Views verinnerlicht, fällt auch die Arbeit mit SwiftUI deutlich leichter. Man braucht entsprechend unter SwiftUI nicht nach Refresh-Methoden zu suchen, mit denen man Views händisch aktualisiert; das übernimmt automatisch ein Status für uns. Zweifelsohne ist das aber ein sehr ungewohntes Vorgehen, wenn man bereits mit der imperativen Programmierung von Views vertraut ist, wie sie in AppKit, UIKit und WatchKit zum Einsatz kommt.
Euer Thomas
Schreibe einen Kommentar