J'utilise AFNetworking pour les appels asynchrones à un service web. Certains de ces appels doivent être enchaînés, les résultats de l'appel A étant utilisés par l'appel B qui est utilisé par l'appel C, etc.
L'AFNetworking traite les résultats des appels asynchrones avec des blocs de réussite/échec définis au moment de la création de l'opération :
NSURL *url = [NSURL URLWithString:@"http://api.twitter.com/1/statuses/public_timeline.json"];
NSURLRequest *request = [NSURLRequest requestWithURL:url];
AFJSONRequestOperation *operation = [AFJSONRequestOperation JSONRequestOperationWithRequest:request success:^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON) {
NSLog(@"Public Timeline: %@", JSON);
} failure:nil];
[operation start];
Il en résulte des blocs d'appels asynchrones imbriqués qui deviennent rapidement illisibles. C'est encore plus compliqué lorsque les tâches ne sont pas dépendantes les unes des autres et doivent au contraire s'exécuter en parallèle et que l'exécution dépend des résultats de toutes les opérations.
Il semble qu'une meilleure approche serait de tirer parti d'une promesses pour nettoyer le flux de contrôle.
Je suis tombé sur MAFuture mais je n'arrive pas à trouver la meilleure façon de l'intégrer à AFNetworking. Étant donné que les appels asynchrones peuvent avoir plusieurs résultats (succès/échec) et qu'ils n'ont pas de valeur de retour, cela ne semble pas être une solution idéale.
Toute indication ou idée serait appréciée.
0 votes
Merci pour cette question - vous avez d'excellentes réponses. J'ai eu un peu de mal à la trouver au départ, et je suis arrivé ici en regardant les promesses. Cet anti-modèle peut se produire pour n'importe quelle API de rappel asynchrone : ce n'est pas spécifique à AFNetworking. J'ai utilisé une recherche du type : "sérialisation des callbacks de blocs imbriqués". Peut-être que quelques balises supplémentaires pourraient aider ? Mais ce n'est peut-être que moi ! :-)