私のアプリケーションは現在のデバイスの場所を取得し、これをサーバーに POST して、テーブル ビューに表示される辞書を返します。現在、私は CLLocationManager デリゲート メソッドと AFJSONRequestOperation (AFNetworking の retrieve-data-through-NSURLConnection-in-NSOperation クラス) を使用してジョブを実行していますが、この機能は 1 つのビュー コントローラー メソッド内にあり、これを再利用できるようにしたいと考えています。他のView Controller間。
独自の NSOperation サブクラスを作成する予定ですが、最初に、別の NSOperation 内で NSOperations (AFJSONRequestOperation) を開始する際に目に見えない落とし穴があるかどうかを知りたいと思いました。これは期待どおりに機能しますか、それとも操作間の依存関係を持つキューを作成する方法を見つける必要がありますか?
NSOperation 内で NSULRL 接続操作をスケジュールすると、メインの実行ループでスケジュールしない限り失敗します。AFJSONOperation (または AFURLOperation の任意のサブクラス) は成功します。内部では、AFNetworking 操作が独自の NSOperationQueue およびカスタム実行ループでスケジュールされているためです。
あ、はい。頑張れ。NSOperation サブクラスを使用して、すべてのワーカー プロセスを分離します。VC またはモデルの途中で GCD をフラットにするよりもはるかにクリーンです。
警告 - すべての AFNetworking 操作はブロック ベースであり、非同期的に返されるため、NSOperation サブクラスは並行である必要があります。Apple は、 Concurrent NSOperation Subclassesのドキュメントでこれを構築する方法の詳細な説明を提供しています
必要に応じて、並行 NSOperation サブクラスの構築をスキップし、既にメイン キューから離れているため、NSOperation 内からネットワーク操作を同期的に開始することもできます。
すべての NSOperation は内部で GCD を使用しており、GCD はネストされた dispatch_async 呼び出しに問題がないため、ロジックが正しい限り、NSOperations をネストしても問題が発生することはないと思います。