2012-02-08 18 views
2

私はAFNetworkingを使用しており、非常に好きです。 私のサーバーからJSONデータを取得する必要があります。それは正常です。完全に動作します。AFNetworking + JSON + progressダウンロード

私はsetDownloadProgressBlockを追加しましたが、JSONダウンロードでは動作しないと思います。ダウンロードするバイト数を見積もることができない可能性があります。

マイコード:

NSMutableURLRequest *request = [[VinocelaHTTPClient sharedClient] requestWithMethod:@"GET" path:@"ws/webapp/services/pull" parameters:nil]; 

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

    } failure:^(NSURLRequest *request, NSHTTPURLResponse *response, NSError *error, id JSON) 
    { 
    }]; 

    [operation setDownloadProgressBlock:^(NSInteger bytesWritten, NSInteger totalBytesWritten, NSInteger totalBytesExpectedToWrite) { 
    NSLog(@"Get %d of %d bytes", totalBytesWritten, totalBytesExpectedToWrite); 

    }]; 

    [operation start]; 

そして、私の結果:

ゲット27129 -1のバイト

ゲット127481 -1バイト

の-1バイトの176699

これは、ZIPファイルや画像に反してJSONデータをダウンロードする際にAFNetworkingが実際のサイズを見積もることができないと思いますか?

答えて

2

ソースを調べると、進行中のコールバックは、キャッシュされた内部NSHTTPURLResponseオブジェクトのexpectedContentLengthプロパティに渡されたようです。したがって、何らかの理由でサーバーが正しくContent-Lengthヘッダーを送信していない場合、またはチャンク転送符号化を行っている場合、その値は不明で、値はNSURLResponseUnknownLength(-1と定義されます)が返されます。

HTTPリクエストによって返されたヘッダーをアプリのコンテキスト外で検査してみてください。 Content-Lengthヘッダーの値が正常であれば、AFNetworking自体に問題がある可能性があります。存在しない場合は、サーバーに問題があります。チャンクされた転送エンコーディングを使用してHTTPサーバーがJSON応答を送信したことはありませんでした(ほとんどの場合、コンテンツサイズは比較的小さく、ヘッダーが送信された時点でわかっているはずです)。

+1

OK Warrenm。私はレスポンスヘッダーを出力し、content-lengthは存在しません。あなたが正しい。私は自分のサーバー上でRails 3を使用しています。私はそれが存在しない理由を見つけようとし、おそらくそれをRailsなどに強制します。まあ、私はこれを追加しました:config.middleware.use Rack :: ContentLengthを私のRails設定に入れてください。しかし結果はばらばらになります: "Content-Length" = 2658; => 2658バイトの176699を取得します。私は、JSONが2658よりも多くのバイトであると確信しています... –

+0

コンテンツの長さの不一致のようなサウンドは、完全なサイズとgzipされたサイズとの間の不一致と関係する可能性があります。それが役立つかどうかわからない... – mattt

関連する問題