2010-01-15 13 views
8

Ich habe Probleme, das Konzept der Verkaufsstellen zu verstehen, wie das iPhone mit Ereignissen umgeht. Hilfe! Delegierte verwirren mich auch. Möchte jemand bitte erklären?Objective C-Terminologie: Outlets & Delegierte

+2

nicht versuchen, ein Idiot zu sein, aber haben Sie die einführenden Dokumente auf developer.apple.com gelesen? Es ist nur, dass die Frage einen Aufsatz beantworten würde. Stellen Sie sich vielleicht eine detailliertere Frage zu dem, was Sie aufhält. –

+0

Die Dokumentation, die Apple im Cocoa Fundamentals Guide für Outlets bereitstellt: http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/CommunicateWithObjects.html#//apple_ref/doc/uid/ TP40002974-CH7-SW3 und Delegaten: http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/CommunicateWithObjects.html#//apple_ref/doc/uid/TP40002974-CH7-SW18 scheint ziemlich gründlich zu mir. –

+0

@Brad - Ich bin keine Dokumentationsperson. – Moshe

Antwort

19

Outlets (im Interface Builder) sind Membervariablen in einer Klasse, in der Objekte im Designer zugewiesen werden, wenn sie zur Laufzeit geladen werden. Das IBOutlet Makro (das eine leere #define ist) signalisiert Interface Builder, es als eine Steckdose zu erkennen, die im Designer angezeigt wird.

Zum Beispiel, wenn ich einen Knopf in die Länge ziehen, schließen sie dann an den aButton Auslass (definiert in meiner Schnittstelle .h-Datei), wird das Laden der NIB Datei zur Laufzeit aButton den Zeiger auf diesen UIButton durch die instanziierten zuweisen FEDER.

@interface MyViewController : UIViewController { 
    UIButton *aButton; 
} 

@property(nonatomic, retain) IBOutlet UIButton *aButton; 

@end 

Dann bei der Umsetzung:

@implementation MyViewController 

@synthesize aButton; // Generate -aButton and -setAButton: messages 

-(void)viewDidAppear { 
    [aButton setText:@"Do Not Push. No, seriously!"]; 
} 

@end 

Dadurch entfällt die Notwendigkeit, Code zu schreiben, um die GUI-Objekte zur Laufzeit instanziiert und zuordnen.


Wie für Delegierten, sind sie Ereignis empfangen Objekte von einem anderen Objekt (in der Regel eine verallgemeinerte API-Klasse, wie beispielsweise einer Tabellensicht) verwendet. Es gibt nichts an sich Besonderes an ihnen. Es ist eher ein Designmuster. Die Delegierten Klasse kann mehrere der erwarteten Nachrichten definieren, wie:

-(void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath 

... und das API-Objekt ruft diese Nachricht auf den Delegaten, wenn sie will es der Veranstaltung informieren. Zum Beispiel:

-(void)update:(double)time { 
    if (completed) { 
     [delegate process:self didComplete:totalTimeTaken]; 
    } 
} 

und die Delegierten definieren die Nachricht:

-(void)process:(Process *)process didComplete:(double)totalTimeTaken { 
    NSString *log = [NSString stringWithFormat:@"Process completed in %2.2f seconds.", totalTimeTaken]; 
    NSLog(log); 
} 

Ein solche Verwendung könnte sein:

Process *proc = [Process new]; 
[proc setDelegate:taskLogger]; 
[proc performTask:someTask]; 

// Output: 
// "Process completed in 21.23 seconds." 
+0

Also Delegierte sind tatsächlich verherrlichte Versionen von was andere Sprachen wie Javascript oder Python als Rückrufe interpretieren, richtig? – SexyBeast

9

Ein Delegierter ist ein Objekt, das ein anderes Objekt Nachrichten weiterleiten kann. Mit anderen Worten, es ist wie wenn deine Mutter dir gesagt hat, du sollst dein Zimmer putzen und du hast es an deinen kleinen Bruder verpfändet. Dein kleiner Bruder weiß, wie man den Job macht (da du zu faul warst, um jemals zu lernen) und so macht er es für dich.

+1

Was für ein wunderbarer, didaktischer Vergleich! –

+1

Warum hat Mama nicht direkt den kleinen Bruder gefragt? – super9