URL Loading Systemを拡張するCocoa勉強会 2004.04.10(土) 木村 渡

はじめにこの発表では、Mac OS XのURL Loading System、そのなかでもNSURLProtocolのサブクラスを実装し、URLLoading SystemをあらたなURL Schemeに対応させることについて説明する。また、認証・キャッシュについてもとりあげる。ポイントは次の２つ。

NSURLProtocolのサブクラスにより、URLで表現されるデータへのアクセスを行う。NSURLProtocol（のサブクラス）はプロトコル NSURLProtocolClientを実装したオブジェクトと協調して動作する。

URL Loading System OverviewURL Loading Systemに関わるクラス、およびその役割は次のとおり。（ADCの「URL Loading SystemOverview」より）

URL LoadingNSURLResponseNSURLRequestNSURLConnectionNSURLDownload

Cache ManagementNSURLCacheNSCachedURLResponse

Authentication and CredentialNSURLProtectionSpaceNSURLCredentialStorageNSURLCredentialNSURLAuthenticationChallengeNSURLAuthenticationChallengeSender - protocol

Cookie Storage - 今回は説明の対象外NSHTTPCookieStorageNSHTTPCookie

Protocol SupportNSURLProtocolNSURLProtocolClient - protocol

Simple Loading基本的なケース。プロトコルはクライアントのメソッド（NSURLProtcolClient）を通して、ロードの結果・経過を通知する。

URLProtocol:didLoadData:は１度のロード中に何度も呼び出されることもある。また、ロード中にエラーが発生し、処理を継続できないときは、クライアントにURLProtocol:didFailWithError:で通知する。

各クラスの役割

プロトコルリソースへのアクセス

クライアント結果・経過の保持・表示

サブクラスで定義するメソッド

NSURLProtocolのサブクラスでは、以下のメソッドをオーバーライドして定義する必要がある。

+canInitWithRequest:リクエストされたURLが、このクラスで扱えるか。

+canonicalRequestForRequest:リクエストされたURLを補正する。たとえば、"file://localhost/tmp/thisfile"や "file:/tmp/thisfile"というURLがあったとき、"file:///tmp/thisfile"というURLに統一することができる。そうすることで、キャッシュが有効に利用できるなどウレシイことがある。（WebKit SDK MLより）とくに必要がなければreturn request;とだけコードを書けばよい。

-startLoadingURLのロードを開始する。実際にロードを行うメソッド。

-stopLoadingURLのロードを中止する。ユーザが中止を指示したとき、ロード中にエラーが発生したときなどに呼び出される。

実装したプロトコルのクラスは+[NSURLProtocol registerClass:]で登録しなければURL Loading Systemでは有効とはならない。

Loading with Cacheキャッシュを利用するケース。キャッシュデータは、NSURLCacheにより管理される。また、キャッシュデータはNSCachedURLResponseのインスタンスとして表現される。

あるURLをロードしようとして、有効なキャッシュがあったときには、次のようになる。（後半はロード後にキャッシュデータを保存しておく処理）

プロトコルは、リクエストの-[NSURLRequest cachePolicy]にしたがってキャッシュが有効かを判定する。

各クラスの役割

プロトコルキャッシュデータが有効かを判定

クライアントキャッシュデータの取り出しキャッシュデータの保存（このときキャッシュデータの作成も行う）

NSURLCacheキャッシュデータを保存・取り出しできる入れ物

Loading with Authentication認証の必要なケース。認証はプロトコルNSURLAuthenticationChallengeSenderを実装したオブジェクトが行う。プロトコルのクラスで実装するのが簡単だが、下の図では説明のためプロトコルと認証のオブジェクトを分けて書いてある。

プロトコルは、認証に成功後、ユーザ／パスワードを保存する。このとき、NSURLCredentialPersistencePermanentが指定されていれば、ユーザ／パスワードはキーチェーンに保存される。

また、-[NSURLCredentialStorage defaultCredentialForProtectionSpace:]によりユーザ／パスワードを取り出して、クライアントに尋ねずに処理を継続することもできる。

各クラスの役割

プロトコル = NSURLAuthenticationChallengeSender認証の実際の実行ユーザ／パスワードをNSURLCredentialStorageに保存

クライアントユーザ／パスワードの入力の受付

NSURLCredentialStorageユーザ／パスワードを保存・取り出しできる入れ物

NSURLCredentialユーザ／パスワードの組をあらわす

NSURLProtectionSpace認証先のホスト名、ポートなどをあらわす

NSURLAuthenticationChallengeNSURLCredential, NSURLProtectionSpace, NSURLAuthenticationChallengeSenderなどをまとめて保持

NSURLCredential、NSURLProtectionSpace、NSURLAuthenticationChallengeの３つは振る舞いをもたない、データクラス。

おまけ

どんなときにプロトコルを実装するか

本当に、あたらしいURLスキームに対応させたいときあるURLを別の内容で置き換えたいとき

正直、後者のほうが用途が多そう。

NSURLProtocolでは、URLの文字列で示されるリソースをロードする手順のみが標準化されていて、自由度はあまり高くない。多様なアクセスを行うには、NSHTTPURLRequestのようにリクエストのクラスも拡張する必要がある。

IMAP URL Scheme

サンプルの理解のため、参考まで。IMAPのURL表現は、RFC2192で定義されており、次のような形式をとる。

imap://user@imapserver/inbox;TYPE=listフォルダの一覧を取得する。

imap://user@imapserver/cocoastudy/?SUBJECT%20NSURLフォルダ内のメールを検索する。（フォルダ内のメールの一覧が得られる）

imap://user@imapserver/cocoastudy/;UID=155フォルダ内のUIDで表されるメールの内容を取得する。

ユーザが指定されなかったときは、anonymousでのログインとなる。

資料内でのコトバの定義

',&!+

NSURLProtocolのサブクラスのインスタンス。 *��-&

NSURLProtocolClientを実装したオブジェクト。�($")%�#

NSCachedURLResponseのインスタンス。

参考情報

������������� �����������

http://developer.apple.com/ documentation/Cocoa/Conceptual/URLLoadingSystem/index.html

とにかく基本。行間を読みまくれっ。������������

http://www.lists.apple.com/mailman/listinfo/webkitsdk-dev

たま～に有用な情報が得られる。 �����

http://homepage3.nifty.com/kimuraw/proj/sandtrip.html

木村が作成している、SafariにローカルCGI機能を追加するソフトウェア。実際にNSURLProtocolのサブクラスを実装したもので、公開されているものを他に知らないのであげておく。

情報少なすぎだってば...