Synchrone AFNetworking Anrufe

Ich bin derzeit mit AFNetworking in einem meiner iPhone app. Es ist wirklich eine handliche Bibliothek, um asynchrone Aufrufe. Allerdings lief ich in Situationen in meiner Anwendung, wo ich brauche, um die Daten vom server, um vorwärts zu bewegen. Also dachte ich, dass dieser Weg wartet die Antwort zurück.

    MyAFNetworkClient *httpClient = [MyAFNetworkClient sharedClient];

    NSURLRequest *request = [httpClient requestWithMethod:@"GET" path:path parameters:nil];

__block int status = 0;

AFJSONRequestOperation *operation = [AFJSONRequestOperation JSONRequestOperationWithRequest:request success:^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON) {

    [[NSNotificationCenter defaultCenter] postNotificationName:@"notificationName" object:JSON];

} failure:^(NSURLRequest *request, NSHTTPURLResponse *response, NSError *error, id JSON){
    @throw error.userInfo;
    status = 2;
    NSLog(@"Error... Status Code 2");

}];
[httpClient enqueueHTTPRequestOperation:operation];
[httpClient.operationQueue waitUntilAllOperationsAreFinished];

while (status == 0)
{
    //run runloop so that async dispatch can be handled on main thread AFTER the operation has
    //been marked as finished (even though the call backs haven't finished yet).
    [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode
                             beforeDate:[NSDate date]];
}

Mit diesem Stück code, ich bin in der Lage, die Antwort zu warten wieder aus dem server und in der Lage, weiter zu gehen. Es schien wirklich um mein problem zu lösen, jedoch nicht sicher, ob dies ist eine gute Möglichkeit, um die Aufrufe. Wenn es ist, ist es ein gutes design-Prinzip, wo ich kann, halten Sie den code gemeinsame und verwenden Sie es auf meine Anwendung.

Danke

  • Ich denke, die Antworten/Kommentare hier veranschaulichen die Beurteilung aufgrund der Natur dieser Frage.
InformationsquelleAutor Harish | 2013-05-16
  1. 12

    Nie-block der main (UI) - thread. Das heißt, nie die Vernetzung synchron.

    Die ganze Zeit Ihre Anfrage lädt, es erscheint, dass Ihre Anwendung eingefroren hat—absolut nicht auf touch-und system-Ereignisse, bis die Anfrage beendet ist.

    Zumindest, zeigen eine be-modal, die nicht entlassen, bis die Anfrage beendet ist. Noch besser, machen Sie es, damit ein Benutzer interagieren kann die app normal, während die Anfrage laden, wenn möglich.

    Was Sie hier haben, mag technisch funktionieren, aber es ist inakzeptabel für eine Reale Anwendung.

    • falsch! 1.: es kann Gründe für die Sperrung der Haupt-thread. Ich glaube nicht, dass Sie regieren können, dass es sich für jede einzelne app in jeder situation. 2.: Tut Anfragen synchron bedeutet nicht, zu blockieren, die Mann-thread. Sie können im hintergrund schon beim starten eine synchrone Anfrage. Für einige Grund, die gesamte iOS-Gemeinde unisono reagiert "NICHT", wenn jemand fragt, für synchronen Netzwerk anfordern.
    • Sie sind völlig Irre. Und im Fall, dass Sie nicht Vertrauen, so die einhellige Meinung der community, zumindest von Apple auf Ihr Wort: (1) (2)
    • Was Sie über, wenn Sie herunterladen müssen Sie die Eigenschaft Liste, das ist ein muss für die Ausführung der Anwendung? ist es nutzbar, vor allem direkt nach dem Tippen auf "Anmelden me in" - Taste. Ich habe client-Einstellungen, Daten auf den remote-server und das ganze Zeug hat es zu respektieren, diese Einstellungen. Wenn die pList noch nicht heruntergeladen, die app nicht bieten kann die richtige Verwendung für den Benutzer.
    • Wie bereits in der ursprünglichen Antwort, kann die app noch interaktiver und display eine Ladeanzeige, während die app das warten auf Daten zu kommen. Sperrung der Haupt-thread der app bewirkt, dass es zu frieren, das macht für eine wirklich schlechte user experience.
    • Hi @mattt, es ist nicht in Bezug auf die ursprüngliche Frage, aber so weit wie möglich erklärt habe, wie können wir das ausführen einer Sequenz von networking-Anfragen synchron (natürlich nicht im Haupt-thread), eine nach der anderen und der ehemalige Ausgang ist ein Eingang des letzteren? Eigentlich können wir erreichen, dass der use case durch die Verwendung von asynchronen Callbacks, aber der code wäre ein Albtraum. Was schlagen Sie vor?
    • sowohl der Apple-links, die Sie gepostet entmutigen synchronen Netzwerk-Anfragen auf dem Haupt-thread nicht diskutieren, synchronen Netzwerk auf einem hintergrund-thread. Irgendwelche Gedanken auf, warum wir nicht tun sollten synchrone Vernetzung in den hintergrund?

    InformationsquelleAutor mattt
  2. 0

    Für alle von Ihnen, die in der gleichen situation sind, wo Sie sind, die asynchrone Aufrufe und wollen warten, bis die Daten wieder zurück auf den Haupt-thread für andere Sachen, dies könnte ein wenig Hilfe

    Szenario:

    Benutzer-Authentifizierung: Benutzer gibt Benutzername, Kennwort und Kennwort anzumelden versucht.

    Lösung: Zeigen Sie, laden -, modal -, um Ihnen zu sagen, dass etwas Los ist hinter den kulissen, sobald Sie sich wieder die Antwort, können Sie fortfahren, um den Haupt-thread wie unten.

    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 2 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{
         //perform next steps....
        });

}

    Dank @matt für den Tipp, was getan werden muss, um in solchen Fällen.

    • Warten für eine bestimmte Zeit ist keine tragfähige option, hier - es ist wahrscheinlich nur so schlimm, wie zu tun synchrone Vernetzung. Sie sollten immer die jeweiligen callback-Blöcke AFNetworking bietet. Um Sie richtig nutzen Sie müssen Architekten den rest der Anwendung, so dass es asynchron-freundlich. Delegation ist eine gute Idee, dann verwenden.
    • richtig ist—das ist nicht eine akzeptable Lösung.
    InformationsquelleAutor Harish
Schreibe einen Kommentar