emailconfirmed, nsInternRO, nsInternRW, Administrators
3,356
edits
added KVO
mNo edit summary |
(added KVO) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
Im Prinzip ist damit ein System von Accessoren gemeint. Am Beispiel wird das einfach deutlich. Nehmen wir an, eine Klasse hat eine iVar (Instanzvariable) und Property "<tt>NSString* myName</tt>": | Im Prinzip ist damit ein System von Accessoren gemeint. Am Beispiel wird das einfach deutlich. Nehmen wir an, eine Klasse hat eine iVar (Instanzvariable) und Property "<tt>NSString* myName</tt>": | ||
In Cocoa wird üblicherweise außerhalb der Klasse niemals direkt auf eine Instanzvariable zugegriffen. Jede Klasse stellt hierfür Accessoren | In Cocoa wird üblicherweise außerhalb der Klasse niemals direkt auf eine Instanzvariable zugegriffen. Jede Klasse stellt hierfür sogenannte Accessoren zur Verfügung, also jeweils eine Getter- und eine Setter-Methode, z.B.: | ||
<source lang="objc"> | <source lang="objc"> | ||
-(NSString*)name { return name; } | -(NSString*)name { return name; } | ||
| Line 15: | Line 15: | ||
</source> | </source> | ||
== @Properties = Accessors == | |||
Der Einsatz von Properties erleichtert lediglich das Tippen, da hiermit die Accessoren beim Kompilieren automatisch erstellt werden: | Der Einsatz von Properties erleichtert lediglich das Tippen, da hiermit die Accessoren beim Kompilieren automatisch erstellt werden: | ||
| Line 26: | Line 27: | ||
Durch @synthesize werden also die beiden o.g. Methoden generiert und dabei auf das Memory Management Rücksicht genommen. | Durch @synthesize werden also die beiden o.g. Methoden generiert und dabei auf das Memory Management Rücksicht genommen. | ||
Gibt es diese Accessoren können die Werte wie folgt gelesen/gesetzt werden. Jede dieser Methoden (außer die letzte) ist gültig und macht exakt das Gleiche: | == Using Accessors == | ||
Gibt es diese Accessoren, können die Werte wie folgt gelesen/gesetzt werden. Jede dieser Methoden (außer die letzte) ist gültig und macht exakt das Gleiche: | |||
<source lang="objc"> | <source lang="objc"> | ||
// getter | // getter | ||
| Line 43: | Line 45: | ||
Man beachte, dass die mit "ACHTUNG" versehenen Zeilen nicht auf die Getter/Setter, sondern direkt auf die Instanzvariablen zugreifen. Damit wird u.a. auch das Memory Management (retain/release-Zyklen) umgangen, was natürlich schlecht ist ;-) | Man beachte, dass die mit "ACHTUNG" versehenen Zeilen nicht auf die Getter/Setter, sondern direkt auf die Instanzvariablen zugreifen. Damit wird u.a. auch das Memory Management (retain/release-Zyklen) umgangen, was natürlich schlecht ist ;-) | ||
== Key/Value == | == Key/Value == | ||
| Line 64: | Line 65: | ||
Vorteile von Key-Value-Coding | == Vorteile von Key-Value-Coding == | ||
* Keine benannten Selektoren (nur valueForKey: und setValue:forKey:) | * Keine benannten Selektoren (nur valueForKey: und setValue:forKey:) | ||
* Sämtliche Cocoa-Collections (NSArray, NSDictionary...) benutzen KVC | * Sämtliche Cocoa-Collections (NSArray, NSDictionary...) benutzen KVC | ||
| Line 70: | Line 71: | ||
* Ideal für dynamisch synthetisierte Methoden | * Ideal für dynamisch synthetisierte Methoden | ||
== Key-Value-Observing == | |||
KVO (Key-Value-Observing) ist ein sehr schlaues Konzept zur Beobachtung von geänderten Properties. Das Funktionsprinzip ist einfach: | |||
* Registrieren, um Benachrichtigungen bei Änderungen von Properties zu erhalten | |||
* Methode überschreiben, die den Empfang von Nachrichten bei Änderungen erlaubt | |||
* Registrierung entfernen, wenn keine Beobachtung mehr erwünscht ist | |||
<source lang="ObjC"> | |||
// register for KVO (eg. in -viewDidLoad:) | |||
[model addObserver:self | |||
forKeyPath:@"propertyName" | |||
options:NSKeyValueObservingOptionNew | |||
context:NULL]; | |||
// implement this method to receive notifications | |||
-(void)observeValueForKeyPath:(NSString *)keyPath | |||
ofObject:(id)object | |||
change:(NSDictionary *)change | |||
context:(void *)context | |||
{ | |||
NSLog(@"Property changed: %@", object); | |||
} | |||
// remove observer when done (eg. in -dealloc) | |||
[model removeObserver:self forKeyPath:@"propertyName"]; | |||
</source> | |||
== Vorteile von Key-Value-Observing == | |||
* Keine Referenz vom Model zum Controller: Der Controller kann Änderungen im Model registrieren, ohne dass das Model eine explizite Referenz zum Controller halten muss | |||
* Vermeiden von unerwünschten Schleifen beim Aktualisieren von Werten | |||
== Links == | == Links == | ||