問題タブ [nsurlconnectiondelegate]

私は最近、GCD と非同期のレンダリングとデータ検索の作業をたくさん行っていますが、非同期がどのように行われるかについてのメンタル モデルをしっかりと固める必要があります。

一連のメソッドに注目したいと思いsetNeedsDisplayます。NSURLConnectionDelegate

1. setNeedsDisplay を非同期で呼び出すのは正しいですか? 私はよくそれを呼んでdispatch_async(dispatch_get_main_queue(), ^{})混乱します。
2. コールバックは非同期として説明されていNSURLConnectionDelegateますが、実際にはメイン スレッド/実行ループで同時に実行されるわけではありません。私はここでの区別についてはあいまいです。

より一般的には、GCD の最新の iOS 時代では、GCD を作成するためのベスト プラクティスと、これらの方法がうまく連携します。私は定期的に使用していて、トラブルに巻き込まれないように努めているため、ここで一般的なガイドラインを探しています。

乾杯、
ダグ

概要

ビュー コントローラーを表示する iOS アプリ用の SAML ログイン (openID に似たシングル サインオン) ソリューションに取り組んでおり、UIWebViewHTTP 基本/ダイジェストを処理するときにタイミングやタイムアウトの問題が発生しています。の認証UIWebView。

具体的には、クライアントが HTTP 認証チャレンジを取得するとUIAlertView、ユーザーにユーザー ID とパスワードを求めるプロンプトを表示します。ユーザーがすばやく (10 秒未満で) 情報を入力できる場合、それは機能します。ただし、エントリに 10 秒以上かかると、接続が終了したように見え、何も起こりません。

質問

1. connection:didReceiveAuthenticationChallenge:ユーザーにユーザー ID とパスワードの入力を求める (そしてユーザー入力を待たなければならない) のを防ぐ呼び出しのタイムアウトはありますか? 誰かに回避策がありますか (たとえば、接続タイムアウトを延長する方法)?
2. UIWebViewのサブクラスよりもHTTP 基本/ダイジェスト認証を処理するためのより良い方法はありNSURLProtocolますか?

詳細とコード

処理する必要があるほとんどの SAML システムでは、ログインは通常の Web ページとしてUIWebView. ただし、処理が必要なシステムの一部は、モバイル ブラウザー用の HTTP 基本認証または HTTP ダイジェスト認証の使用にフォールバックするため、それも処理できる必要があります。

大きな課題は、UIWebView が下にあるネットワーク呼び出しを公開しないという事実から始まります。必要なものを取得するために、NSURLProtocol必要に応じてサブクラスを作成して登録しました。

これにより、HTTP 基本/認証チャレンジが発行されたときにこのメソッドSMURLProtocolが呼び出されるので、HTTP 基本認証とダイジェスト認証を処理できる YES を返します。

これで、SMURLProtocol が認証チャレンジを処理できることをネットワーク スタックに伝えたので、

ご覧のとおり、UIAlertView を起動して、ユーザーにユーザー ID とパスワードの入力を求めています。ネットワーク コードがバックグラウンド スレッドで実行されているため (どうやら、確かなことはわかりません)、メイン スレッドでそれを行う必要があります。セマフォと明示的な Grand Central Dispatch コードを追加して、時折発生していたクラッシュを回避しました (このスレッドに基づく)。

最後の部分は、ユーザー ID とパスワードを受け入れる UIAlertView デリゲートであり、チャレンジの資格情報を作成します。

概要で述べたように、ユーザーがユーザー ID とパスワードを約 10 秒以内に入力できる場合、これはすべてうまく機能します。それよりも時間がかかる場合、接続がタイムアウトしたように見え、認証情報をチャレンジの送信者に渡しても効果がありません。

以下に示すように、NSURLConnectionDownloadDelegateとNSURLConnectionDataDelegateの両方のデリゲートメソッドを実装しました。

問題は、connection：didReceiveResponse：、connectionDidFinishDownloading：destinationURL：が呼び出された後、connectionDidFinishLoading：が呼び出されないことです。connection：didReceiveData：も呼び出されません。

