asihttprequest stürzt mein app
Ich habe eine navigation app. Drücken Sie eine Taste auf Hauptansicht, dann schieb ich einen neuen Blickwinkel auf die navigation-controller. Alle ziemlich grundlegende Dinge.
Wenn die neue Ansicht geladen ist, mache ich ein ASIHTTPRequest zu Holen, json-Daten, die eine Liste von Bild-urls.
Dann Mach ich eine for-Schleife, erstellen Sie eine Reihe von ASIHTTPRequests, fügen Sie Sie in einer Warteschlange, und führen Sie dann die Warteschlange.
Aber wenn ich auf die zurück-Taste, bevor die Warteschlange beendet ist, stürzt die app, diese app zeigt Häuser und können sagen, Sie nehmen das falsche Haus, klicken Sie auf zurück, sehr schnell, vor jedem Foto wird angezeigt, bumm Absturz.
Diesem thread http://groups.google.com/group/asihttprequest/browse_thread/thread/3d4815198aa889b9 erklärt mein problem auch richtig gut, außer, dass ich Abbrechen alle Anforderungen an Sicht zu entladen, legen Sie delegieren auf null und lassen Sie die Warteschlange.
Ich noch Absturz. Ich crash so ziemlich jedes mal, wenn ich 3G verwenden, aber über WLAN ist es echt schwer zu machen, ihn zum Absturz zu bringen, aber durchaus machbar.
In fast 80% der Instanzen der debugger springt auf diese Zeile in ASIHTTPRequest.m
(void)requestReceivedResponseHeaders:(NSMutableDictionary *)newResponseHeaders {
if ([self error] || [self mainRequest]) { return; }
--> if (delegate && [delegate respondsToSelector:didReceiveResponseHeadersSelector]) {Vielen Fällen springt Sie auf :
(void)requestReceivedResponseHeaders:(NSMutableDictionary *)newResponseHeaders {
if ([self error] || [self mainRequest]) { return; }
---> if (delegate && [delegate respondsToSelector:didReceiveResponseHeadersSelector]) { Anzeige in einer Handvoll Instanzen geht es zu meiner main-loop
int main(int argc, char *argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
--> int retVal = UIApplicationMain(argc, argv, nil, nil); with SIGBART error [pool release]; return retVal; Bin ich mit dem MBP und MacPro, neueste OS X, Xcode 4.0.2 und ich Teste auf alle apple-Geräte mit Ausnahme von original-iPhones.
Ich möchte wirklich nicht wieder schreiben, meine ganze app, aber gibt es sonst noch etwas gibt, vergleicht mit ASIHTTPRequest ?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Versuchen, Abbrechen und löschen Sie die Stellvertretung in
-viewWillUnloadeher als-viewDidUnload. Ich vermute, dass das Zeitfenster, in dem es tatsächlich entladen (zwischen dem Aufruf dieser beiden UIViewController Methoden) ist die Zeit, wenn Sie crashable. Die Stellvertretung ist Weg, aber Sie haben nicht gesagt, Ihre ASIHTTPRequest-Objekt, das noch.Der Fehler ist, dass der Delegat wird noch festgelegt.
Ich gefunden habe, 2 Möglichkeiten, um dieses Problem zu beheben.
Den Weg, den ich als hässlich empfand ist, dass Sie einen universal-Delegierten, die nicht alle Netzwerk-traffic und instanziiert wird, wenn die app zuerst ausgeführt wird. Ich tatsächlich verwendet das app-delegate und hören nsnotification center-Nachrichten. Es funktioniert wie ein Charme, ist die app nie abstürzt, aber ich denke, es ist nicht optimal.
Ist die beste Möglichkeit, nicht delegieren und nicht "setDidFinishSelector", sondern stattdessen "setCompletionBlock:^". Dies funktioniert nur auf Geräten mit iOS 4.0 und höher, das ist mehr als 90-95% und wächst. Dies ist nur eine wunderbare Art und Weise und nicht zum Absturz der Anwendung.
Werden Sie nicht finden nichts besseres, dass ASIHTTPRequest, das problem wird sein, wie Sie es sind, und verschwinden Delegierten zur navigation sind ein gemeinsames problem zu bewältigen haben.
Es klingt wie dein problem bezieht sich auf den viewcontroller, der Umgang mit dem queue zerstört werden, die aufgrund der navigation der Nutzer. Ich finde der beste Weg, die Lösung dieser Fragen ist eine zentrale model-Klasse, die Griffe alle meine Kommunikations-und halten, dass die Klasse während des gesamten application lifecycle.
So dass Sie nicht bekommen, unerklärliche Abstürze, wenn die Delegierten verschwunden unerwartet.
Option 2
Ein weiterer Ansatz kann sein, ein deaktivieren der navigation der Nutzer bis zum Netzwerk-Betrieb abgeschlossen ist. Legen Sie eine modale Ansicht über den gesamten Bildschirm, zeigt eine uiactivityview, damit der Benutzer weiß, Ihre Aktionen werden blockiert. Dann können Sie fade-der modal-Ansicht aus, wenn die Daten da sind. Wenn Sie design der Bildschirm schön mit einer Steigung, sodass der hintergrund nur graut ein bisschen, das kann OK Aussehen. Aber es ist nicht wirklich der beste Ansatz - Sie beheben sollten die Delegierten AWOL statt.
Müssen wir wahrscheinlich sehen, mehr von dem code in Bezug auf die Warteschlange, Schöpfung, Zerstörung usw. zu finden, die genaue Problem.
Ihre Anwendung delegieren können eigene Reihe von Anfrage-Warteschlangen. Die array-Leben unabhängig vom Status der Navigations-controller-stack und der damit verbundenen Ansichten. Statt binden-Anforderungen an einen view-controller in den nav-stack, und sich nicht um die UI-tricks zu blockieren knallen zurück zu einer übergeordneten Ansicht, man könnte hinzufügen, Anfragen an eine app delegate-Warteschlange-Instanz, oder stoppen Sie alle Anfragen und leeren der Warteschlange, etc.