NSURLConnection NSURLRequest proxy für asynchrone web-service-Aufrufe
Ich habe mehrere views, die die gleiche NSURLRequest/NSURLConnection request
. Ideal, um die Wiederverwendung von code, ich würde gerne eine Art "proxy", die nicht alle der zugrunde liegenden Arbeit von der Erstellung/Ausführung der (asynchronen) request/Verbindung, wobei alle Delegierten Methoden, etc., damit ich nicht haben, kopieren Sie alle diese NSURLConnection
delegate-Methode-Handler in jeder Ansicht. Zuerst von allen, ist dieser design-Ansatz für angemessen? Zweitens, wie würde ich mich über etwas ähnliches?
Für ein wenig hintergrund-info, ich versuchte dies und bekam es auch "funktioniert", aber es scheint nicht zu sein, die Ausführung asynchron. Ich erstellt einen Proxy.h/m-Datei, die Instanz-Methoden für die verschiedenen web-service-Aufrufe (und enthält auch die NSURLConnection
delegate-Methoden):
@interface Proxy : NSObject {
NSMutableData *responseData;
id<WSResponseProtocol> delegate;
}
- (void)searchForSomethingAsync:(NSString *)searchString delegate:(id<WSResponseProtocol>)delegateObj;
@property (nonatomic, retain) NSMutableData *responseData;
@property (assign) id<WSResponseProtocol> delegate;
@end
Den WSResponseProtocol so definiert:
@protocol WSResponseProtocol <NSObject>
@optional
- (void)responseData:(NSData *)data;
- (void)didFailWithError:(NSError *)error;
@end
Zu verwenden, die view-controller muss lediglich konform zu den WSResponseProtocol
Protokoll, fangen die Antwort(en). Machen die web-service-Aufruf erfolgt in etwa so:
Proxy *p = [[Proxy alloc] init];
[p searchForSomethingAsync:searchText delegate:self];
[p release];
Kann ich mehr code, aber die übrigen kann davon ausgegangen werden. Bevor Sie anrufen, ich "startAnimating" ein UIActivityIndicatorView
spinner. Aber die spinner nie spinnt. Wenn ich einfach die NSURLConnection delegate-Methoden direkt in der view-controller, der spinner dreht. Also, es macht mich denken, dass meine Implementierung nicht ausführen asynchron. Irgendwelche Gedanken/Ideen hier?
InformationsquelleAutor tbehunin | 2009-12-24
Du musst angemeldet sein, um einen Kommentar abzugeben.
Dein Ansatz ist vernünftig, allerdings bin ich mir nicht sicher, warum, Sie erstellen Ihr eigenes Protokoll. Dies ist nicht notwendig. Alles, was Sie brauchen, um dieses implementiert in Apple Dokumentation auf NSURLConnection. Wenn Sie den code von dieser Seite, wo die NSURLConnection instanziiert wird, und stellen Sie die Verbindung über ein ivar anstatt nur zu erstellen, als eine lokale variable kannst du dann vergleichen Sie die connection-Objekte in jedem der callback-Methoden und entsprechend reagieren. Zum Beispiel, nehmen Sie diesen code von den docs, und ändern Sie das connection-Objekt an ein ivar:
Die variable theConnection ist unser ivar. Dann können Sie es wie folgt:
Kann man sicherlich implementieren, erstellen Sie Ihre eigenen Protokoll, wie Sie vorgeschlagen sind, und rufen Sie dann zurück, um den Delegierten entspricht, ist Ihr Protokoll, aber Sie können es besser nur die Instanziierung Ihr Objekt über Erfolg und Misserfolg-Auswahl, die Sie überprüfen können. So etwas wie dieses:
Wo dataDidDownloadSelector ist ein SEL-Instanz-Variablen, die Sie festlegen, wenn Sie erstellt Ihre download-delegieren, wo alle von diesem code enthalten ist--das Proxy-Objekt. So etwas wie dieses:
Umsetzung Ihrer Selektoren wie:
Dieser hat sich zu einer Antwort mehr als ich beabsichtigte. Lassen Sie mich wissen, ob es nicht sinnvoll ist, und ich kann versuchen zu klären.
Beste Grüße,
Zurückfällt mein Kommentar zuvor. Dieser Ansatz ist der Ansatz, den ich werde mit vs synchrone NSURLConnections in eine NSOperation. NSURLConnection bereits das threading, die ich brauche, ohne es in eine NSOperation. Plus, nach dem Lesen mehr blogs, synchrone NSURLConnections + - Authentifizierung bieten nicht so viele "Haken" wie asynchrone Aufrufe tun.
Wo\wie ist receivedData erklärt. Die Dokumentation hält nur sagen, es erklärt wird, anderswo aber gibt keine Informationen, wie das zu tun.
Es ist eine Eigenschaft oder ivar der Klasse, wo dieser code deklariert. Es sollte zugänglich sein durch
[self receivedData]
InformationsquelleAutor Matt Long
Ihren code so ist, denke ich würde nichts tun - lassen Sie den Proxy direkt nach der Initialisierung, so dass es nie läuft sogar.
Ansatz, den ich gerne nutze, ist die synchrone NSURLConnection Anrufe, die in einer NSOperation die wiederum gelang durch ein NSOperationQueue. Ich mache das Objekt der Warteschlange lebt in einem Singleton, so dass ich nur auf die Instanz zugreifen, von überall aus und sagen Sie es, wenn ich eine neue Verbindung gestartet.
Zu pass out Ergebnissen, die ich in der Regel speichern die Daten, die Ergebnis irgendwo zentral über ein singleton, und/oder passieren Sie den Gegenstand zurück, um niemanden interessiert, verpackt in eine Meldung (Sie können wickeln Sie ein beliebiges Objekt in der Meldung userInfo Wörterbuch).
InformationsquelleAutor Kendall Helmstetter Gelner