LazyTableImages コードをそのまま使用している場合、それは正常です。読み込みは、スクロールが終了するまで延期されます。私のテスト アプリ (単純な instagram のようなストリーム) では、別のアプローチを使用します。基本的には、セルをサブクラス化し、セル自体からダウンロードを開始し、セルをダウンロード マネージャーのデリゲートとして使用してから、セルの UI を更新します。ダウンロードが終わったら
詳細に
- cellForRowAtIndexPath メソッドでダウンロードを開始します (ビューがスクロールしている場合、LazyTableImages はダウンロードを延期します。スクロール中にロードしても問題ないため、ダウンロードを延期しません) セルの「startDownload」メソッドを呼び出します。
- 私のセル サブクラスはダウンロード マネージャーのデリゲートとして設定され、ダウンロードが完了すると、セルはプレースホルダーを実際の画像に変更します (これはカスタムの "downloadManagerDidFinishDownloadForImage:(UIImage*)image" デリゲート メソッドで実行され、細胞サブクラス)
- 私のセル サブクラスでは、prepareForReuse メソッドをオーバーライドします。ここで、セルが再利用される場合は、ダウンロードを停止することを選択できます。私の場合、デリゲートの設定を解除し、ダウンロードを続行します。これは、コア データで作成された画像キャッシュがあり、キャッシュを続行したいからです。
さらに、次の 2 つの点に注意する必要があります。
- ダウンロード マネージャーはバックグラウンド スレッドで動作する必要があります
- メインスレッドでセル UI を更新してください。使用できます
:
dispatch_async(dispatch_get_main_queue(), ^{
//update here your cell UI
});
デリゲート メソッドで (そのメソッドがダウンロード マネージャーによって呼び出された場合は、必ずバックグラウンド スレッドで呼び出されるため、ディスパッチを使用してメイン スレッドで「移動」する必要があります)。
必要に応じて、私の例を見ることができますが、それは「そのまま」です(これはテストアプリであり、スパゲッティコードと質問に関係のないものがたくさんあります;-)
http://www.lombax.it/documents/InstaXplore.zip
私の例では、次を確認する必要があります。
- BrowseCell <-- セルのサブクラス
- BrowsePhotoViewController <- テーブルビューコントローラー
他にもコアデータストレージやインスタグラム関連ですが、基本的には
- cellForRowAtIndexPath で新しいセルを作成 (または前のセルを再利用) し、InstaImage アイテム (カスタム イメージ) を渡します。
- InstaImage は、キャッシュされたコピーが存在するかどうかを確認し、存在しない場合はダウンロードを開始し、セルに警告を返します
何度も試すためのキャッシュクリアボタンがあります:-)