Co to są alternatywy dla NSURLConnection dla kodowania transferu kodowanego?

Question

Sprawdziłem, czy nie ma innych istotnych pytań, ale jedyną odpowiedzią jest "Użyj ASIHTTPRequest", ponieważ nie jest już rozwijany Chciałem zapytać, jakich alternatyw używają ludzie, podczas gdy pracując nad naszym SDK natknąłem się na wiele dziwnych zachowań w NSURLConnection podczas odbierania danych z serwera.

Odsłuchujemy, że NSURLConnection nie radzi sobie dobrze z odpowiedziami w kodowaniu kodowanym. Lub przynajmniej tak czytamy w tym pytaniu tutaj NSURLConnection and "chunked" transfer-coding

Niektórzy programiści, z którymi rozmawialiśmy, mówią, że w systemie iOS 5 poprawiają się, musimy upewnić się, że nasz pakiet SDK jest wstecznie zgodny z co najmniej systemem iOS 4.3.

Chcę potwierdzić, że to jest problem w NSURLConnection, i jak ludzie mają z tym problem.

Wszystkie alternatywy, które znalazłem do tej pory, są oparte na NSURLConnection i zakładam, że takie będą mieć tę samą wadę. ASIHTTPRequest w rzeczywistości działało, ponieważ opierało się na nieco niższym niż NSURLConnection, ale szukało alternatyw dla wiedzy, że nie jest już obsługiwane.

Lista innych bibliotek spojrzał na to: Restkit, ShareKit, LRResty, AFNetworking, TTURLRequest

Jestem świadomy istnieją podobne pytania tutaj i tutaj ASIHTTPRequest alternativeIs RESTKit a good replacement for ASIHTTPRequest? Ale oba rozwiązania są oparty na NSURLConnection.

EDYCJA: Zauważyłem, że wskazałem złe pytanie na początku mojego posta, więc jest ono aktualizowane. Wskazuje na wątek z 2008 roku i widziałem podobne, ale żadne nie są najnowsze.

Answer 1

Przenośne przesyłanie jest obsługiwane przez NSURLConnection. Używam ich.

1. zdefiniować niektóre rekwizyty:

   NSMutableData * responseData; 
   NSURLConnection * connection; 
   

2. nawiązać połączenie

   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]; 
   

3. Zarejestruj swoje metody wywołania zwrotnego dla connect jonowy założona

   - (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response { 
       // You may have received an HTTP 200 here, or not... 
       [responseData setLength:0]; 
   } 
   

4. Zarejestruj metody wywołania zwrotnego dla "chunk otrzymał"

   - (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data { 
       NSString* aStr = [[NSString alloc] initWithData:data encoding:NSASCIIStringEncoding]; 
   
       NSLog(@"This is my first chunk %@", aStr); 
   
   } 
   

5. Rejestracja Twoja "połączenie zakończone" callback:

   - (void)connectionDidFinishLoading:(NSURLConnection *)connection { 
       [connection release]; 
   } 
   

6. I wreszcie, zarejestruj ty "Połączenie nie powiodło się" callback:

- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error { 
    NSLog(@"Something went wrong..."); 
} 

Answer 2

Nie ma żadnych alternatyw, których jestem świadomy.

Wszystkie pozostałe biblioteki są zbudowane na podstawie NSURLConnection. Chociaż można użyć jednej z bibliotek innych niż iOS, np. libcurl.

ASIHTTPRequest jest jedyną biblioteką, o której wiem, że jest zbudowana na wierzchu warstwy CFNetworking. Było to (być może pośrednio) główny powód, dla którego pierwotny programista przestał nad nim pracować - ponieważ nie używa NSURLConnection, ma on lot kodu.

Prawdopodobnie nie jest prawdą stwierdzenie, że ASIHTTPRequest nie jest już obsługiwany. Prawdą jest, że pierwotny programista już na nim nie działa, ale jeśli spojrzysz na zatwierdzenia github, zobaczysz, że nadal pracują nad nim inni. Wiele osób nadal go używa, z różnych powodów, włącznie z mną.

Powiedziawszy to wszystko, wracając do problemu, który masz: Nie jestem pewien, czy 3-letni wątek jest koniecznym referencyjnym dowodem na to, że 1-letnia wersja (tj. IOS 4.3) NSURLConnection doesn obsługuje trupowe transfery. Chunked transfery są tak bardzo wykorzystywane w Internecie, że wydaje się wysoce nieprawdopodobne, aby problem był tak duży i oczywisty. Możliwe, że przyczyną problemu jest coś, co jest bardzo szczególne dla serwera, z którego korzystasz.

Answer 3

Wystarczy, aby dostroić się do następnej osoby, która ją tu i wciąż nie może dostać się do NSURLConnection pracować z zakodowanymi danymi.

NSURLConnection będzie działał z kodowaniem kodowanym, ale ma nieujawnione wewnętrzne zachowanie, które będzie buforować pierwsze 512 bajtów, zanim otworzy połączenie i wszystko przez IF Content-Type w nagłówku odpowiedzi będzie "text/html", lub "strumień aplikacji/oktetów". Dotyczy to przynajmniej iOS7.

Jednak nie buforuje odpowiedzi, jeśli Content-Type jest ustawiony na "text/json". Tak więc, ktokolwiek nie może uzyskać zakodowanych odpowiedzi NSURLConnection do pracy (tj. Wywołania zwrotne nie są wywoływane) powinien sprawdzić nagłówek odpowiedzi i zmienić go na serwerze na "text/json", jeśli nie zakłóca to działania aplikacji w inny sposób .