Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort des Gutachters
Vorwort
1 Einführung
2 Einstieg in die Praxis
3 Aufwachen – analoger Wecker
4 Daten, Tabellen und Controller
5 Animationen und Layer
6 Programmieren, aber sicher
7 Jahrmarkt der Nützlichkeiten
A Die Buch-DVD
Stichwort

Download:
- ZIP, ca. 23,6 MB
Buch bestellen
Ihre Meinung?

Spacer
Apps entwickeln für iPhone und iPad von Klaus M. Rodewig, Clemens Wagner
Das Praxisbuch
Buch: Apps entwickeln für iPhone und iPad

Apps entwickeln für iPhone und iPad
geb., mit DVD
515 S., 49,90 Euro
Galileo Computing
ISBN 978-3-8362-1463-6

Die Neuauflage des Buches erhalten Sie in unserem Online-Shop - versandkostenfrei innerhalb Deutschlands und Österreichs.
Zum Online-Shop
Pfeil 2 Einstieg in die Praxis
Pfeil 2.1 Hefte raus, Klassenarbeit! – Die Arbeit mit Klassen
Pfeil 2.1.1 Objekte erzeugen: alloc und init
Pfeil 2.1.2 Objekte löschen: release und dealloc
Pfeil 2.1.3 Initializer
Pfeil 2.1.4 Accessoren
Pfeil 2.1.5 Eigene Methoden
Pfeil 2.1.6 Vererbung
Pfeil 2.1.7 Kategorien
Pfeil 2.1.8 Protokolle
Pfeil 2.2 Das erste iOS-Projekt
Pfeil 2.2.1 Der Interface Builder
Pfeil 2.2.2 Delegation
Pfeil 2.3 Model, View und Controller
Pfeil 2.3.1 Der Aufbau des Musters
Pfeil 2.3.2 Key-Value-Observing
Pfeil 2.3.3 Target-Action-Mechanismus
Pfeil 2.3.4 Controller in Cocoa Touch
Pfeil 2.4 Speicherverwaltung, Propertys und Key-Value-Coding
Pfeil 2.4.1 Referenzenzählen in Objective-C
Pfeil 2.4.2 Die Speicherverwaltungsregeln
Pfeil 2.4.3 Propertys
Pfeil 2.4.4 Key-Value-Coding
Pfeil 2.4.5 Abschließende Bemerkungen
Pfeil 2.5 Automatisches Referenzenzählen
Pfeil 2.5.1 Zurück in die Zukunft
Pfeil 2.5.2 Weakie und die starken Zeiger
Pfeil 2.5.3 Autoreleasepools
Pfeil 2.5.4 Einzelgänger
Pfeil 2.5.5 Migration bestehender Projekte

Galileo Computing - Zum Seitenanfang

2.3 Model, View und ControllerZur nächsten Überschrift

Für das Beispielprogramm HelloWorld hat Xcode diverse Dateien angelegt. Wozu sind die alle da? Wenn der View – also die Ansicht – der App doch in den XIB-Dateien liegt, wozu dient dann die Controller-Klasse? Die Antwort auf diese Fragen liefert das Architekturmuster, das Apple für alle Cocoa-Applikationen empfiehlt.

Das Model-View-Controller-Muster, nach seinen Komponenten auch abgekürzt MVC genannt, wurde Ende der 1970er-Jahre zusammen mit der Programmiersprache Smalltalk entwickelt. Es beschreibt eine Struktur zum Aufbau von Applikationen und zählt deswegen zu den Architekturmustern und nicht zu den Entwurfsmustern, die nur Lösungen für Teilprobleme einer Applikation beschreiben. Die Struktur soll dabei die Wartbarkeit und die Erweiterbarkeit des Programmcodes verbessern. Sie unterteilt die Applikationen in sinnvolle Komponenten und erleichtert dadurch die Entwicklung größerer Anwendungen.

Cocoa verwendet das Model-View-Controller-Muster als Grundlage für die Applikationsentwicklung. Wenn Sie dieses Muster noch nicht kennen, erscheint es Ihnen vielleicht für kleinere Apps etwas aufwendig. Sie sollten aber dieses Muster konsequent in Ihren Applikationen anwenden. Zum einen erleichtert es Ihnen auf Dauer die Entwicklung und hilft Ihnen, sauberen und übersichtlichen Code zu schreiben. Zum anderen ist es aber auch sehr schwer, eine Cocoa-App an diesem Muster vorbei zu programmieren, da sowohl die Tools als auch das API auf das MVC-Muster ausgerichtet sind.


Galileo Computing - Zum Seitenanfang

