Notifications: iOS-Entwicklung mit MVC (Model-View-Controller)
App-Entwicklung ist ein spannendes und zugleich auch sehr kreatives Feld. Für so gut wie jede Problemstellung gibt es nicht nur "die eine" Lösung, oftmals führen viele verschiedene Wege zum Ziel. Doch wo es viele verschiedene Lösungsansätze gibt, sind nicht alle auch tatsächlich gut und fügen sich sauber in die Programmierung für eine spezifische Plattform ein.
Aus diesem Grund gibt es in der Softwareentwicklung allgemein die verschiedensten Design-Pattern, die beschreiben und festlegen, wie Code strukturiert und aufgebaut wird. Zu diesen Pattern gehört auch MVC (kurz für "Model-View-Controller"). Es spielt unter anderem in der iOS-Entwicklung eine essenzielle Rolle, nicht zuletzt aufgrund der Tatsache, dass Apple – der Hausherr über diese Plattform – selbst in seinen grundlegenden Frameworks auf MVC setzt und somit die gesamte Code-Basis in der iOS-Entwicklung im Hinblick auf MVC entwickelt und designt wurde.
Warum MVC so wichtig ist
Bevor ich nun damit anfange, MVC in Bezug auf die iOS-Entwicklung im Detail vorzustellen, möchte ich kurz vorausschicken, warum MVC eigentlich so wichtig für uns iOS-Entwickler ist und warum sich jeder App-Entwickler damit im Detail auseinandersetzen sollte.
Wie im vorherigen Abschnitt bereits kurz erwähnt, sind Pattern wie MVC dazu gedacht, eine grundlegende gemeinsame Struktur für den eigenen Code zu definieren. Halten wir uns an derartige Pattern, hat das zur Folge, das sich auch andere Entwickler, die ebenfalls mit diesen Pattern vertraut sind und diese selbst anwenden, sich schneller im eigenen Code zurechtfinden und leichter nachvollziehen können, wie und warum etwas funktioniert und implementiert ist. Umgekehrt wird ein Schuh daraus, nämlich dann, wenn Entwickler derartige Design-Pattern ignorieren und ihren Code so schreiben und strukturieren, wie sie es selbst für richtig und sinnvoll halten (und dabei die Eigen- und Besonderheiten der jeweiligen Plattform außer Acht lassen). Das führt schnell zu unübersichtlichem Spaghetti-Code und erschwert es anderen Entwicklern, in solch einem Code zurechtzukommen.
Sie sehen also schon: Pattern in der Softwareentwicklung sind wichtig. Und Apple setzt in iOS stark auf MVC, gerade auch bei all den hauseigenen Frameworks, mit denen iOS-Entwickler tagtäglich zu tun haben. Nur, wer die Prinzipien und die Funktionsweise von MVC grundlegend versteht, begreift auch, wie bestimmte Funktionen in der iOS-Entwicklung arbeiten und ist darüber überhaupt erst in der Lage, selbst sauberen und gut strukturierten Code für iOS zu schreiben.
Model-View-Controller (MVC): Eine Einführung
Mit diesen Vorworten aber nun ohne Umschweife weiter mit den Grundlagen des MVC-Pattern. Wie bereits geschrieben stehen die drei Buchstaben für Model, View und Controller. Damit werden die Klassen eines jeden iOS-Projekts bezeichnet, die sich idealerweise genau einem dieser drei Elemente zuordnen lassen.
Als Model wird dabei die eigentliche Logik und die Datenhaltung einer App bezeichnet. Model-Klassen regeln Zugriffe auf das Dateisystem oder auf Datenbanken und beschreiben, wie die interne Logik einer App aussieht. Bei einer Addressbuch-App würde das Model beispielsweise beschreiben, welche Informationen zu einem Kontakt gespeichert werden können und wie die Kontakte intern in der App verwaltet werden.
Eine View ist das genaue Gegenstück zum Model. Während das Model sich um die nach außen hin nicht sichtbare Logik kümmert, dienen die Views zur Darstellung von Elementen auf der Oberfläche. Schaltflächen, Textansichten, Labels; all das sind Views, die wir in der iOS-Entwicklung verwenden können. Dabei zeichnet Views aus, dass diese keinerlei Information über die zugrundeliegende Logik einer App (also das Model) besitzen. Views regeln einzig und allein, wie etwas aussieht, nicht aber, welche Informationen sie anzeigen. Nehmen wir als Beispiel ein Label. Ein Label legt einfach nur fest, wie ein Text aussieht; welche Schriftfarbe und -art werden verwendet? Wie groß ist das Label? Das sind Dinge, die ein Label definiert. Welcher Text angezeigt wird, ist dem Label dabei egal. Diese Information ist von Label zu Label unterschiedlich. Diese strikte Trennung erlaubt es uns, Labels immer und immer wieder in unterschiedlichen Projekten zu verwenden, ohne für jeden Inhalt auch eine eigene Label-Klasse erstellen zu müssen. Genau hier zeigt sich bereits der große Vorteil und der Schwerpunkt, den das MVC-Pattern ausmacht, doch dazu gleich mehr.
Bleibt zu guter Letzt noch der Controller. Der Controller kann als Bindeglied zwischen View und Model verstanden werden. Controller bringen diese beiden Elemente zusammen und schließen somit die Lücke zwischen der reinen Logik einer App und deren Oberfläche.
Betrachten wir dabei zur Verdeutlichung noch einmal das bereits genannte Beispiel einer Addressbuch-App: Ein Controller könnte darin alle Kontakte (das Model) auslesen und in einer Tabelle (die View) dem Nutzer anzeigen. Beides für sich betrachtet – ein Kontakt und eine Tabelle – funktionieren unabhängig voneinander und können so auch problemlos in andere Projekte übernommen werden. Kontakte können dann auch in einer App für ein soziales Netzwerk verwendet werden und eine Tabelle andere Inhalte anzeigen. Wie genau eben jenes Zusammenspiel ausschaut, regelt ein Controller.
Wiederverwendbarkeit dank MVC
Dieses grundlegende Prinzip ist das wichtigste Paradigma bei der Arbeit mit MVC: Nur ein Controller erhält Zugriff auf Model und View. Model-Klassen sollen nur Zugriff auf andere Model-Klassen besitzen, genauso wie Views nur Zugriff auf andere View-Klassen haben sollen. Diese strikte Trennung erlaubt es, Model- und View-Klassen leicht wiederzuverwenden und in verschiedenen Projekten für unterschiedliche Zwecke einzusetzen. Genau so ist es schließlich auch bei den verschiedenen View- und Model-Klassen, die Teil des Foundation- oder UIKit-Framework von Apple sind. Man stelle sich vor, man müsste für jeden Button eine eigene Klasse erstellen, in der festgelegt ist, was der Button tut. Dank MVC ist das nicht nötig. Ein Button ist damit eine View, und was ein Button nun genau tut, legt ein zugeordneter Controller fest. Soll an einer anderen Stelle eine andere Aktion von einem Button aus ausgeführt werden, so wird ein zweiter passender Controller erstellt, der die gewünschte Aktion festlegt und implementiert; eine neue separate Button-Klasse ist dafür nicht notwendig, es kann dieselbe Button-Ansicht wie zuvor verwendet werden, und dennoch ist die durchzuführende Aktion eine andere.
Während somit die Model- und View-Klassen nach dem MVC-Pattern die Elemente sind, die problemlos in verschiedenen Projekten wiederverwendet werden können, sind die Controller der Teil des MVC-Codes, der am wenigsten an anderer Stelle wiederverwendet werden kann. Das liegt daran, dass Controller sehr spezifischen Code enthalten und festlegen, wie Model und View verwendet werden. Das ist aber auch nicht weiter tragisch und ist durch das Pattern bedingt.
Kommunikation im MVC-Pattern
Nun haben wir sehr viel über das MVC-Pattern gelesen und wissen, wofür es gut ist und wo seine spezifischen Vorteile liegen und warum es in der iOS-Entwicklung so wichtig ist. Bevor es nun an die Anwendung von MVC in der iOS-Programmierung geht, bleibt noch eine letzte wichtige Frage zu klären: Wie kommunizieren denn Controller-Klassen mit Model und View? Schließlich wissen wir jetzt, das Model und View nie direkt miteinander kommunizieren sollen und stattdessen hier der Controller als Bindeglied fungiert. Doch wie tut er das? Wie teilt eine View einem Controller mit, das sie betätigt wurde? Und wie kann das Model den Controller beispielsweise darüber informieren, das es neue Datensätze aus dem Internet geladen hat?
Hier kommen die verschiedenen Kommunikationswege des MVC-Pattern ins Spiel. Derer gibt es typischerweise vier:
- Eine View informiert ihren Controller über eine Aktion, die mit oder auf ihr ausgeführt wurde.
- Ein Model informiert seinen Controller über mögliche Änderungen in der Datenhaltung.
- Ein Controller hat Zugriff auf seine View und kann diese aktualisieren.
- Ein Controller hat Zugriff auf sein Model und kann dieses aktualisieren.
Diese kleine Übersicht zeigt erneut, wie essenziell wichtig der Controller für die Kommunikation zwischen View und Model ist; ohne ihn würden nach MVC-Pattern die Objekte von View- und Model-Klassen niemals miteinander kommunizieren können. Abb.1 verdeutlicht noch einmal die Kommunikationswege zwischen den drei Elementen Model, View und Controller des MVC-Patterns.
Bei MVC gibt es also nur zwei Arten von Kommunikationswegen: Zwischen Controller und Model und zwischen Controller und View. Und genau diese beiden betrachten wir nun einmal im Detail.
Kommunikation zwischen Model und Controller
In der iOS-Entwicklung gibt es zwei Techniken, um die Kommunikation zwischen Model und Controller zu ermöglichen. Ich möchte dabei auch direkt vorausschicken, das die genannten Techniken auch an anderer Stelle im Code eines iOS-Projekts verwendet und implementiert werden können, beispielsweise auch bei der Kommunikation zwischen mehreren verschiedenen Controllern oder zwischen verschiedenen Model-Objekten. Sie sind allerdings unabdingbar und essenziell für eben jene wichtige Kommunikation zwischen Model und Controller und müssen dort in jedem Fall verwendet werden.
Die erste Technik beschreibt eine iOS-typische Möglichkeit, Objekte über bestimmte Aktionen zu informieren. Es handelt sich dabei um die sogenannten Notifications. Eine Notification in iOS ist sehr einfach aufgebaut und verfügt mindestens über einen eindeutigen Titel, über den die Notification identifiziert und von anderen Notifications differenziert werden kann.
Wird nun auf Controller- oder Model-Seite eine bestimmte Aktion ausgelöst, über die man auch andere Objekte eines iOS-Projekts informieren möchte, so sendet man zusammen mit der entsprechenden Aktion eine Notification. Alle anderen Objekte des Projekts können sich für eben jene Notification registrieren und werden damit informiert, sobald besagte Notification gesendet wurde. Sie haben dann die Chance, eigene weitere Aktionen auszuführen und entsprechend auf das Event zu reagieren, welches die besagte Notification gesendet hat.
iOS und Notifications in der Praxis
Soweit einmal die Theorie von Notifications. In der Praxis spielen zwei Klassen des Foundation-Frameworks eine essenzielle Rolle bei der Arbeit mit Notifications: NSNotification und NSNotificationCenter.
Ein NSNotification-Objekt entspricht einer im vorherigen Abschnitt beschriebenen Notification. Es besteht aus mindestens einem eindeutigen Titel, über den die Notification im gesamten Projekt identifiziert werden kann. Darüber hinaus kann eine Notification zusätzlich auch aus einem optionalen Objekt und einem optionalen Dictionary mit weiteren Informationen bestehen. Diese Teile werden dann zusammen mit der Notification versendet und können von den Empfängern der Nachricht mit ausgewertet werden.
Das NSNotificationCenter ist als Singleton konzipiert, sprich es gibt in der Regel nur eine Instanz dieser Klasse in einem iOS-Projekt. Über dieses Singleton werden zwei Aufgaben geregelt: Einerseits werden über das NotificationCenter Notifications verschickt. Möchte also ein Objekt eine Notification senden, so wird diese dem NSNotificationCenter übergeben und dieses stellt die Nachricht im Projekt bereit. Auf der anderen Seite registrieren sich Objekte, die über den Eingang bestimmter Notifications informiert werden wollen, ebenfalls beim Singleton der Klasse NSNotificationCenter und geben dabei an, welche Methode ausgeführt werden soll, wird die registrierte Notification tatsächlich gesendet.
Notifications erstellen und senden
Betrachten wir zunächst einmal das Erstellen und Senden von Notifications. Für diesen Zweck bringt die Klasse NSNotification einen passenden Designated Initializer mit, über den eine vollständig konfigurierte Instanz einer NSNotification erzeugt werden kann:
init(name name: String, object object: AnyObject?, userInfo userInfo: [NSObject : AnyObject]?)
Der erste Parameter name entspricht dabei dem eindeutigen Namen der Notification. Dieser wird auch von allen Objekten, die über das Senden dieser Notification informiert werden möchten, für die zugehörige Registrierung verwendet. object ist ein optionaler Parameter, bei dem es sich um ein beliebiges Objekt handeln kann. Dieses Objekt wird gewissermaßen mit der Notification "verschickt", was es Empfängern der Notification erlaubt, dieses Objekt auszulesen und für ihre Zwecke zu verwenden.
userInfo zu guter Letzt ist ebenfalls ein optionaler Parameter. Dieses Dictionary kann genutzt werden, um zusammen mit der Notification weitere beliebige Informationen zu verschicken. Es hängt von Fall zu Fall ab, ob es sinnvoll und angebracht ist, ein solches Dictionary zu übergeben oder nicht.
Neben diesem Designated Initializer verfügt die Klasse NSNotification noch über einen vereinfachten Convenience Initializer:
convenience init(name aName: String, object anObject: AnyObject?)
Dieser nimmt lediglich den eindeutigen Namen und ein optionales Objekt für die Notification entgegen. Beim Initialisieren einer Notification über diesen Convenience Initializer wird das userInfo-Dictionary des Designated Initializers also in jedem Fall auf nil gesetzt und verfügt somit über keinen Wert. Dieser Convenience Initializer lohnt also immer dann, wenn das userInfo-Dictionary sowieso nicht gebraucht und gesetzt wird.
Eine simple Notification ohne userInfo-Dictionary lässt sich somit beispielsweise wie folgt erzeugen:
let myNotification = NSNotification(name: "MyNotification", object: nil)
Bleibt noch die Frage, wie nun eine solche Notification innerhalb einer App gesendet wird. Wie bereits geschrieben, kommt hierbei das Singleton der Klasse NSNotificationCenter zum Einsatz. Das Singleton kann mithilfe der Klassenmethode defaultCenter ausgelesen werden:
class func defaultCenter() -> NSNotificationCenter
Bei der Arbeit mit NSNotificationCenter wird standardmäßig immer dieses Singleton verwendet und darüber alle weiteren Aktionen des NSNotificationCenter ausgeführt.
Um nun ein NSNotification-Objekt im System zu senden, bringt NSNotificationCenter eine passende Instanzmethode mit. Die Deklaration dieser Methode lautet wie folgt:
func postNotification(_ notification: NSNotification)
Die Methode postNotification: nimmt das zu sendende NSNotification-Objekt entgegen und sendet es anschließend umgehend in der gesamten App.
Listing 1 zeigt einmal beispielhaft den kompletten Prozess vom Erstellen einer Notification und das anschließende Senden der Nachricht im System.
Listing 1: Erstellen und Senden einer einfachen Notification.
let myNotification = NSNotification(name: "MyNotification", object: nil) NSNotificationCenter.defaultCenter().postNotification(myNotification)
Empfangen von Notifications
Wir wissen also nun, wie wir Notifications erstellen und senden können. Bleibt noch die Frage, wie ein Objekt, das sich für eine bestimmte Notification interessiert, auf diese "lauschen" und beim Senden eben jener Nachricht eine eigene Aktion durchführen kann.
Essenziell hierbei ist erneut das Singleton der Klasse NSNotificationCenter. Die Klasse bringt eine Methode mit, mit deren Hilfe ein sogenannter Observer für eine Notification erstellt wird. Dieser Observer legt fest, welches Objekt bei welcher Notification welche Methode aufrufen soll. Die Deklaration dieser Methode lautet wie folgt:
func addObserver(_ observer: AnyObject, selector aSelector: Selector, name aName: String?, object anObject: AnyObject?)
Interessiert sich nun ein Objekt für eine bestimmte Notification, kann es diese Methode nutzen, um sich selbst für eben jene Notification zu registrieren. Betrachten wir dabei die Parameter dieser Methode einmal im Detail:
- observer: Der Observer ist das Objekt, welches über das Eintreffen einer spezifischen Notification informiert werden möchte. Wenn Sie diese Methode in der Klasse des Objekts aufrufen, das selbst über eben jene Notification informiert werden möchte, übergeben Sie hier als Parameter self.
- aSelector: Der Selector entspricht dem Namen der Methode, die bei Eingang der Notification auf dem als observer definierten Objekt aufgerufen werden soll. In Swift werden Observer als einfache Strings definiert. Dabei ist unbedingt darauf zu achten, den korrekten Methodennamen zu schreiben, da der Compiler durch dieses Verfahren keine Chance hat, die Zeichenkette gegen einen vorhandenen Methodennamen zu prüfen. Schleicht sich in der Zeichenkette ein Fehler ein und die entsprechende Methode existiert gar nicht, führt dies zum Absturz der App, sobald die entsprechende Notification gesendet wird.
- aName: Dieser Parameter entspricht dem Namen der Notification, über deren Senden der observer informiert werden soll. Hierbei mag es vielleicht verwundern, warum ausgerechnet dieser Parameter – der ja gerade als essenziell wichtig erscheint – als optional deklariert ist. Sollte für aName nil übergeben werden, so bedeutet das einfach, dass die in aSelector definierte Methode des observer bei jeder gesendeten Notification ausgeführt wird und nicht nur bei der spezifisch als aName definierten.
- anObject: Möchte man nur über das Senden von Notifications von einem ganz spezifischen Objekt informiert werden, so kann man dieses als anObject übergeben. Der aufzurufende Selector des observer wird sodann nur ausgeführt, wenn die gewünschte Notification von eben jenem Objekt aus gesendet wurde. Wird die Notification von einem anderen Objekt gesendet, greift der Selector nicht und wird auch nicht ausgeführt. In der Regel wird hier oftmals nil übergeben, was bedeutet, dass der Selector des observer-Objekts immer ausgeführt werden soll, wenn die gewünschte Notification gesendet wird; egal, von welchem Objekt das Senden ausgeht.
Sollen nun Objekte einer Klasse über das Senden einer bestimmten Notification informiert werden, so müssen diese sich an einer bestimmten Stelle im Code für eben jene Notification mit der genannten Methode registrieren. Typische Stellen für die Registrierung für Notifications sind beispielsweise Initializer oder – bei View-Controllern – die viewDidLoad-Methode. Eine einfache beispielhafte Registrierung für eine Notification mit dem Namen MyNotification kann wie folgt aussehen:
NSNotificationCenter.defaultCenter().addObserver(self, selector: "doSomething:", name: "MyNotification", object: nil)
In diesem Beispiel wird die Methode doSomething: aufgerufen, sobald an irgendeiner beliebigen Stelle im Code die Notification mit dem Namen MyNotification gesendet wird. Zu beachten ist dabei der Parameter, den die Methode doSomething: erwartet (zu erkennen am Doppelpunkt am Ende des Selectors). Dieser Parameter ist vom Typ NSNotification, was bedeutet, dass dieser Methode beim Aufruf das zugehörige NSNotification-Objekt übergeben wird, das beim Senden eben jeder Notification verwendet wurde. Das erlaubt es dieser Methode, weitere Informationen der Notification wie das optional mitgelieferte Objekt oder das userInfo-Dictionary auszulesen. Die Klasse NSNotification bringt für diesen Zweck drei Read-Only-Properties mit, um auf alle Informationen einer Notification zugreifen zu können:
- name: Der Name der Notification.
- object: Das optional mit der Notification "mitgelieferte" Objekt.
- userInfo: Das optional mit der Notification "mitgelieferte" userInfo-Dictionary.
Die Beispielmethode doSomething: kann in ihrer Implementierung auf all diese Informationen dank ihres Parameters zugreifen und diese auswerten und verwenden:
func doSomething(notification: NSNotification) {
print("Name: \(notification.name)")
print("Object: \(notification.object)")
print("User info: \(notification.userInfo)")
}Der Name des Parameters in der Methodendeklaration von doSomething: spielt dabei keine Rolle; Sie können jeden beliebigen Namen verwenden (in diesem Beispiel ist der Parametername auf notification gesetzt). Das Notification-System von iOS übergibt die zugrundeliegende Notification an eben jenen Parameter, den Sie dann innerhalb der Methode verwenden und auswerten können.
Optional können Sie auch auf die Übergabe eines NSNotification-Parameters beim Selector verzichten. In diesem Fall fällt der Doppelpunkt am Ende des Selectors weg, der auf einen Parameter hinweist. Dabei ist zusätzlich noch zu beachten, dass die zugehörige Methode selbst dann ebenfalls über keinem Parameter verfügen darf.
Absturz der App verhindern - Observer entfernen
Sie kennen nun die wichtigsten Klassen und Methoden sowie die Funktionsweise von Notifications. Zu guter Letzt möchte ich noch auf einen weiteren wichtigen Punkt hinweisen, der nicht umgehend ins Auge springt.
Registriert sich ein Objekt mittels der im vorigen Abschnitt vorgestellten Methode addObserver:selector:name:object: für den Empfang einer Notification, so wird diese Information im Singleton des NSNotificationCenter gespeichert. Diese Information bleibt auch dann noch vorhanden, wenn das Objekt, das sich für eine Notification registriert hat, gar nicht mehr existiert und aus dem Speicher entfernt wurde. Dieses Verhalten hat aber zur Folge, dass das Notification-Center beim Senden eben jener Notification trotzdem versucht, auch das bereits aus dem Speicher entfernte Objekt zu informieren und aufzurufen; was zu einem Absturz der App führt, schließlich existiert das gewünschte Objekt nicht mehr.
Daher ist es wichtig, dass Objekte, die sich für Notifications registrieren, sich auch genauso wieder vom Notification-Center abmelden, sobald sie sich nicht mehr für den Eingang eben jener Notifications interessieren. Typischerweise ist das spätestens dann der Fall, wenn das betroffene Objekt aus dem Speicher entfernt wird.
Zu diesem Zweck verfügt NSNotificationCenter über eine passende Methode zum Entfernen eines Observers:
func removeObserver(_ observer: AnyObject, name aName: String?, object anObject: AnyObject?)
Die drei Parameter kennen wir dabei bereits aus der Methode addObserver:selector:name:object:. observer ist das Objekt, welches sich für eine Notification registriert hat. aName entspricht dem Namen der Notification, für die sich der observer registriert hat. Und anObject schließlich entspricht einem optionalen Objekt, falls man Notifications nur von eben jenem Objekt wünscht.
Diese Methode wird dann äquivalent zur Methode addObserver:selector:name:object: aufgerufen, beispielsweise wie folgt:
NSNotificationCenter.defaultCenter().removeObserver(self, name: "MyNotification", object: nil)
iOS Notifications-Beispiel
Zum Abschluss des Notification-Themas führe ich noch ein komplettes Beispiel auf, das kurz und knapp die Funktionsweise von Notifications demonstriert und einen typischen Anwendungsfall zeigt (s. Listing 2).
Listing 2: Vollständiges Notification-Beispiel
class Person {
let firstName: String
let lastName: String
init(firstName: String, lastName: String) {
self.firstName = firstName
self.lastName = lastName
}
}
class Company {
var employees = [Person]()
func addEmployee(employee: Person) {
employees.append(employee)
let addedEmployeeNotification = NSNotification(name: "AddedEmployee", object: employee)
NSNotificationCenter.defaultCenter().postNotification(addedEmployeeNotification)
}
}
class EmployeeViewController: NSObject {
override init() {
super.init()
NSNotificationCenter.defaultCenter().addObserver(self, selector: "addedEmployee:", name: "AddedEmployee", object: nil)
}
func addedEmployee(notification: NSNotification) {
// Reload view.
}
deinit {
NSNotificationCenter.defaultCenter().removeObserver(self, name: "AddedEmployee", object: nil)
}
}Ein paar Worte zur Erklärung des Beispiels aus Listing 2: Die Klasse Company verschickt Notifications, wann immer ein Mitarbeiter in Form eines Person-Objekts über die Methode addEmployee: hinzugefügt wird. Diese Notification trägt den Namen AddedEmployee und übergibt die hinzugefügte Person-Instanz als Notification-Objekt; über ein userInfo-Dictionary verfügt die Notification nicht.
Neben diesen Person- und Company-Klassen enthält das Beispiel noch eine weitere Klasse namens EmployeeViewController, bei der es sich der Einfachheit halber nicht wirklich um einen View-Controller, sondern um eine Subklasse von NSObject handelt. Im Initializer der Klasse wird der Observer für die Notification AddedEmployee gesetzt. Geht diese Nachricht ein, wird die Methode addedEmployee: aufgerufen, die als Parameter die zugehörige Notification erhält. Diese Methode könnte nun beispielsweise dazu dienen, eine Liste der Mitarbeiter neu zu laden und zu aktualisieren.
Zu guter Letzt wird der gesetzte Observer bei der Deinitialisierung eines Objekts der Klasse EmployeeViewController wieder entfernt.
Und damit endet der erste Teil der Vorstellung von MVC in der iOS-Entwicklung. Im zweiten Teil werden das Key-Value Observing sowie die Techniken zur Kommunikation zwischen View und Controller im Detail vorgestellt.