NSURLConnectionDownloadDelegateメソッドにコメントすると、他の3つは問題なく呼び出されます。

サーバーからJSONを取得するNSURLConnectionsがあります。NSURLConnectionDataDownloadingデリゲートメソッドは、ニューススタンドが問題をダウンロードするために使用します。

これをどのように管理しますか？

これが私が実装しているすべてのデリゲートメソッドです

これが私の.hファイルです

これは私がJSONを取得するためにサーバーに接続する方法です

これは、必要に応じて問題をダウンロードするためのコードです

問題は、サーバーからJSONを取得するための呼び出しにあります。問題のダウンロードは正常に機能します。

特定のフォルダーにNSURLCacheを設定し（../../アプリケーションサポート/オフラインで、OSによってランダムに削除されないようにします）、NSURLRequestReturnCacheDataElseLoadポリシーを使用してNSURLRequestを送信します。

NSURLConnectionDelegateに準拠するクラスによって処理される応答が、キャッシュまたはネットからのものであることをどのように判断できますか？

NSURLConnection について質問があります: イメージをダウンロードしたい:

（正しく）呼び出された最初のデリゲートは

これが一度呼び出された後：

そしてすぐに：

ここまではすべて正しいですが、connectionDidFinishLoading が同じ接続の didReceiveData デリゲートをもう一度起動した後、次の方法で接続を識別します。

これは可能ですか？

更新、詳細情報:

私のアプリは多くの同時接続を開始し、デリゲートが呼び出されたときに、すべての接続の情報を辞書に保存します。次のキーを使用して接続情報を取得します。接続の 99% ではすべて問題ありませんが、1 つの接続 (毎回同じです!) ではこの動作をします

ここに完全な実装があります:

ここにデリゲートの例:

最初のNSURLConnectionを開始した後、2番目のNSURLConnectionを開始しようとしています。私の最初のものは完璧に機能します。適切なデリゲートがすべて呼び出され、すべてが計画どおりに実行されます。ただし、最初のものが終了した後、2番目のものを作成しても、何も起こりません（デリゲートが呼び出されることはありません）。何が起こっているのでしょうか？同じNSURLConnectionを再利用できないことはわかっていますが、再利用する前に再初期化するので、完全に新しい接続である必要があります。

これが（両方の）接続を開始するための私のコードです。これは同じインスタンス変数ですが、再初期化されています。また、最初のものが完全に実行を終了するまで、2番目のものは開始されないことに注意してください。

私はココアのObjective-cの初心者ですので、些細な質問をお許しください。

私は現在、NSJSONSerializationを介していくつかのデータをフェッチし、さらなる作業のために保存するXCODEプロジェクトに取り組んでいます。

このステップでは、データのフェッチの進行状況を、必要なパラメーター（フェッチ元のURLと配列に解析する必要のあるレイヤー）のセッターを持つクラスにカプセル化します。このプロシージャを使用するには、このクラス内にメソッドを作成します。このメソッドは、接続と要求を作成し、データを含む配列を返します。いくつかのテストの後、私はこのクラスのインスタンスを作成しようとし、データのフェッチを開始するメソッドを呼び出しました。

私の問題は、新しいインスタンス「block_stats」からメソッドdata_arrayを呼び出して、同じタイプの配列にデータを格納した後、配列が空になることです。

この動作の理由は、（didReceiveResponse、didReceiveData、connectionDidFinishLoading）のメソッドの使用が非同期で機能しており、ダウンロードが完了する前にdata_arrayの戻りが行われたためです。

ダウンロード部分を含むクラス内のメソッド：

インスタンスを作成し、メソッドを呼び出してデータをフェッチする別のビューのIBAction

誰かアドバイスをいただければ幸いです。できるだけ理解しやすいといいですね。前もって感謝します！

ほとんどの場合、かなり些細な質問ですが、完了ブロックは常に使用して呼び出され[NSURLConnection sendAsynchronousRequest: ...]ますか？または、タイムアウトタイマーを実装する必要がありますか？

MBProgressView呼び出しの前にaを追加し、完了ブロックでのみ削除する次の点を考慮してください。