Je regardais le NSURLConnection qui pourrait être utilisée pour établir une connexion sync ou async à une URL et ensuite récupérer ses données... beaucoup de changements ont été apportés à cette classe avec IOS 5 et j'ai vu qu'ils ont introduit certains protocoles formels liés à l'authentification ou au téléchargement, mais je ne vois pas, par exemple, si la classe connection:didReceiveResponse: Le message (qui a été précédemment envoyé au délégué et qui n'est plus disponible) est toujours disponible dans certains protocoles Comment implémenter une connexion asynchrone et récupérer, par exemple, les en-têtes HTTP dès que la réponse est reçue ? Je suis sûr qu'il y a un meilleur moyen que d'utiliser NSURLConnection ainsi que le connection:didReceiveResponse: message des méthodes comme stringWithContentsOfURL chargent-ils toujours le contenu de manière synchrone ? Comment mettez-vous en œuvre les téléchargements asynchrones dans vos applications en évitant les méthodes obsolètes et en réagissant aux événements tels que _http response received_m etc ? Lancez-vous les téléchargements synchrones en tâche de fond, si possible ?
Réponses
Trop de publicités?
NSURLConnectionDelegate est devenu un protocole formel (c'était un protocole informel dans les versions précédentes). Dans ce protocole, les méthodes suivantes (non dépréciées) sont déclarées :
connection:didFailWithError:connectionShouldUseCredentialStorage:connection:willSendRequestForAuthenticationChallenge:
De plus, il existe deux sous-protocoles qui se conforment à NSURLConnectionDelegate :
NSURLConnectionDataDelegate est utilisé pour les délégués qui chargent des données en mémoire, et déclare les méthodes suivantes, dont certaines vous seront certainement familières :
connection:willSendRequest:redirectResponse:connection:didReceiveResponse:connection:didReceiveData:connection:needNewBodyStream:connection:didSendBodyData:totalBytesWritten:totalBytesExpectedToWrite:connection:willCacheResponse:connectionDidFinishLoading:
NSURLConnectionDownloadDelegate est utilisé pour les délégués qui stockent les données directement dans un fichier disque, et déclare les méthodes suivantes :
connection:didWriteData:totalBytesWritten:expectedTotalBytes:connectionDidResumeDownloading:totalBytesWritten:expectedTotalBytes:connectionDidFinishDownloading:destinationURL:
Comme vous pouvez le constater, vous pouvez toujours utiliser vos anciens délégués, éventuellement avec quelques modifications mineures.
Pour plus d'informations, voir le Document sur les différences d'API entre iOS 4.3 et iOS 5.0 et NSURLConnection.h dans votre installation locale de Xcode. Lorsqu'une nouvelle version du SDK est publiée, il n'est pas rare que la documentation contenue dans les fichiers d'en-tête soit plus fiable que celle disponible dans la bibliothèque du développeur. Il faut un certain temps pour que cette dernière soit mise à jour.
Je viens de rencontrer ce même problème. Il semble que l'envoi d'une requête asynchrone soit plus simplifié avec des blocs et des NSOperationQueue .
+ (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue *)queue completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handlerCela signifie que le délégué n'est désormais utilisé que pour les questions d'authentification et d'échec.
NON ! Ils ne sont PAS limités à une utilisation pour les problèmes d'authentification et d'échec si vous regardez attentivement dans la bibliothèque d'Apple.
Depuis l'introduction de +(void)sendAsynchronousRequest:queue:completionHandler: à l'objet de classe NSConnection, beaucoup de choses qui peuvent effectuer autant de NSConnectionDelegate comme auparavant, peut maintenant être utilisée dans des protocoles formels appelés " NSConnectionDataDelegate " & NSConnectionDownloadDelegate l'ouverture d'une nouvelle pièce pour ajouter plus d'éléments à l'édifice. NSURLConnection méthodes. (à partir de iOS5)
Je pense donc qu'il s'agit d'une amélioration, qui ne limite pas leur utilisation.
