13

シナリオは次のとおりです。

-UIViewController (A) がナビゲーション スタックにプッシュされます
-viewDidLoad で、AFNetworking (アプリケーション全体で共有されるシングルトン AFHTTPClient) を使用して非同期 GET が呼び出され、ビューにさまざまなユーザー要素 (UILabel など) が設定されます。
-リクエストが返される前にユーザーが戻るボタンを押した -
他のアクティブなView Controllerがリクエストを行っている可能性があるため、開いているすべての操作をキャンセルできないと仮定します

質問 #1 は、UIViewController A によって行われたオープン リクエストを追跡し、ユーザーがそのビューを離れたときに未処理のリクエストをキャンセルする必要があるか、またはそれらを終了させて​​無視する必要があるかということです。AFNetworking はブロックを使用するため、更新されるユーザー要素はブロック内に保持されるため、ビューがポップされた後に成功/失敗ブロックが実行されてもクラッシュは発生しません。ただし、それらを無視することの欠点は、不要なネットワーク トラフィックのようです。

質問 2 は、UIViewController A によって行われた操作をキャンセルするコードをどこで実行しますか? ユーザーが戻る (現在のビューをポップする) のではなく、進む (新しいビューをスタックにプッシュする) 可能性があるため、viewDidDisappear は正しくないようです。この場合、ユーザーが来る可能性があるため、開いている要求をキャンセルしたくない現在のビューに戻ると、再度読み込まれません。ただし、ブロックはユーザー要素を保持するため、リクエストの実行中に dealloc または viewDidUnload が呼び出されるとは思わないので、そこに行くことはできないと思います。

これについて考えていただければ幸いです。ベストプラクティスは何だと思いますか？

4

2 に答える 2

8

一般的に言えば、ユーザーがView Controllerを離れたときにリクエストをキャンセルする必要はありません。メモリ管理に関しては、block self への参照により、割り当てが解除されたインスタンスにメッセージを送信することによって引き起こされるクラッシュが防止されるため、心配する必要はありません。

ユーザー エクスペリエンスに関しては、問題が発生するまで特に気にする必要はありません (私たち開発者は、アプリケーションで何が遅くなるかについて完全に間違った推測をするコツを持っています)。ただし、大量の GET リクエストを行っていて、顕著な遅延が発生している場合は、コントローラーを使用することをお勧めしますHTTPClient -cancelAllHTTPOperationsWithMethod:path:(-viewDidUnload:他のコールバックは時期尚早です)。

于 2012-04-17T22:12:37.843 に答える
0

たぶん、すべてのネットワークのものを管理するシングルトンを持ち、そのデリゲートを現在のvc（viewDidLoad内）に設定して、着信データを取得し、vcが消えたときにキャンセルメッセージを送信する（または別のvcを許可する）ことができますその代理人になります）。または、シングルトンは、後の段階で任意のvcがアクセスできるようにデータを保持できます。このため、VCに非同期コードを入れない傾向があります。

于 2012-04-11T18:40:01.100 に答える