2.3.1 Der Aufbau des MustersZur nächsten ÜberschriftZur vorigen Überschrift

MVC teilt die Klassen eines Programms in drei Bereiche auf, die man auch Ebenen oder Schichten nennt. Das Modell verwaltet die Daten des Programms. Diese Schicht kapselt also die Daten der Anwendung in Klassen. In dem Programm Adressbuch sind beispielsweise diese Daten die gespeicherten Adressen. Dessen Modell besitzt also Klassen zur Darstellung von Adressen. Die Aufgabe des Modells ist auch, die Daten konsistent zu halten. Das bedeutet, dass ein gutes Datenmodell die Anwendungsdaten fehlerfrei abbilden sollte. Im Adressbuch können Sie beispielsweise keinen vollständig leeren Eintrag speichern. Für das Datenmodell des Adressbuchs ist ein leerer Eintrag ein Fehler, den es nicht zulässt. Das fünfte Kapitel stellt ein Puzzlespiel vor. Dort hat das Modell nicht nur die Aufgabe, den aktuellen Zustand des Puzzles zu speichern. Es achtet auch darauf, dass der Nutzer keine ungültigen Züge ausführen kann.

Der View enthält alle Klassen, die für die direkte Interaktion des Programms mit dem Nutzer zuständig sind. Das sind sowohl Klassen, die etwas anzeigen als auch Eingaben verarbeiten können. Viele View-Klassen können auch beides. Typische Beispiele für Views sind Bilder, Buttons, Textfelder und Fenster. Der Wecker aus dem nächsten Kapitel verwendet für die Darstellung nicht nur Standardelemente, die iOS zur Verfügung stellt. Er benötigt darüber hinaus auch applikationsspezifische View-Elemente, die spezielle Darstellungs- und Eingabemöglichkeiten haben.

Der Controller im MVC-Muster stellt schließlich das Bindeglied zwischen dem Modell und den Views dar. Er übernimmt die Steuerung des Programms und enthält die Applikationslogik. Der Controller darf auf die Komponenten des Modells und des Views zugreifen und auch deren Methoden aufrufen. Umgekehrt sollten aber weder das Modell noch der View die Klassen oder Methoden des Controllers kennen.

Abbildung

Abbildung 2.33 Das MVC-Architekturmuster in der Übersicht

Machen Sie sich nicht abhängig!

Die Modell- und die View-Schicht sollten jeweils keine Abhängigkeit zu den beiden anderen Schichten haben. Abhängigkeit meint dabei die Verwendung der Klassen der anderen Ebenen. Verwenden Sie also keine Controller- oder View-Klassen bei der Implementierung des Modells und auch keine Controller- oder Modell-Klassen bei der Implementierung Ihrer Views.

Sie erhöhen so die Wiederverwendbarkeit dieser beiden Schichten. Das bedeutet beim Modell, dass jedes seiner Objekte durch mehrere unterschiedliche Controller verarbeitet und durch unterschiedliche Views dargestellt werden kann. Andererseits sollten Sie Ihre View-Klassen so entwickeln, dass sie sich auch für ähnliche Anwendungsfälle eignen. Denken Sie an die View-Klassen von Cocoa-Touch, wie Buttons, Slider oder Textfelder, die Sie in vollkommen unterschiedlichen Applikationen einsetzen können.

Die stringente Anwendung von MVC erleichtert überdies die Portabilität von Apps. Für die Portierung von iPhone-Apps zum iPad müssen Sie in der Regel die View-Schicht sehr stark anpassen, während der Controller geringere Anpassungen benötigt. Das Modell sollte in den meisten Fällen gleich bleiben. Ein sauber implementiertes Modell können Sie unter Umständen sogar in OS X Applikationen verwenden.

Stellen Sie sich vor, Sie sollen für einen Kunden eine App für die Inventur seines Lagers entwickeln. Das MVC-Muster gibt Ihnen dazu einen einfachen und groben Weg vor, wie Sie das Programm umsetzen können. Sie starten mit dem Modell, in dem Sie die Klassen (z. B. für Produkte, Warengruppen, Hersteller), deren Attribute und deren Beziehungen zueinander festlegen. Danach setzen Sie die ersten Eingabemasken nach den Wünschen Ihres Kunden um und implementieren schließlich die Geschäftslogik der App in den Controllern.

