J'ai vérifié d'autres questions pertinentes pour cela, mais la seule réponse est "Utilisez Nous l'avons suivi au fait que Certains développeurs que nous parlions de dire que cela s'améliore dans iOS 5, nous devons nous assurer que notre SDK est compatible avec IOS 4.3 au moins.
Je veux confirmer que cela concerne un problème dans Toutes les alternatives que j'ai trouvées jusqu'à présent sont basées sur Une liste d'autres bibliothèques examinées sont:
Je suis conscient qu'il y a des questions similaires ici est à la suite d'un bon remplacement pour ASIHTTPEQUEST? et ici alternative ASIHTTPRequest mais les deux des solutions sont basées sur NsurlConnection.
Edit: J'ai remarqué que j'ai signalé la mauvaise question au début de mon message, c'est donc mis à jour. Il pointe d'un fil de 2008 et j'en ai vu des semblables mais aucune récente. ASIHTTPQUEST " car cela ne se développe plus, je voulais demander quelles utilisatrices d'alternatives utilisent, tout en travaillant sur Notre SDK je suis tombé sur beaucoup de comportement étrange dans nsurlconnection lors de la réception de données du serveur.
nsurlconnection ne traite pas de réponses en codage à découpage. Ou au moins donc nous lisons dans cette question ici ici NsurlConnection et codage de transfert "chunked"
nsurlconnection et comment les gens traitent de cela.
nsurlconnection et je suppose que tel sera le même défaut. ASIHTTPQUEST a fait du travail car il est basé un peu plus bas que nsurlconnection , mais cherchait des solutions de rechange dans la connaissance qu'il n'est plus pris en charge.
restakit ,
sharekit ,
lrr. ,
Afnetworking ,
Turlrequest
3 Réponses :
Il n'y a aucune alternative que je suis au courant.
Toutes les autres bibliothèques sont construites sur NsurlConnection. Bien que vous puissiez utiliser l'une des bibliothèques non-iOS, par exemple. libcurl.
ASIHTTPEQUEST est la seule bibliothèque dont je suis conscient de celle construite sur la couche de travail CFNet. C'était (peut-être indirectement) la raison principale que le développeur original a cessé de travailler dessus - car il n'utilise pas NsurlConnection, il a un lot du code.
Ce n'est probablement pas strictement correct de dire que ASIHTTPEQUEST n'est plus supporté. Il est vrai que le développeur original ne fonctionne plus dessus, mais si vous regardez le GitHub commet, vous verrez qu'il est toujours en train de travailler par d'autres personnes. Beaucoup de gens l'utilisent toujours, pour diverses raisons, moi-même incluses.
Après avoir dit tout cela, revenir au problème que vous avez: je ne suis pas sûr qu'un thread de 3 ans est nécessairement une référence définitive pour prouver qu'une libération de 1 an (IOS 4.3) de NsurlConnection n'a pas t Supporte les transferts décrits. Des transferts chuntés sont tellement utilisés sur le Web qu'il semble très improbable qu'il ait un problème aussi grand et évident. Il est possible qu'il existe quelque chose de très particulier au serveur que vous utilisez qui causent le problème.
Je suis d'accord et je pensais trouver beaucoup plus si c'était toujours une question grave. En utilisant ASI signifie maintenant que nous ne l'avons pas exploré plus loin, mais juste avant de poster cela, je commencerais à me demander (d'où la confirmation de la recherche). Je reviendrai probablement et j'y regarderai quand j'en aurai une chance, car il est préférable d'utiliser NsurlConnection si possible (la base de code plus petite et les bibliothèques n'ont pas besoin d'être importées, etc.) une fois que je faisais, je m'assurerai de Mettez à jour cela pour quelqu'un d'autre se demandant.
Les transferts chuntés sont pris en charge par NsurlConnection. Je les utilise.
Définissez des accessoires: p>
- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error { NSLog(@"Something went wrong..."); }établir une connexion p>
- (void)connectionDidFinishLoading:(NSURLConnection *)connection { [connection release]; }enregistrer votre méthode de rappel pour la connexion établie p>
- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data { NSString* aStr = [[NSString alloc] initWithData:data encoding:NSASCIIStringEncoding]; NSLog(@"This is my first chunk %@", aStr); }Enregistrez votre méthode de rappel pour "Chunk reçu" P>
- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response { // You may have received an HTTP 200 here, or not... [responseData setLength:0]; }enregistre votre rappel "Connexion fini": P>
NSURL *url = [NSURL URLWithString:@"...."]; self.responseData = [[NSMutableData alloc] initWithLength:0] ; NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url]; self.connection = [[NSURLConnection alloc] initWithRequest:request delegate:self startImmediately:YES];et enfin, vous enregistrez que "Connexion a échoué" Callback: P> Li> ol>
NSMutableData * responseData; NSURLConnection * connection;
Comme vous pouvez le constater, c'est juste simple et vous n'avez pas besoin d'utiliser d'autre cadre. J'utilise ASIHTPTP tous les jours, mais pour le codage de transfert à chunder, c'est assez :)
i3.kym-cdn.com/photos/ Images / Newsfeed / 000/150/505 / ...
Merci, je vais donner un test dès que j'aurai le temps de fouiller à nouveau dans le SDK et je m'assurerai de définir cela comme la réponse si cela fonctionne.
Juste pour choisir la personne suivante qui obtient ici et ne peut toujours pas obtenir NsurlConnection de travailler avec des données codées par le morceau.
NsurlConnection fonctionnera avec un codage à décomposition, mais a un comportement interne non divulgué de manière à tamponner les 512 premiers octets avant d'ouvrir la connexion et de laisser quoi que ce soit en cas de contenu de contenu dans l'en-tête de réponse est "Texte / HTML", ou "Application / octet-Stream". Cela concerne au moins IOS7.
Cependant, il ne tamponne pas la réponse si le type de contenu est défini sur "Texte / Json". Donc, quiconque qui ne peut pas être chunté codé des réponses NsurlConnection à fonctionner (c.-à-d. Les rappels ne sont pas appelés) doivent vérifier l'en-tête de réponse et le modifier sur le serveur sur "Text / Json" s'il ne casse pas le comportement des applications d'une autre manière. .
Je ne comprends pas la logique dans le deuxième paragraphe "Il ne tamponne pas la réponse si le type de contenu est défini sur" text / json "et" et le modifier sur le serveur sur "Text / Json" semble être contradictoire. Vous ne voulez pas que NsurlConnection tamponnent la réponse? Sinon pourquoi pas?
Je ne suis pas sûr que je comprenne ce que vous ne comprenez pas, mais je le repousserai: il sera tamponné si le type de contenu n'est pas du texte / JSON. Ce n'est pas un jugement de valeur, je déclare juste le comportement. Personnellement, je ne veux pas que ce soit en mémoire tampon car le serveur que je n'avais pas de contrôle de N'a pas défini de texte / JSON en tant que type de contenu, ce qui provoque la réponse (qui n'est pas réellement JSON, mais un protocole de ligne personnalisé) ne pas venir. Je ne veux pas que ce soit en mémoire tampon car la logique d'application et une action supplémentaire dépendent de quelque chose à l'intérieur de ces 512 octets qui ne viendront jamais. Pensez «connexion de connexion» ou similaire.
@MAKSA TEXT / JSON n'est pas un type mime officiel. Vos commentaires s'appliquent-ils également à l'application / JSON?
Pas encore, je voulais vérifier que d'autres développeurs avaient connu des résultats similaires. Je viens de réaliser que j'ai mis le mauvais lien dans ma question. Je voulais dire ( Stackoverflow.com/questions/8606493/... < / a>). J'ai mis à jour le message avec plus d'informations.