実りある検索結果を得るには、この質問をうまく表現できないようです。
ネットワーク接続が終了するのを待っている間に一番上のビュー コントローラを変更した場合、ネットワーク リクエストに関するエラー処理を構築する必要がありますか? nil
または、コールバック ブロックがメッセージを送信しても何も起こらないと期待できますか? または、プロセスを丁寧に停止するプリプロセッサの魔法はありますか?
上記の答えは、メイン スレッド以外のすべてのプロセスで同じですか?
実りある検索結果を得るには、この質問をうまく表現できないようです。
ネットワーク接続が終了するのを待っている間に一番上のビュー コントローラを変更した場合、ネットワーク リクエストに関するエラー処理を構築する必要がありますか? nil
または、コールバック ブロックがメッセージを送信しても何も起こらないと期待できますか? または、プロセスを丁寧に停止するプリプロセッサの魔法はありますか?
上記の答えは、メイン スレッド以外のすべてのプロセスで同じですか?
非同期リクエストのデリゲートがビュー コントローラーであり、そのビュー コントローラーが非アクティブになっている場合は、リクエストをキャンセルする必要があります。
リクエストをキャンセルしない場合、ユーザーに関係のないことをしようとしている可能性があります。この問題は 1 回発生し、関連性のないポップアップ アラートがユーザーに表示されました。
を使用している場合は、メソッドNSURLConnection
を呼び出すだけです。cancel
これを行うには、通常、NSURLConnection
オブジェクトの強力なポインターを保持する必要があります。
リクエストをキャンセルするのに適した場所は、prepareForSegue
別のビューに切り替える直前です。
ナビゲーション コントローラー (プッシュ セグエ) やモーダル セグエでは、View Controller がスタックに保持されるため、解放されません。デリゲート メソッドは引き続き呼び出されます。他の状況でも、競合状態に陥る可能性があるため、必ずキャンセルしてください。
viewWilLDisappear
また、View Controller のメソッドでリクエストをキャンセルすることも検討する必要があります。リクエストが応答を受け取る前にユーザーがホーム ボタンをクリックしてからアプリケーションに戻ると、リクエストはエラー (タイムアウト) になる可能性が高くなります。接続エラーが発生したときに何もしていない場合は問題ありませんが、エラーが表示されている場合、ユーザーはアプリを再起動したときにすぐにエラーが表示されることを期待しません。
MVC パラダイムを仮定すると、特定のビューに関連するすべてのプロセスの答えはほとんど同じです。
場合によっては、非同期リクエストへのデリゲートが (View Controller ではなく) 別のクラスのインスタンスである場合があり、キャンセルする代わりに、同じスレッド (メイン実行ループ) であっても、常にレスポンスを処理します。「バックグラウンドで」コンテンツを更新しているときにこれを行います。