Wenn das Programm erfolgreich ist, wird der Kunde wahrscheinlich recht bald mit Änderungswünschen zu Ihnen kommen. Die Lageristen wollen einen Barcode-Scanner integriert haben, die Buchhaltung braucht eine Suchfunktion, und die IT-Abteilung will endlich die SAP-Anbindung realisieren. Sie werden wahrscheinlich alle drei Schichten des Programms verändern müssen. Jetzt treten aber die Vorteile des MVC-Musters zutage:

  • Sie können neue Controller und Views für die neuen Anwendungsfälle implementieren, ohne aufwendige Änderungen an den bestehenden Klassen vornehmen zu müssen.
  • Wenn Sie Ihre Modellklassen erweitern müssen, müssen Sie in der Regel nur die bestehenden Controller anpassen.
  • Auch für die Erweiterung Ihrer bestehenden Views brauchen Sie nur Logik in den entsprechenden Controllern anzupassen.

Natürlich kann das auch alles sehr aufwendig und kompliziert sein. Aber diese Aufwände sind verglichen mit Spaghetticode, bei dem sich Abhängigkeiten quer durch die gesamte Applikation ziehen, relativ gering.


Galileo Computing - Zum Seitenanfang

2.3.2 Key-Value-ObservingZur nächsten ÜberschriftZur vorigen Überschrift

Die Modellobjekte können auch ohne Abhängigkeit Kontakt zum Controller aufnehmen, da sie von Haus aus das Beobachtermuster unterstützen. Damit können sich Controllerobjekte als Beobachter bei den Modellobjekten registrieren. Wenn das Programm ein Modellobjekt verändert, benachrichtigt es alle Beobachter durch einen Methodenaufruf. Das Beobachtermuster erzeugt dabei keine Abhängigkeit des Modells vom Controller, da die Modellobjekte die Klassen ihrer Beobachter nicht kennen. Diese Verbindung nennt man auch lose Kopplung.

Cocoa Touch setzt das Beobachtermuster über das Key-Value-Observing (KVO) um. Es ist aber nicht nur auf Modell- und Controllerklassen beschränkt, sondern beliebige Klassen können es verwenden. Das beobachtete Objekt muss das Protokoll NSKeyValueObserving implementieren, was für jede Subklasse von NSObject automatisch gilt, da diese das Protokoll von NSObject erben.

Die Klasse NSObject implementiert folgende Methoden, um die Beobachter eines Objekts zu verwalten:

- (void)addObserver:(NSObject *)observer
forKeyPath:(NSString *)keyPath
options:(NSKeyValueObservingOptions)options
context:(void *)context;
- (void)removeObserver:(NSObject *)observer
forKeyPath:(NSString *)keyPath;

Listing 2.29 Methoden zur Verwaltung von Beobachtern

Darüber können Sie jeweils einen Beobachter zu einem Attribut bei einem Objekt registrieren beziehungsweise abmelden. Wenn Sie beispielsweise das Attribut firstName einer Person beobachten wollen, können Sie den Beobachter folgendermaßen registrieren:

[thePerson addObserver:theController
forKeyPath:@"firstName"
options:NSKeyValueObservingOptionNew |
NSKeyValueObservingOptionOld
context:NULL];

Listing 2.30 Registrierung eines Beobachters

Nach dieser Registrierung benachrichtigt das Personenobjekt thePerson den Beobachter theController jetzt bei jeder Änderung des Attributs firstName. Die beiden Konstanten für den Optionsparameter geben dabei an, dass die Benachrichtung immer den alten und den neuen Attributwert enthalten soll. Für den Empfang der Benachrichtigung muss der Empfänger folgende Methode implementieren:

- (void)observeValueForKeyPath:(NSString *)keyPath
ofObject:(id)object
change:(NSDictionary *)change
context:(void *)context

Die Attributwerte enthält dabei das Dictionary change. Sie können die Methode folgendermaßen implementieren:

- (void) observeValueForKeyPath:(NSString *)inKeyPath
ofObject:(id)inObject
change:(NSDictionary *)inChange
context:(void *)inContext {
if([inKeyPath isEqualToString:@"firstName"]) {
NSLog(@"alter Wert:%@", [inChange valueForKey:NSKeyValueChangeOldKey]);
NSLog(@"neuer Wert:%@", [inChange valueForKey:NSKeyValueChangeNewKey]);
}
}

Listing 2.31 Implementierung der Observierungsmethode

Die Registrierung aus Listing 2.30 registriert den Beobachter nur für genau ein Objekt-Attribut-Paar. Wenn Sie weitere Objekte oder Attribute beobachten möchten, müssen Sie diese gesondert registrieren. Vor der endgültigen Freigabe eines Beobachters müssen Sie ihn immer abmelden. Ansonsten erhalten Sie einen Laufzeitfehler, und Ihr Programm stürzt ab.

Für dieses Beispiel sieht der entsprechende Aufruf folgendermaßen aus:

