カスタムUITableViewCellがあり、ユーザーがボタンをクリックすると、サーバーにリクエストを送信してセルを更新します。私はこれをNSUrlConnectionで行い、すべて正常に動作し(これはすべてセルクラス内で行われます)、返されるとデリゲートメソッドが起動され、tableivewコントローラーがこれを処理します。ただし、テーブルビューでセルを作成するときは、dequeue メソッドを使用してセルを再利用します。セルが非同期の nsurlconnection を起動し、これがまだ進行中にセルが再利用された場合、現在の接続は消去されますか? セルが再利用された場合、セルに割り当てられた実際のメモリがまだそこにあることを確認したいので、接続はその義務を果たすことができますか??
2 に答える
UITableViewCell
サブクラス化してメソッドをオーバーライドすることで、 の動作をカスタマイズできます-perpareForReuse
。この場合、セルがデキューされるときに接続を破棄することをお勧めします。nil
接続を継続する必要がある場合は、それへの参照を削除 (に設定) し、そのデリゲート メソッドを別の場所で処理する必要があります。
セルに表示したい接続やデータの参照を保持することは、後で発生した問題を回避するためにどれだけの労力を費やしたとしても、決して良い考えではありません。あなたのアプローチは決して信頼できるものではありません。
あなたの場合、ユーザーがテーブルビューを上下にすばやくスクロールすると、アプリが起動し、数十の接続がキャンセルされる可能性がありますが、何かをロードするために終了することはありません. これはひどいユーザー エクスペリエンスとなり、アプリがクラッシュする可能性があります。
MVCを念頭に置いてアプリを設計することをお勧めします。セルは、モデル データを表示するための単なる手段であり、他には何もありません。それは、この建築設計におけるビューです。
そのために、Table View Delegate は、特定の行に表示されるモデルのプロパティを取得し、セルをセットアップする必要があります。モデルはネットワーク接続をカプセル化します。コントローラーは、変更通知を管理および更新し、ユーザー入力を処理する役割を担います。
いくつかの Apple のサンプルでは、このトピックに関する詳細が提供されています。また、MVC についての優れた紹介もあります。ぜひご覧ください。;)
http://developer.apple.com/library/ios/#documentation/general/conceptual/devpedia-cocoacore/MVC.html
「Your Second iOS App: Storyboards」にも、「データ コントローラー クラス」を作成する手順が説明されています。とても便利です!
ここで、モデルを更新する NSURLConnection を使用すると、もう少し複雑になる可能性があります。「遅延初期化モデル」を扱っています。つまり、コントローラーがプロパティにアクセスするときに、「実際の」データがまだ利用できない場合に、代わりに「プレースホルダー」データを提供する場合があります。ただし、モデルはそれをロードするためのネットワーク リクエストを開始します。最終的にロードされると、モデルは何らかの形で Table View Controller に通知する必要があります。ここで注意が必要なのは、モデルとテーブル ビュー間の同期の問題を混乱させないことです。モデルのプロパティはメイン スレッドで更新する必要があります。更新中は、テーブル ビューがモデルのプロパティにアクセスしないようにする必要があります。これを実現するためのいくつかの手法を示すサンプルがいくつかあります。