[thePerson removeObserver:theController forKeyPath:@"firstName"];

Listing 2.32 Abmelden eines Beobachters


Galileo Computing - Zum Seitenanfang

2.3.3 Target-Action-MechanismusZur nächsten ÜberschriftZur vorigen Überschrift

Sie können auch bei Views das Beobachtermuster einsetzen, um Änderungen des View-Zustands im Controller mitzubekommen. Das ist aber häufig recht aufwendig umzusetzen, da es nur eine Beobachtermethode, meistens aber mehrere zu beobachtende Views gibt.

Stattdessen kann in Cocoa Touch ein View den Controller über den Target-Action-Mechanismus benachrichtigen. Dazu registrieren Sie das Objekt (das Target) mit einer Methode (der Action) und den Ereignistypen beim betreffenden View. Dieser View ruft dann beim Auftreten des entsprechenden Ereignisses die Methode in dem registrierten Objekt auf.

In Cocoa Touch unterstützen aber nicht alle Views diesen Mechanismus. Er ist nur bei Objekten der Klassse UIControl verfügbar, wobei aber das Target eine beliebige Klasse haben darf. Es sollte aber ein Controller sein, da die Verwendung von Klassen der beiden anderen Schichten eine Verletzung des MVC-Musters wäre. Sie können Target-Action-Beziehungen über den Programmcode oder den Interface Builder herstellen. Sie können über die Methoden

- (void)addTarget:(id)target
action:(SEL)action
forControlEvents:(UIControlEvents)controlEvents
- (void)removeTarget:(id)target
action:(SEL)action
forControlEvents:(UIControlEvents)controlEvents

Listing 2.33 Verwaltung von Action-Targets bei Controls

Target-Action-Paare registrieren beziehungsweise abmelden. Der Datentyp SEL bezeichnet dabei übrigens Selektoren.

Auch hier müssen Sie darauf achten, die Paare rechtzeitig freizugeben. Sie dürfen allerdings bei der Abmeldung nil für das Target verwenden, um alle Paare abzumelden. Abschnitt 3.2.4, »Ereignisse«, stellt die verschiedenen Ereignistypen vor.


Galileo Computing - Zum Seitenanfang

2.3.4 Controller in Cocoa TouchZur vorigen Überschrift

Als Sie das HelloWorld-Projekt angelegt haben, hat Xcode automatisch eine Klasse HelloWorldViewController als Unterklasse von UIViewController erzeugt. Sie ist die Basisklasse für alle Controller, die eine Vollansicht verwalten. Der Begriff Vollansicht bezeichnet entweder den kompletten Bildschirm oder die komplett sichtbaren Bereiche der Containerviewcontroller. Zu diesen gehören die Navigations-, Tabbar-, Popover- und Splitviewcontroller. Unterklassen von UIViewController sollten bis einschließlich iOS 4 immer Vollansichten und niemals nur Teilansichten verwalten, da diese Betriebssysteme nur so den kompletten Lade- und Anzeigezyklus des Viewcontrollers unterstützen. Das vierte Kapitel behandelt aber eine Möglichkeit, wie Sie für Subviews eigene Controller erstellen können. Ab iOS 5 können Sie aber auch auf der Basis von UIViewControllern Subviews verwalten.

Jede Vollansicht sollte einen eigenen View-Controller besitzen. Dieser sollte immer eine Unterklasse von UIViewController sein. In der Regel legen Sie für jede Vollansicht auch eine Unterklasse an, da Sie die kompletten View-Controller-Klassen in der Regel nicht wiederverwenden können. Diese Klassen enthalten ja schließlich Ihre Geschäftslogik. Die Hierarchie eines View-Controllers liegt in einer XIB-Datei, sofern die Views nicht über Programmanweisungen erzeugt werden. Die Datei sollte den gleichen Namen wie die Controller-Klasse haben.

Nicht nur die View-Controller, sondern auch das Application-Delegate gehören zur Controller-Schicht der Applikation. Die Aufgabe der Controller ist es, die Eigenschaften des jeweiligen Views zu steuern und zu kontrollieren.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
  Zum Katalog
Zum Katalog: Neuauflage: Apps programmieren für iPhone und iPad





Neuauflage: Apps programmieren für iPhone und iPad
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Objective-C 2.0 & Cocoa





 Objective-C 2.0
 Cocoa


Zum Katalog: Mac OS X Lion






 Mac OS X Lion


Zum Katalog: Mac OS X und UNIX






 Mac OS X
 und UNIX


Zum Katalog: Android 3






 Android 3


Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: CSS






 CSS


Zum Katalog: jQuery






 jQuery


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2011
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de