lifeLOG + REPOsitory

twitter より (2011-11-18)

2011-11-19T16:39:00.001+09:00

13:01 納得した！ → "@yoshikaw: "「一番いいおすすめを頼む」〜5分でわかるレコメンドエンジンの基礎〜 (Gunma.web #3 2010/12/11)" http://t.co/PEtTmx6N"

twitter より (2011-11-07)

2011-11-08T01:03:00.001+09:00

11:14 Ruby 1.9.3 を Lion (+ xcode) でビルドする際の注意点が載っている。 → http://t.co/YC9ch0OT

twitter より (2011-10-26)

2011-10-28T08:07:00.001+09:00

11:20 MobileMe 時代には複数のMac間でMail.app上のローカルなメモが同期できていたのに、iCloudに移行してからそれができなくなった。もちろん、iCloud上にメモを作れば同期する。とはいえ、こういう仕様変更にはイライラさせられる。
11:31 やっぱりバグだったのかもな。ローカルなメモが同期していたのは。
12:01 iMac が Lion になって以来、スクロールバーが常時表示されないのはユーザ体験の観点から言ってどうかな、と思ってきた。が、これってデバイス(というか、Mac の機種)によって変わるのな。MacBook (Early 2008) を Lion に移行させて初めてわかった。
12:05 ちなみに、スクロールバーの表示方式は「システム環境設定」>「一般」>「スクロールバーの表示」で切り替えられる。デフォルトは「入力デバイスに基づいて自動的に表示」。当然のことだが、常に表示させるとコンテンツの表示エリアが小さくなる。

Lion アップデート (10.7.1 → 10.7.2)

2011-10-21T13:43:00.002+09:00

Lion (client) 10.7.2 update
iMac (Mid 2010)

アップデートは 2011-10-19 に実行。再起動後に iCloud への以降をうながすウィンドウが出てきたが、iOS デバイスのアップデートを放ってあるので、iCloud への以降もしばらく保留。MacBook も Snow Leopard のままになっているし。

Lion アップデート (10.7 → 10.7.1)

twitter より (2011-08-25)

2011-08-26T18:19:00.001+09:00

19:02 そうか。ジョブズが CEO 辞任したのか。彼のスピーチが見られなくなるとしたら、ちょっと残念かも。→ http://t.co/fsZWF6F
19:04 10年後に残っているのは何なのかな?Windows? Mac? それとも iPhone? どれも忘れられているんだろうな。
19:08 ソフトウェアっていうのは消してしまえるんだよねえ。物理的な実体をともなったサーバ設備を削除するのは簡単なことじゃないけど、仮想サーバなら管理者パスワードを知っていればそれができる。コワいわ。→ http://t.co/MxeL7D9
19:15 世界の仮想化(ソフトウェアへの移行)が進んだ状態では、パスワードによる直接的な権限認証方式は旧式に過ぎるのだろう。個人の認証ならパスワード(本人だけが知っている)でも良いとして、権限の付与や移譲はそれとは別の方式を採用すべきってことか。やはり確実なのは物理的な鍵か(・ω・)？

Lion アップデート (10.7 → 10.7.1)

2011-08-20T12:32:00.000+09:00

Lion (client) 10.7.1 update
iMac (Mid 2010)

Snow Leopard アップデート (10.6.6 → 10.6.7)

twitter より (2011-08-10)

2011-08-11T13:49:00.001+09:00

09:58 すごいなあ。一度つぶれかけてたことが嘘のようだわ。 → アップル、時価総額で米国一に　エクソンモービル抜く ( http://t.co/gL38GTQ )
10:03 とはいえ、盛者必衰は世のならい。やがては凋落していくんだろう。ただ、iPhone も Mac も今更他の機器に乗り換えたくない。あと 5 年くらいはがんばってほしいかな。きっとその頃にはまるっきり違うモノが出ている。

twitter より (2011-07-29)

2011-07-30T11:44:00.001+09:00

14:06 やっとわかった。なんで「システム環境設定」から消しちゃったんだろうな。 → Lionで操作スペースにソフトを割りあてる方法 ( http://t.co/S3rMPH8 )

twitter より (2011-07-26)

2011-07-27T06:16:00.001+09:00

12:23 GAE だと Go でも Web アプリが作れるのか。→ http://t.co/IsyVK4H

twitter より (2011-07-21)

2011-07-22T11:54:00.001+09:00

01:43 とりあえず imac を Lion に上書きアップデートしてみる。ただいまダウンロード中...
02:10 Lion へのアップデート完了(iMac)。AppStore でポチってから Lion で起動するまで 30 分かからなかった。
05:51 Lion になって、Safari の「進む」「戻る」ボタンの色が薄くなった気がする。
06:11 Lion のサーバ版は ¥4,300.- App Store のトップには並んでいないけど、検索すれば見つかる。
09:39 Air もそのうち終わるかも。プログラミングしないならキーボードつきの iPad とあまり変わらんものね。 → アップル、ホワイト「MacBook」をひっそりと提供終了 ( http://t.co/REGofZo )

twitter より (2011-06-09)

2011-06-10T12:22:00.001+09:00

12:38 なんだ！今日(2011-06-09)の Google のロゴは音が鳴るぞ。ギターになっていて、マウスで弦をはじくと音が鳴る。

twitter より (2011-06-08)

2011-06-09T06:23:00.001+09:00

16:43 先日(6/6)の WWDC keynote がポッドキャストで配信されていた。いま、見終わったところ。Lion の紹介がある一方で、iOS 5 と言い、iCloud と言い、総じて「脱PC」をメッセージとして強く感じた。
16:48 Lion で興味を引かれたのは Autosave と Versions。明示的な「セーブ」操作をなくすのは「ユーザビリティ」上の大きな挑戦だと思うが、版管理(Versions)と組み合わせることでその飛躍を解消している。ただしユーザが受け入れるかどうかは未知数だけど。
16:51 Versions はデモを見る限りでは、アプリごとの Time Machine だ。アプリ側が意識することなく(つまり、そのためのコードを追加することなく)、このサービスを使えるのか、さらに旧版を保持するためのストレージがどこなのか、などはデモからはわからなかった。
16:55 Lion についてもう 1 点、特筆すべきは、Mac App Store のみで提供されるってことだろう。4GB 程度で HD の映画 1 本と同じぐらいとのこと。$29.99 で 7 月に発売。あと 1 ヶ月か 1.5 ヶ月ぐらいか。
16:57 iOS 5 の目玉は PC Free だろう。購入して Setup するときに iTunes につなぐ必要がなく、Software update もl OTA でできるようになる。iCloud とあわせれば Mac (あるいは PC) はもういらない、と。
16:59 まあ、Mac (や PC) が不要と言うよりは、Mac (や PC) が iPhone や iPad と同等になった、と見るべきか。もう、付属品(アクセサリー)じゃないのだ、と。
17:01 iCloud は Mobile Me の拡大後継サービス。対応アプリが増えて、無料になる。Mobile Me はどうなるんだ、と思っていたら、すでに移行(とサービス終了)の案内が出ていた。 → http://t.co/wPm76Tm
17:05 Apple に(安定した)クラウドサービスなんて提供できるのか、と思っていたら keynote の終わりで、新しいデータセンター作ったぞ、と自慢していたので何とかなるのかも。まあ、サービス開始当初は混乱するかもしれないけどな。
17:09 今回の keynote は全体的に地味な印象を受けた。これはハードウェアの発表がなかったからだと思う。次の iPhone はいつなんだろう。待ってるんだよ。今更、白モデルを買う気になれないんだから。

twitter より (2011-06-04)

2011-06-05T06:24:00.001+09:00

08:22 今さらなんだけど、Google Chrome のアイコンを見ていて、Google のロゴに使われている色が四色だと気付いた。一方、Google は6文字なので、青と赤が2度使われている。なんで四色なんだろう？

twitter より (2011-05-30)

2011-05-31T06:25:00.001+09:00

09:38 昔の知り合いと(すごく)久し振りに話すと、自分が歳をとったなあ、と実感する。

twitter より (2011-05-16)

2011-05-17T12:07:00.001+09:00

02:55 近いうちに「解析概論」などが iPad で読めるようになるのか。 → http://t.co/UnnLnvn

twitter より (2011-05-15)

2011-05-16T21:13:00.001+09:00

10:07 iOS デバイスたちのアップデート、いちいち Mac につないでやるのがメンドウ。セルフアップデート可能になって欲しいわ。

twitter より (2011-04-27)

2011-04-28T06:16:00.001+09:00

18:47 ER15 が届いた。これがファイナルだとのこと。長く続いたもんだ。14 か 13 あたりから見返さないとストーリーが思い出せないわ。

twitter より (2011-03-31)

2011-04-01T06:22:00.001+09:00

10:14 xcode もついに有料化か。なんでこんなことするのかねえ。

Snow Leopard アップデート (10.6.6 → 10.6.7)

2011-03-31T15:27:00.002+09:00

少し遅くなったが、うちの Mac たちの Mac OS X (Snow Leopard) をアップデートした。前回(→ 10.6.6)から約 2.5 ヶ月。

iMac & MacBook

Snow Leopard (client) 10.6.7 update
iMac (Mid 2010)

サイズは 313.2MB。10.6.6 の2倍以上で、10.6.5 のときの半分。
MacBook (Early 2008)

iMac と同じ 313.2MB。

About パネルは以下のようになった。

Snow Leopard (client) 10.6.7 About dialog
iMac (Mid 2010)

MacBook (Early 2008)

Mac mini Server

Snow Leopard Server 10.6.7 update
Mac mini Server (Late 2009)

サーバ版は 381.8MB。クライアントよりも少し大きめ。しばらくアップデートをさぼっていたので、OS 以外にもいろいろと並んでいる。Xcode アップデートがここに並ぶのは珍しい(ひょっとしたら、初めて見たかも)。

以下は、Mac mini Server の About パネル。

Snow Leopard Server 10.6.7 About dialog
Mac mini Server (Late 2009)

カーネルバージョン

ついでにカーネルバージョンも記録しておく。

[mini] mnbiwa% uname -a                                                   [~]
Darwin xanadu.private 10.7.0 Darwin Kernel Version 10.7.0: \
Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386

[imac] mnbi% uname -a                                                     [~]
Darwin avalon.private 10.7.0 Darwin Kernel Version 10.7.0: \
Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386

twitter より (2011-01-20)

2011-01-21T17:08:00.002+09:00

18:44 プログラム(コード)よりも、コンテンツを売り物にする傾向は加速するばかりだ。ふと思ったんだけど、自分の撮った写真で時計アプリを作れたらウレシイのかね？ウレシイのならそういうサービスが出てきてもおかしくないな。→ http://t.co/YEpyJWK
19:00 2月末か。日本でも同時期だとしても時期的にビミョーだな。→ http://t.co/AKtZ6Rv

数学で犯罪を解決する ([著]キース・デブリン, ゲーリー・ローデン, [版]ダイヤモンド社)

2011-01-20T20:32:00.002+09:00

数学なしには暮らせない

「数学なんて、日常生活で何の役に立つんだよ」と問われれば、「われわれは数学なしには暮らせない。知らないだけで、いつだって数学を使っているんだ」とチャーリーなら答えるだろう。チャーリーとは海外ドラマ「ナンバーズ」の主人公で、数学の天才。彼は著名な応用数学者にして、FBI の犯罪捜査に関するアドバイザーだ。

なんだ、フィクションの話か、と思われるかもしれない。もちろんドラマ自体はフィクションだが、登場する数学(のかけら)はフィクションではないし、実際に犯罪捜査に応用されている事実もあるようだ。

キース・デブリンによる「数学で犯罪を解決する」は、「ナンバーズ」で使われている数学を説明したものだ。これを読めば「ナンバーズ」自体はフィクションであっても、数学が犯罪捜査に役立つ(役立っている)ことがわかる。

数学は魔術？

ドラマの中で FBI の捜査官たちが求めるのは、数学を適用することで得られた分析の結果だ。犯人が誰なのか、どこに潜んでいるのか、どこを通って逃げようとするのか。つまりは、犯人を捕えるための決め手となる情報だ。それがどうやって導かれたものかは気にしない。劇中の捜査官たちは数学者(チャーリー)の説明を聞いて「魔術(ブードゥー)だ」とつぶやく。

シーズン 2 のあるエピソードでは、FBI が霊能力者を協力者として使う様子が描かれる。チャーリーはそれに強く反発するが、(チャーリーの兄をふくめた)捜査官たちにとっては数学者も霊能力者も同じに見えているのだ。どちらも彼らには理解できない仕組みで隠された情報を暴く。

充分に発達した科学技術は魔術と見分けがつかない、と言ったのはクラーク(→「クラークの三法則」)だが、数学はその最たるものかもしれない。

数学とはパターンを見つける方法

なぜ、数学を用いることで人の行動(犯罪者の逃走経路とか潜伏場所とか)を予測したり、言い当てることができるのだろう？

「画像エンハンス」(Chapter 5) のように犯罪捜査(と裁判)の直接的な証拠となる応用例もあるが、「ナンバーズ」で用いられる数学の多くは人の行動を分析し予測するものだ。典型的なのはドラマの第1話の連続殺人犯の活動拠点(自宅と勤務先)の場所を絞り込む手法だろう(Chapter 1)。

このエピソードでは、スプリンクラーから飛び出す水滴が落ちた場所からスプリンクラーの位置をつきとめる、という例え話で説明されている。同様に、複数の犯行現場から犯人の活動拠点をつきとめられる、というのがチャーリーの主張だ。物理法則だけにしたがう水滴と、自らの意思を持つ人の行動を同列に扱うことができるのはなぜだろう？

その根拠となるのは人の行動には(たとえ本人がランダムに見せかけようとしたとしても)パターンが現れる、というものだ。加えて、人は「ランダム＝バラバラ」という偏見を持っている。犯行を重ねれば重ねるほどその場所は拠点の中心として同心円状に散らばっていく(実際の地理では地形や建物の状況、交通事情もあり円にはならない)。

完全にランダムなデータからはどんなパターンも読み取ることはできない。けれど、人の行動は(そこに意思がからむ以上)完全なランダムにはなりえない。そこには必ずパターンが生まれる。そして数学はパターンを見つけることに長けた人々が築き上げてきた体系だ。パターンを見つけ、記述するための道具がそこにはある。

数学を知らなくても暮らせる

たしかにチャーリーの言うように、現代の生活では様々な面で数学が使われている。けれど、その恩恵を享受するだけなら数学を知る必要はない。インターネットで買い物をするのに暗号の仕組みを知る必要はない。微分方程式が解けなくたってクルマの運転に支障はない。これは数学に限らず、人類がこれまで蓄積してきたあらゆる知識体系について言えることだ。iPhone のアプリを使うのにプログラミングの技術が必要ないのも同じ理屈だ。

もちろん、日常の生活の中でもパターンは生まれる。自分と自分の周囲のできごとを分析することでパターンを見つけ、将来に起きることを予測できるはずだ。しかし、そうする人は少ない。というか、そんな人はほとんどいないだろう。なぜなら、コストに見合わないから。データを収集し、分析し、パターンを見つけ、将来を予測する。どのステップにもコストがかかる。個人の生活では、そのコストに見合うだけの予測が必要になる場面はほとんどない。

(チャーリーのような)数学の天才は別として、「数学が役に立つ」ではなくて「(自分で)数学を知っていることが役に立つ」場面というのは、日々の暮らしの中では見つけられないだろう。数学はオモシロイんだけどな。

参考文献

数学で犯罪を解決する

キース・デブリン, ゲーリー・ローデン
ダイヤモンド社 ( 2008-04-11 )
ISBN: 9784478004203

物読みファイル (別館)で詳細を見る

「ナンバーズ」は DVD で観ることもできる。以下は「数学で犯罪を解決する」に数学的あらすじが解説されているシーズン 3 までのもの。シーズンを重ねるごとに数学風味が薄れてくるように思う。ま、それは仕方ないことか。

ナンバーズ天才数学者の事件ファイルシーズン1

ロブ・モロー, デビッド・クラムホルツ, ジャド・ハーシュ, アリミ・バラード, サブリナ・ロイド / パラマウントホームエンタテインメントジャパン ( 2009-06-12 )

物読みファイル (別館)で詳細を見る

ナンバーズ天才数学者の事件ファイルシーズン2 コンプリートDVD-BOX

ロブ・モロー, デビッド・クラムホルツ, ジャド・ハーシュ, アリミ・バラード, サブリナ・ロイド / パラマウントホームエンタテインメントジャパン ( 2009-08-07 )

物読みファイル (別館)で詳細を見る

ナンバーズ天才数学者の事件ファイルシーズン3 コンプリートDVD-BOX Part 1

ロブ・モロー, デビッド・クラムホルツ, ジャド・ハーシュ, アリミ・バラード, ナビ・ラワット / パラマウントホームエンタテインメントジャパン ( 2010-06-11 )

物読みファイル (別館)で詳細を見る

ナンバーズ天才数学者の事件ファイルシーズン3 コンプリートDVD-BOX Part 2

ロブ・モロー, デビッド・クラムホルツ, ジャド・ハーシュ, アリミ・バラード, ナビ・ラワット / パラマウントホームエンタテインメントジャパン ( 2010-07-09 )

物読みファイル (別館)で詳細を見る

オフライン機能の実現 #6 (MacBloggerGlass)

2011-01-17T21:27:00.002+09:00

GData API 経由で取得したフィードデータをローカルに保存できるようになり、すっかりオフライン機能が完成したと思い込んでいたが(→「FeedManager が完成 - オフライン機能の実現 #5」)、実はまだ未完成だった。というのも、フィードを保存するだけでは、テキスト以外のリソースは保存されないからだ。フィードには記事のテキストしかふくまれていないから、たとえばスクリーンショット画像を表示するにはやはりネットにアクセスしなければならない。

このブログで使っているテキスト以外のリソースは主に画像とスクリプトだ。画像はスクリーンショット等で使っているし、スクリプトは Gist でコードを貼り付けるのに使っている。

さて、この問題、どう解決したものだろう？

解決の方針

まず必要になるのは、リソース(画像等)をローカルストーレジの所定の場所に保存する仕組みだ。所定の場所はフィードと同様 ~/Library/BloggerGlass/<account>/<Blog ID> とする。ここにリソースのタイプごとにディレクトリを作って保存する。画像なら images、スクリプトなら scripts となる。このとき、ファイル名はリソースの URL から生成したハッシュ値を用いる。

次に必要になるのは、フィードのテキストから対象となるリソースの URL を抜き出す仕組み。さらには、その URL をローカルなファイルへのものに置き換える仕組みも必要だ。これは、すでに内部リンクの置き換えの実現で似たような処理を作り込んでいる。ここにはいくつか工夫の余地がありそうだが、動かすだけなら素直な(ただし愚直な)方法で実現できる。

Snow Leopard アップデート (10.6.5 → 10.6.6)

2011-01-16T19:56:00.003+09:00

Mac 用の App Store のスタートにあわせて、Mac OS X (Snow Leopard) のアップデートがリリースされた。10.6.5 から約 2 ヶ月と短い間隔のアップデートだが、これは App Store 対応のアップデートだから(だと思う)。

iMac & MacBook

iMac と MacBook (クライアント版)の場合。

Snow Leopard (client) 10.6.6 update
iMac (Mid 2010)

サイズは 114.8 MB。10.6.5 のときの 680 MB とくらべるとかなり小さめのアップデートだ。
MacBook (Early 2008)

MacBook 用のサイズも iMac と同じ 114.8 MB だった。

About パネルは以下のようになった。

Snow Leopard (client) 10.6.6 About dialog
iMac (Mid 2010)

MacBook (Early 2008)

Mac mini Server

サーバ版の場合。

Snow Leopard Server 10.6.6 update
Mac mini Server (Late 2009)

Server も client と同じサイズだ。

以下は、Mac mini Server の About パネル。

Snow Leopard Server 10.6.6 About dialog
Mac mini Server (Late 2009)

カーネルバージョン

例によって、カーネルバージョンも記録しておく。これまで同様(→「Snow Leopard アップデート (10.6.4 → 10.6.5)」参照)、サーバとクライアントで同一になっている。

[mini] mnbi% uname -a
Darwin mini.private 10.6.0 Darwin Kernel Version 10.6.0: \
Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386

[imac] mnbi% uname -a
Darwin imac.private 10.6.0 Darwin Kernel Version 10.6.0: \
Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386

最終定理 ([著]アーサー・C・クラーク, フレデリック・ポール, [版]早川書房)

2011-01-15T14:21:00.003+09:00

言わずと知れたクラーク最後の長編。タイトルの最終定理とはフェルマーの最終定理のこと。数百年にわたり数学者を悩ました問題の 1 つで、1995 年にワイルズによって解決されたあれだ。数学者でなくとも数学好きなら中学や高校のときに一度は目にしたことのある定理だろう。

2 つの物語

これは 2 つの物語が(ほぼ)並列に語られる作品だ。1 つは主人公となるスリランカの数学者の半生を描くもの。もう 1 つは銀河間スケールで活動する知性体による人類粛清の物語。

主人公のランジットは数学を志す学生だったが、ひょんなことから海賊の一員と間違われ投獄、拷問の憂き目に会い、友人の尽力で解放され、最終定理の「簡潔な」証明を発見したことで著名な数学者となり、美人と結婚し、娘と息子に恵まれ、幸せに暮らす。

一方、いくつもの銀河に君臨するグランド・ギャラクティクスは、核をもてあそび始めた地球人類を有害な存在とみなし、従属する種属にその粛清を命じる。が、土壇場で気を変え、人類は滅亡を免れる。

2 つの物語は終盤でランジットの娘を接点として絡み合う。この点を除いて、2 つの物語は独立していると言って良い。ランジットはグランド・ギャラクティクスの決定に対して何ら特別な影響を及ぼさないし、グランド・ギャラクティクスとその従属種属は取りたてて(最終定理をふくむ)数学に興味を示しはしない。

絡むようで絡まない 2 つの物語。それがこの作品の特徴だ。

SF らしさ

SF として見るなら、本作はこれまで SF が生み出してきた楽天的なアイデアの数々を盛り込んだ作品になっている。世界政府しかり、宇宙エレベータしかり。さまざまな銀河種族に君臨するオーバーロード(超知性)も、今では懐しく感じる。これらを題材としたクラークの他の作品を思い出すのも楽しい。

また、あわや人類滅亡かという瀬戸際まで行くものの、最後は大団円で終わるところも、読後感すっきりの古き良き SF を思い出させる。

クラークと言うよりはポールの作品

全体の語り口を通して感じられるのは、フレデリック・ポールの作風。ことに異星人の描写ではそれが顕著だ。どちらかと言うと淡々と事実を叙述するクラークのそれとは異なり、描き方に起伏が感じられる。読んでいて「ゲートウェイ」のことを思い出した。とくに終盤で主人公(をふくむ人類)がマシンの中(のシミュレートされた環境)で生き続けるという辺りではその思いを強くした。

解説によれば、本作は、クラークが基本的なアイデアと原稿の一部をポールにわたし、ポールがそれをもとに書き上げ、クラークがチェックをして完成したとのこと。ポール風味になっていて当然か。

かといって、クラークらしさが感じられないかと言うとそうではない。とくに主人公が退屈な大学の授業の中で天文学の講義に魅せられる様子や、スカイフック(宇宙エレベータ)が登場する辺りは、クラークの SF 作品に多く見られる(というよりクラーク自身の)「宇宙への憧れ」がストレートに表われている。

不満は……

唯一の不満点はタイトルになっている「最終定理」が、物語の展開上、ほとんど意味のないこと。暴虐な異星人を撃退するために使われることもなければ、異質な知性とのコミュニケーションに必要なわけでもない。ただ、その証明が主人公のキャリアの転回点になったというだけの扱い。看板に偽りありだ。

ストーリー上、主人公が数学者である必然性はまったくないし、フェルマーの最終定理を持ち出す必要も感じられない。タイトルからイーガンの「ディアスポラ」ようなものを期待していると裏切られることになる。

この点に目をつむれば、読んでいて楽しく、読み終わって爽快な良作 SF だ。

参考文献

宇宙旅行はエレベーターで

ブラッドリー C エドワーズ, フィリップレーガン
武田ランダムハウスジャパン ( 2008-04-23 )
ISBN: 9784270003350

物読みファイル (別館)で詳細を見る

本作中で「スカイフック」として登場する宇宙エレベータについて知りたいならこの本を読むと良い。

楽園の泉 (ハヤカワ文庫SF)

アーサー・C. クラーク
早川書房 ( 2006-01 )
ISBN: 9784150115463

物読みファイル (別館)で詳細を見る

宇宙エレベータを描いた SF ならこれ。シェフィールドの「星ぼしに架ける橋」(ハヤカワ文庫 SF)も有名だけど、こちらは現在では入手困難。

ディアスポラ (ハヤカワ文庫 SF) / 山岸真

グレッグ・イーガン
早川書房 ( 2005-09-22 )
ISBN: 9784150115319

物読みファイル (別館)で詳細を見る

こちらは数学が物語に織り込まれた作品。

ZSH のパス設定

2010-12-28T19:06:00.002+09:00

以前、MacBook と Mac mini Server の間で git clone しようとして失敗したことがあった(→「MacBook にも Git を (あるいはリモートリポジトリの準備)」)。原因は、リモート側のシェルの PATH 設定だった。git でリモートリポジトリから SSH 経由で clone しようとする場合、リモート側で(SSH 経由で) git コマンドが実行される。リモート側のシェルのパスに git コマンドをふくむディレクトリが入っていなければ、git コマンドが見つからずエラーになる。

シェルは起動時に設定ファイルを読み込む(実行する)ことで実行環境を整える。このとき、たいていのシェルでは実行モードによって読み込む設定ファイルが変わる。実行モードというのはログインシェル、対話シェル、そしてスクリプト実行用シェルの 3 つのことで、git clone で起動されるシェルはスクリプト実行用シェルになる。このため、たとえ ssh コマンドでリモートログインした状態で対話的に git コマンドを使えたとしても、git clone しようとすると (git コマンドが見つからず)エラーになることがある。

今日も、MacBook と iMac の間で git clone しようとして同じエラーが出て失敗した。以前解決したはずの問題にまた遭遇したことになる。というのも、あれからしばらくしてシェルを zsh に変えたからだ(→「twitter より (2010-08-03)」)。最初の設定のときに、ssh コマンドでリモートログインしてローカルなシェルの場合と同様に使えることを確認して安心していた。今日まで git clone のようなリモートのコマンドを直接実行することはなかったから、この問題に気付かなかった。

では、zsh を使う場合リモート(のスクリプト実行用)のシェルが参照するパスを設定するにはどうすれば良いのか？より具体的に言えば、git のリモートリポジトリを置いたコンピュータのシェルが zsh のとき、git clone 等が失敗しないようにするにはどうすれば良いのか？

答えは ~/.zshenv

結論を先に書くと、スクリプト用シェルのために PATH を設定するには ~/.zshenv に書けば良い。書式は通常のシェルスクリプトと同じ。つまり、git clone が失敗する問題を解決するためには、リモート側(clone されるリポジトリがある方)に ~/.zshenv を作り、以下のように PATH の設定をしてやれば良い(git コマンドを MacPorts でインストールしている場合)。

export PATH=/opt/local/bin:/opt/local/sbin:$PATH

これまで、zsh のためのパスは ~/.zshrc で設定してきた。この方法どこが悪かったのだろう？

それは実行モードごとの設定ファイルの読み込みが以下のようになっているからだ(→「【コラム】漢のzsh (1) 最強のシェル、それは「zsh」 | マイコミジャーナル」参照)。一言で言えば、~/.zshrc はスクリプト実行用シェルのときは読み込まれない。

zsh の設定ファイル読み込み順序
実行モード	読み込み順
ログインシェル	~/.zshenv ~/.zprofile ~/.zshrc ~/.zlogin
対話シェル	~/.zshenv ~/.zshrc
スクリプト用シェル	~/.zshevn

これを見れば、スクリプト用シェルが参照する PATH は ~/.zshenv で設定しなければならないことがわかる。

~/.zshenv を読むより前に起きていること

さて、これで MacBook と iMac の間で git clone に失敗する問題は解決できたが、ついでに zsh における PATH の設定について調べてみた。

zsh の man ページによれば、シェルが起動時に最初に読み込むのは /etc/zshenv だとのこと。その後、上述の表のような順序で設定を読み込む。では、/etc/zshenv はどうなっているのか？

Mac OS X 10.6.5 の /etc/zshenv の内容を以下に示す。

# system-wide environment settings for zsh(1)
if [ -x /usr/libexec/path_helper ]; then
 eval `/usr/libexec/path_helper -s`
fi

ここに書いてあるのは /usr/libexec/path_helper があれば、それを実行しろというもの(バッククォート記法なので、正確には path_helper の実行結果をスクリプトとして実行しろ、となる)。

この path_helper というコマンドは PATH を設定するためのシェルスクリプトを生成するためのもので -s オプションで B-shell 用のスクリプトが作られる。man ページには直接実行するものじゃないゾ、と書いてあるが、そこをあえて実行してみた結果を以下に示す。実行の前に PATH と MANPATH の設定を消しているのは、このコマンドが現在の設定に追加するようになっているから。空にしておくことで、zsh が /etc/zshenv でこのコマンドを実行したときの結果がわかる。

[imac] mnbi% PATH=''
[imac] mnbi% MANPATH=''
[imac] mnbi% /usr/libexec/path_helper -s
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin"; export PATH;
MANPATH="/usr/share/man:/usr/local/share/man:/usr/X11/share/man"; export MANPATH;

では、path_helper は PATH (と MANPATH) に入れるべきディレクトリをどうやって知るのだろう？ man ページによれば、それは /etc/paths と /etc/manpaths だとのこと。そして、ここに書かれたものに、さらに /etc/paths.d と /etc/manpaths.d に置かれたファイルの内容を付け加えて、PATH と MANPATH とする。

以下に、Mac OS X 10.6.5 の /etc/paths の内容を示す。

/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin

同じく、Mac OS X 10.6.5 では /etc/paths.d には X11 というファイルがあり、その内容は以下のようになっている。

/usr/X11/bin

以上のことから、~/.zshenv を使ってユーザごとにパスを設定する以外にも、追加したいパスを書いたファイルを /etc/paths.d に置けば、システム全体で(正確には zsh を使っているすべてのユーザで)同様の効果が得られることがわかる。

NSTableView でソートしたとき、選択された要素をモデル配列から正しく取り出す方法

2010-12-27T19:43:00.002+09:00

NSTableView では、見出し行をクリックするとカラムの内容によって行をソートすることができる。ところが、これはモデル(となっている NSMutableArray)をソートしているわけではないから、ソートしたビュー上の並び順とモデル内の要素の並び順は一致していない。

たとえば、もともと「りんご」「みかん」「ぶどう」の順にモデル配列の中に収められているとして、これをビュー上でソートして「ぶどう」「みかん」「りんご」の順に表示されているとする。ここでビュー上で「りんご」を選択すると、そのインデックスは(0 から数えるので) 2 となる。このインデックスを使い、モデル配列から objectAtIndex: で要素を取り出せば、それは「りんご」ではなく「ぶどう」になってしまう。

つまり、ビューでソートした状態でビュー上の選択(のインデックス)に合わせてモデルの要素を取り出すと、ビューの選択とは異なる要素を取り出してしまうことになるのだ。

MacBloggerGlass の場合で言うと、記事の一覧をタイトルまたは日付けでソートした状態で一覧から記事の選択を行うと、表示される記事の内容がずれてしまう。

こうしたビューとモデルにおける要素の並び順の不一致を避けるには、両者を結びつけている NSArrayController を使えば良い。

具体的には、NSArrayController から selectedObjects で要素オブジェクト(の配列)を取り出せば、ビューでソートしているかどうかに関係なく、適切なオブジェクト(つまりビュー上の選択と同じオブジェクト)が取り出せる。

MacBloggerGlass の場合、以下のようなコードを使う(AppController.m より抜粋)。

    Entry *entry = [[feedController selectedObjects] objectAtIndex:0];

feedController が記事一覧(と記事内容)用のモデル配列のための NSArrayController だ。AppController の IBOutlet として確保し、Interface Builder で NSArrayController のインスタンスと結びつけている。記事一覧では複数選択を許していないから、selectedObjects の返す配列の最初の要素を取り出している。

ちなみに、この NSArrayController を使う解決方法はググって見つけた(→Cocoaの日々: NSArrayController を使った NSTableView で選択行の情報を取得する)

NStableView と NSArrayController の関係

では、なぜ NSArrayController からは、ソートの状態に関係なく、適切なモデルオブジェクトを取り出すことができるのだろうか？

オブジェクトの配列をモデルとして、その内容を NSTableView に表示させる場合(配列の要素になっているオブジェクトのプロパティを表のカラムに表示させる、という意味)、Cocoa Bindings では両者を NSArrayController で結びつける。

これは詳細に言えば、NSTableColumn の値として、NSArrayController の arrangedObjects が返す配列の要素のプロパティを結びつける、ということだ。初期状態では、arrangedObjects はモデルの配列の並び順そのままの配列を返す。だから、モデル配列の順序がそのままビューの表示順序になる。一方、NSTableView の見出し行でソートしたときは、NSArrayController の arrangedObjects が返す配列の並び順が変わる。その結果、ビューの表示順序が変わる。

実はビュー(NSTableView)の行がソートされるのはむしろ結果で、実際にはコントローラ(NSArrayController)が返す要素の順序がソートされていたのだ。これは、NSArrayController がソートされた状態のモデル配列を保持している、と言っても良い。だから、ビュー上でソートされた状態のインデックスを使っても、適切なオブジェクトを取り出すことができるのだ。

では、なぜ NSArrayController の arrangedObjects の並び順が変わるのか？それは、NSTableView の見出し行がクリックされたときに NSArrayController に対して setSortDescriptors が呼ばれ、NSSortDescriptor がセットされることによる。これはソートの方法を指示するオブジェクトで、NSArrayController は arrangedObjects を作り出す際に参照するものだ。初期状態ではこれがセットされていないため(ソートされず)、arrangedObjects はモデルの要素順と同じ順序の配列になっている。

見出しをクリックしてからの一連の動きを時系列で並べると以下のようになる。

NSTableView の見出しがクリックされる。
NSTableView が NSArrayController に対して、NSSortDescriptor をセットする。
NSTableView (実際には NSTableColumn) が NSArrayController に対して arrangedObjects を要求する(メソッドを呼び出す)。
NSArrayController は先にセットされた NSSortDescriptor にしたがってソートした配列を返す。

まとめると、ソートはビューで起きているのではなく、コントローラの内部で起きている、ということになる。だから、コントローラはソートされた状態のインデックスから適切なオブジェクトを取り出すことができる、と。

iOS アプリではどうする？

Cocoa Bindings が使えない iOS アプリでは NSArrayController に相当する部分を自前で用意しなければならないはず。なんだか面倒なことになりそうな予感がする。ソートしなければ(できないようにすれば)良いんだけど。そもそも、iOS のアプリで表をソートするアプリって見かけないような……。

進捗状況を表示する (MacBloggerGlass)

2010-12-25T09:30:00.000+09:00

フィードをネットから取得する際には、ブログの記事数にもよるが、やはり多少の時間(数秒)がかかる。その間、ユーザにフィードバックがないのはユーザ体験上の問題だ。GAE 版ではブラウザが矢印を回したり、アドレスバーを塗り潰したりして「ネットにアクセスしてますよ」と主張してくれるが、Cocoa 版ではこれも自前でどうにかしなければならない。

フィードバックの方法

今回は、進捗状況をフィードバックする仕組みとしては、最も手軽な部類の「ステータスメッセージの表示」を作り込むことにした。

メッセージを表示する場所は、Safari などでもお馴染のアプリウィンドウの最下部。ここにテキスト 1 行分の領域を空け、ラベル (NSTextField) を配置する。あとは、アプリコントローラで進捗に合わせてメッセージを setStringValue: してやれば良い。

問題は進捗状況をどうやって知るのか。実際のフィードの取得は GData ライブラリの中でアプリの実行ループとは並列に実行されている。スレッドなのか、あるいは他の仕組みなのかまではまだ調べていないが、便宜上、別タスクと呼んでおく。このフィード取得用の別タスクが、アプリに対してコールバックを呼ぶなどして途中の状況を知らせてくれれば簡単なのだが、そういう仕組みは GData ライブラリには用意されていない。データをアップロードする場合には、そういうものがあるが、取得(ダウンロード)時にはないようだ。

しばらく悩んだ後、何も難しく考えることはないと気付いた。フィードの取得が完了したことは GData ライブラリからのコールバックでわかる。ならば、取得を開始するときにタイマで定期的に進捗していることを知らせるメッセージを表示させ、完了したらそれを止めれば良い。「ネットにアクセスしているよ」を知らせるだけなら、これで十分だ。

タイマを使った遅延実行

NSObject には、指定した時間間隔の後、オブジェクトに対してメッセージを送る(つまり、そのオブジェクトでメソッドを実行する)仕組みが存在する。それが以下のメソッドだ。

- (void)performSelector:(SEL)aSelector
             withObject:(id)anArgument
             afterDelay:(NSTimeInterval)delay;

delay には遅延させる時間を秒単位で指定するが、NSTimeInterval は実は double 型なので 1.0 や 10.0 のように実数(というか浮動小数)で指定する。

他にもときどき見かけるけど、基本型を typedef しただけの型っていうのは何か落ち着かない。クラスにしてファクトリなりイニシャライザを用意して欲しいよ。即値をどう指定したものか迷うから。NSTimeInterval ならファクトリに intervalWithSeconds:(NSUInteger)sec とかがあれば迷わずにすむ。書くのは少しメンドウだけど。

遅延実行を使った進捗メッセージの表示

フィードの取得開始時にメッセージとして「Loading.」を表示
一定時間後にメッセージを更新するようにタイマをセット
メッセージの更新では、「.」を追加したメッセージを表示するとともに、再び一定時間が経過したらメッセージの更新するようにタイマをセット
取得が完了したら、メッセージの更新を停止した上で、「(Complete)」を追加したメッセージを表示
ある程度時間が経過したら、メッセージを消す。

つまり、最初に「Loading.」と表示され、その後時間の経過とともに「Loading...」と「.」が増えて行き、完了した時点で「Loading........(Complete)」と表示される、というものだ。

フィードの取得開始と完了を通知する

あと少し問題が残っている。それはフィードの取得開始をどうやってアプリコントローラ(AppController)に伝えるか、というもの。

実際にネットからフィードを取得するかどうかは、FeedManager だけが知っている(→「FeedManager が完成」)。アプリコントローラから「このフィードをよこせ」と言われたとき、すでにメモリ中に FeedBlogPost クラスのインスタンスがあればそれを返すし、インスタンスがないときにもすぐにはネットから取得せず、まずはローカルのストレージ中で保存されたフィードを探す。そこにもないとなって、ようやくネットから取得することになる。この動きは FeedManager 中にカプセル化されていて、アプリコントローラからは見えない。

FeedManager をアプリコントローラに依存するようにはしたくなかったので、通知(NSNotification)を使って、取得の開始と完了を知らせることにした(→「設定変更を通知する」)。

FeedManager の実装部で開始を通知する部分のコードがこれだ。

- (void)fetchPostsForReceiver:(id)feedReceiver
                         blog:(EntryBlog *)blog
                      account:(NSString *)account
                     password:(NSString *)password {
    [...snip...]
    // send notification
    NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
    NSDictionary *userInfo = [NSDictionary dictionaryWithObject:blog
                                                         forKey:@"fetchingBlog"];
    [nc postNotificationName:BGKeyPostsLoadStartNotification
                      object:self userInfo:userInfo];
    [...snip...]
}

同様に完了を通知するコードは以下になる。

- (void)postsTicket:(GDataServiceTicket *)ticket
   finishedWithFeed:(GDataFeedBlogPost *)gfeed
              error:(NSError *)error {
    [...snip...]
    // send notification
    NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
    [nc postNotificationName:BGKeyPostsLoadCompleteNotification object:self];
}

実装: 進捗メッセージの表示

実際に進捗メッセージを表示するアプリコンントローラの実装を以下に示す(AppController.m より抜粋)。

- (void)awakeFromNib {
    NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
    [nc addObserver:self selector:@selector(handleBlogIDChange:)
               name:BGKeyBlogIDChangeNotification object:nil];

    [nc addObserver:self selector:@selector(handleFeedLoadStart:)
               name:BGKeyPostsLoadStartNotification object:nil];
    [nc addObserver:self selector:@selector(handleFeedLoadComplete:)
               name:BGKeyPostsLoadCompleteNotification object:nil];

    [statusMessage setStringValue:@""];
    [...snip...]
}

- (void)handleFeedLoadStart:(NSNotification *)note {
    EntryBlog *blog = [[note userInfo] objectForKey:@"fetchingBlog"];
    [self startIndicatorWithMessage:[NSString
                                     stringWithFormat:@"%@: Loading.",
                                     blog.title]];
}

- (void)handleFeedLoadComplete:(NSNotification *)note {
    [NSObject cancelPreviousPerformRequestsWithTarget:self
                                             selector:@selector(handleUpdateIndicator:)
                                               object:nil];
    NSString *message =
    [NSString stringWithFormat:@"%@(Complete)", [statusMessage stringValue]];
    [statusMessage setStringValue:message];

    [self performSelector:@selector(handleClearIndicator:)
               withObject:nil afterDelay:BGIndicatorClearInterval];
}

- (void)startIndicatorWithMessage:(NSString *)message {
    [NSObject cancelPreviousPerformRequestsWithTarget:self
                                             selector:@selector(handleClearIndicator:)
                                               object:nil];
    
    [statusMessage setStringValue:message];
    [self performSelector:@selector(handleUpdateIndicator:)
               withObject:nil afterDelay:BGIndicatorUpdateInterval];
}

- (void)handleUpdateIndicator:(id)object {
    NSString *message = [NSString stringWithFormat:@"%@.",
                                  [statusMessage stringValue]];
    [statusMessage setStringValue:message];

    [self performSelector:@selector(handleUpdateIndicator:)
               withObject:nil afterDelay:BGIndicatorUpdateInterval];
}

- (void)handleClearIndicator:(id)object {
    [statusMessage setStringValue:@""];
}

取得開始の通知を受ける handleFeedLoadStart: で startIndicatorWithMessage: の遅延実行をセットする。startIndicatorWithMessage では開始メッセージを表示した後、handleUpdateIndicator: の遅延実行をセットする。handleUpdateIndicator: ではメッセージを更新(「.」を追加)した後、handleUpdateIndicator: (つまり自分自身)の遅延実行をセットする。こうして handleUpdateIndicator: の実行が繰り返され、取得完了通知を受けた handleFeedLoadComplete: でキャンセルされるまで続く。また、handleFeedLoadComplete: では、完了メッセージを表示した後、進捗メッセージを消去するための遅延実行をセットしている。これにより、いつまでも完了メッセージがステータス行に残ることを防いでいる。

まとめ

メンドウだと言ってしまえばその通りなんだけど、GUI っていうのはそういうものだ。それに利用している仕組みも難しいものではないし。

一方で、テキストメッセージを表示するというフィードバックは、GUI アプリのユーザ体験としてはほめられたものじゃない。グルグル回ったり、塗り潰されたりする方が見やすいし、わかりやすい。フィードバックを表示するための裏の仕掛けには、今回のように通知と遅延実行を使えば良いが、何を表示するかには工夫の余地がある。

Cocoa Touch 版(つまり iPhone アプリ)では、この方式は使えない。グラフィカルな仕掛けが必要だ。グルグル回るやつとか。

参考文献

詳解 Objective-C 2.0 改訂版

荻原剛志
ソフトバンククリエイティブ ( 2010-12-17 )
ISBN: 9784797361780

物読みファイル (別館)で詳細を見る

タイマを使ったメソッドの実行については「15-01 アプリケーションと実行ループ」に記述がある。とくに今回用いた遅延実行については p.351 の「メッセージの遅延実行」を参考にした。

PasswordManager の導入 - 非公開ブログの記事を取得する (MacBloggerGlass)

2010-12-24T23:53:00.002+09:00

今日の作業は「いくつか気になっている細部のつめ」の一つ。非公開ブログの記事を取得できるようにすること。GAE 版では Google サービスに対する認証処理をサボったため公開ブログだけしか扱えなかった。しかし、Cocoa 版ではブログの一覧を取得するために認証付きのアクセスを利用している。記事の取得でも同様にすれば良いだけのこと。

GData ライブラリを使った記事の取得を実行している部分は、FeedManager (の一部のメソッド)に局所化されている。そこだけを変更すればできると考えた。が、この目論見は甘かった。必要な情報を伝播させるため、あちこちに手を入れる必要があった。結局、大小さまざまの変更をほぼ全体に施すことになってしまったのだ。以下で説明する PasswordManager もその一つ。

これまではアカウント(Google アカウント)のパスワードは PreferenceController だけで保管、利用してきた。取得にパスワードが必要な情報(ブログ一覧)を使うのがここだけだったから。一方、ブログ記事を取得するトリガーは AppController にある。非公開ブログの記事を取得するためには AppController から FeedManager にパスワードを知らせなければならない。

環境設定パネル(PreferenceController で制御している)で入力したパスワードを AppController でも利用できるようにするための仕組みが PasswordManger だ。パスワードの保管と読み出しを局所化することがその目的になる。インタフェース部を以下に示す。FeedManager 同様、これもシングルトンパターンを実装している(→「FeedManager の実装」)。メソッドの実装は、PreferenceController にあったキーチェーンを使った保存と読み出しをほぼそのまま流用している(「→キーチェーンサービスを使ってパスワードを保存する」)

@interface PasswordManager : NSObject {
    NSMutableDictionary *passwords;
}

+ (PasswordManager *)sharedManager;

- (NSString *)currentPassword:(NSString *)account;
- (void)updatePasswordForAccount:(NSString *)account
                        password:(NSString *)password;

@end

この他にも、GData API の認証付きサービスを利用するために必要な情報をFeedManager にわたすための仕掛けが必要になったり、と結構大掛かりな変更になった。FeedManager だけを 2、3 行変更するだけのつもりで始めた変更だっただけに、なおさら変更量が多く感じられたのかも。

ラベルによる記事の抽出 - ラベル検索の実装 #3 (MacBloggerGlass)

2010-12-23T23:37:00.003+09:00

前回(→「ドロワー (NSDrawer) の使い方」)に続いて、ラベルの付いた記事を抽出する仕組みを作り込む。

Feed にクエリを指定して Entry を絞り込む

GAE 版では、GData API への問い合わせにクエリーを指定することで、取得するフィードデータの段階で記事を絞り込んでいた。Cocoa 版ではフィードデータをローカルストレージに保存しているため、この方式は使えない。

記事の抽出は MVC のうち、M (モデル) でも C (コントローラ) でも可能だが、今回は M (モデル) で行うことにした。この場合、記事の抽出というよりも絞り込みと言うべきだろう。

具体的には、Feed クラスに対して絞り込みのための「何か」を付与することで、Feed のプロパティ entries (配列)に収められる要素(Entry のインスタンス)を制限する。Feed が抱える要素(Entry)をフィルタにかけるようなイメージだ。

Feed に付与する「何か」をクエリー(Query)と呼ぶ。その実体は、Entry クラスの述語メソッドと引数となるオブジェクトを組み合わせたものだ。Feed が抱える Entry のインスタンスそれぞれに対して、述語メソッドを(組み合わされた引数とともに)適用し、結果が真 (BOOL の YES) のものだけを残すわけだ。

今回は、ラベルによる絞り込みなので、Entry クラスには - (BOOL)hasLabel:(NSString *)label というメソッドを定義しておく。以下にその定義を示す。

- (BOOL)hasLabel:(NSString *)aLabel {
    NSString *label;
    for (label in self.labels) {
        if ([label isEqualToString:aLabel]) {
            return YES;
        }
    }
    return NO;
}

NSInvocation を使った Query の実現

Query の定義を以下に示す。これを見てわかるように、Query の実体は NSInvocation そのものだ。Entry のインスタンスに適用するために特殊化された NSInvocation と言っても良い。

NSInvocation は言わば、オブジェクトに対するメソッド呼び出し自体を独立したオブジェクトとして扱えるようにするためのものだ。そこには、メソッドの情報(セレクタとシグナチャ)、引数、ターゲットとなるオブジェクトが収められる。もともと、分散処理を実現するための仕組みの一つのようだが、今回のような目的にも利用できる。

単にラベル(文字列)による要素の絞り込みを実現するだけなら、NSInvocation のような仕組みは必要ない。ただラベル(の配列)を Feed クラスにわたすだけで良い。単純な方法をとらなかったのは、他の種類のクエリーもサポートするためだ。たとえば、投稿日時による絞り込み等。Entry で適切な述語を定義してやれば、そういった絞り込みも可能になる。

@interface Query : NSObject {
    NSInvocation *invocation;
}

+ (Query *)queryWithPredicate:(SEL)predicate argument:(id)object;
- (id)initWithInvocation:(NSInvocation *)anInvocation;

- (BOOL)applyTo:(Entry *)target;

@end

@implementation Query

+ (Query *)queryWithPredicate:(SEL)predicate argument:(id)object {
    NSMethodSignature *signature =
    [Entry instanceMethodSignatureForSelector:predicate];

    NSInvocation *anInvocation =
    [NSInvocation invocationWithMethodSignature:signature];
    [anInvocation setSelector:predicate];
    [anInvocation setArgument:&object atIndex:2];

    Query *query = [[Query alloc] initWithInvocation:anInvocation];
    return [query autorelease];
}

- (id)initWithInvocation:(NSInvocation *)anInvocation {
    [super init];
    invocation = [anInvocation retain];
    return self;
}

- (void)dealloc {
    [invocation release];
    [super dealloc];
}

- (BOOL)applyTo:(Entry *)target {
    [invocation invokeWithTarget:target];

    BOOL result;
    [invocation getReturnValue:&result];
    return result;
}
@end

コントローラ(AppController)では、ドロワー内のテーブルビューで選択が変わったときに、Feed に対して Query を付与している。ラベルが複数選択された場合は Query も複数付けられることになる。

- (void)tableViewSelectionDidChange:(NSNotification *)notification {
    id object = [notification object];
    if (object == postTable) {
        [...snip...]
    } else if (object == labelsTable) {
        NSIndexSet *indexes = [labelsTable selectedRowIndexes];
        NSArray *selectedLabels = [feed.labels objectsAtIndexes:indexes];
        NSString *label;
        NSMutableArray *queries =
        [NSMutableArray arrayWithCapacity:[indexes count]];
        for (label in selectedLabels) {
            Query *query =
            [Query queryWithPredicate:@selector(hasLabel:) argument:label];
            [queries addObject:query];
        }
        [feed setValue:queries forKey:@"queries"];
    }
}

Feed での絞り込みは entries プロパティに対するアクセサを上書きすることで実現している。これを見てわかるように、複数の Query が付けられた場合、AND 結合による絞り込みとなる。

- (NSArray *)entries {
    if ([queries count] == 0) return entries;
    NSMutableArray *filteredEntries = [NSMutableArray array];
    Entry *entry;
    Query *query;
    for (entry in entries) {
        BOOL result = YES;
        for (query in queries) {
            result = [query applyTo:entry];
            if (! result) break;
        }
        if (result) {
            [filteredEntries addObject:entry];
        }
    }
    return filteredEntries;
}

ちなみに今回は、この絞り込みは Feed クラスではなく、Feed から派生させた FilteredFeed クラスに実装している。そして記事フィードを表現する FeedBlogPost クラスをこの FilteredFeed クラスから派生するように変更した。というのも、ブログ一覧(のフィード)を表現する FeedBlog クラスには絞り込みは必要ない。絞り込みの実装がそちらに影響を及ぼすことのないようにしておきたかったのだ。

Cocoa 版 BloggerGlass の完成

ラベル検索が実現できたことで、Mac 用アプリとして作り始めたときの目標(→「欲しいのはオフライン機能」)を達成できた。

MacBloggerGlass プロトタイプ #0
ラベル検索

スクリーンショットだけではわかりにくいが、左のドロワーで選択したラベルの付いた記事だけが一覧に現れている。

これで Cocoa Touch 版、すなわち iOS デバイス向けのアプリとして作り直すための基礎ができた。Cocoa 版との大きな違いは、GUI の部品が異なること、Cocoa Bindings が使えないことなどだろうか。UI としては、Cocoa 版よりもむしろ iPhone 向けに最適化した GAE 版に近いものになるかもしれない。Cocoa Bindings を使わないとすると、コントローラの実装も変わる(コードが増える)はず。

一方で、モデルと言うべき GData オブジェクトのアダプタ(Entry と Feed)クラスおよび FeedManager はほぼそのまま流用できるだろう。

Cocoa Touch 版にとりかかるのは 2011 年になってからになるか。2010 年の残りはいくつか気になっている細部をつめる作業をしよう。

ドロワー (NSDrawer) の使い方 - ラベル検索の実装 #2 (MacBloggerGlass)

2010-12-22T23:54:00.005+09:00

ラベルの一覧を表示する UI として、ドロワーを使うことにした。ドロワーとは、アプリウィンドウの端に(大抵は左右のどちらか)付加的に表示できるウィンドウのことだ。通常のアプリウィンドウと同じく、様々なビューを置くことができる。

最近の Mac OS X 用アプリではあまり見かけなくなった(少々古臭い) UI だが、表示中はメインウィンドウにくっついており見失うこともないし、不要なときは隠しておけばメインウィンドウ上のレイアウトを圧迫することもない。

MacBloggerGlass のメインウィンドウは記事一覧表示とその内容表示で、すでに 2 分割(2 ペイン)しているが、ここにラベル一覧表示領域を追加するとさらに分割することになってしまう。その方が使いやすいならそうするが、まずは表示領域の分割ではなく、必要な時だけ領域を追加する方式で試してみることにした。

Interface Builder での操作

Cocoa アプリにドロワーを追加するには、ライブラリツールから Windows グループにある Windows and Drawer (右のスクリーンショットを参照)をドラッグしドキュメントウィンドウにドロップする。

ライブラリツール上は 1 つのオブジェクトのように置かれているが、ドキュメントウィンドウにドロップすると以下の 3 つのオブジェクトが現れる(下のスクリーンショット参照。)。

Window
Drawer Content View
Drawer

この 3 つのオブジェクトは、ドロップされた状態ですでに互いに関連づけられている。具体的には Drawer に備わったアウトレットのうち、parentWindow が Window に、contentView が Drawer Content View にそれぞれ結びつけられている。

大抵の場合、アプリウィンドウはプロジェクトを作ったときから (MainMenu.xib 内に) 存在しているため、上記の Window オブジェクトは不要だ。当然、削除することになるが、そのときは Drawer オブジェクトの parentWindow を適切に設定しなければならない。

Drawer オブジェクト(の parentWindow)にアプリのウィンドウを結びつけるには、Ctrl キーを押しながら Drawer オブジェクトからアプリウィンドウまでドラッグする。アプリウィンドウ上に接続するアウトレットの候補が現れるので、parentWindow を選ぶ。

この Interface Builder のドキュメントにも書いてある正式な手順(Ctrl + ドラッグ)は正直言ってわかりづらい。いつもどっちからドラッグするのかで迷ってしまう。それよりも、アウトレットを備えたオブジェクト上でポップアップメニューを出す方がずっとわかりやすい。マウスなら(特に設定を変えていない限り)右クリック、TrackPad なら 2 本の指でタップした状態でクリックでポップアップメニューが出てくる。メニューにあるアウトレットの右端の端子(○)を接続したいオブジェクトまでドラッグする。Ctrl キーを押す必要はない。

ドロワーの表示

ドロワーを表示するにはアプリコントローラからアウトレットを通して openOnEdge: メソッドを呼ぶ。このとき、親ウィンドウのどの端にドロワーを付けるかを引数として指定する。隠す際は close メソッドだ。

以下は、AppController.m からの抜粋だ。labelsDrawer は AppController クラスのアウトレットで、Interface Builder 上で Drawer オブジェクトに接続してある。

以下のコードでは、現在のドロワーの状態を取得し、それに応じて表示中なら close、非表示中なら openOnEdge: を呼んでいる。openOnEdge: にわたしている NSMinXEdge はウィンドウの左端を意味する定数だ。ドロワーを右端に表示したいなら NSMaxXEdge を指定する。

- (IBAction)toggleLabelsDrawer:(id)sender {
    NSDrawerState state = [labelsDrawer state];
    if (state == NSDrawerOpeningState || state == NSDrawerOpenState) {
        [labelsDrawer close];
        [showDrawerMenu setTitle:@"Show Labels"];
    } else {
        [labelsDrawer openOnEdge:NSMinXEdge];
        [showDrawerMenu setTitle:@"Hide Labels"];
    }
}

上記で、showDrawerMenu に対して setTitle: しているのは、ドロワーの状態によってドロワーを表示(または非表示)にするためのメニュー項目の文字列を変えるためだ。非表示状態では「Show Labels」に、表示中なら「Hide Labels」に置き換えている。showDrawerMenu も AppController のアウトレットで NSMenuItem * として宣言し、Interface Builder 上でメニュー項目と接続してある。

ラベル一覧の表示

前回(→「ラベル検索の実装 #1」)のラベル列挙と合わせると、ラベル一覧表示が可能になる。以下がそのスクリーンショットだ。

MacBloggerGlass プロトタイプ #0
ラベル一覧表示

ラベル一覧をドロワーとして実現した状態。一覧表示にふくまれているすべての記事に付いたラベルを集めてドロワー内のテーブルに表示している。

ラベル検索の実装 #1 (MacBloggerGlass)

2010-12-21T23:39:00.002+09:00

ラベル検索を実現するために必要な仕組みは以下の 2 つ。

ラベルの列挙
指定されたラベルの付いた記事の抽出

今回は、まず簡単な方、ラベルの列挙を実装してみる。

GDataCategory

GData ライブラリで Blogger の記事は GDataEntryBlogPost クラスが表現している。各記事に付けられたラベルはこのクラスの categories というプロパティに収められている(実際に categories が定義されているのは GDataEntryBlogPost の基底クラスである GDataEntryBase)。このプロパティは NSArray として取り出すことができ、その各要素は GDataCategory クラスのインスタンスになっている。

もともと、Blogger の記事データを表す Atom フィードでは、カテゴリは以下のような XML 要素として表現されている。この term 属性が Blogger の記事に付けたラベルになっている。

<category
    scheme="http://www.blogger.com/atom/ns#"
    term="1. Macをプログラムする">
</category>

GDataCategory クラスには上記の term 属性を参照するための term プロパティが定義されている。ややこしいことに label というプロパティも定義されているが、こちらは Blogger のラベルとは関係ない。

実装

Entry クラス

Entry クラスでは、内部に抱えた GDataEntryBlogPost の categories プロパティから各 GDataCategory のインスタンスの term プロパティを取り出し、NSArray の一時オブジェクトとして返すメソッド(プロパティへのアクセサ)を定義した。

- (NSArray *)labels {
    NSArray *categories = [gDataEntry categories];
    if (! categories) return nil;
    NSMutableArray *lbls = [NSMutableArray arrayWithCapacity:[categories count]];
    GDataCategory *category;
    for (category in categories) {
        [lbls addObject:[category term]];
    }
    return lbls;
}

Feed クラス

Feed クラスでは、初期化時に各 Entry からラベルを(上述の labels メソッドで)取り出し、NSMutableSet にまとめておき、labels プロパティとして保持するコードを追加した。

- (void)gatherLabels {
    labels = [[NSMutableSet alloc] init];
    Entry *entry;
    NSString *label;
    for (entry in entries) {
        for (label in entry.labels) {
            [labels addObject:label];
        }
    }
}

配列ではなく集合を使ったのは、集合は addObject 時に要素の重複を排除してくれるから。

FeedManager クラス

また、内部に抱えた Feed インスタンスの labels プロパティをそのまま返す、同名のプロパティを FeedManager クラスにも用意することにした。アプリコントローラからは FeedManager 経由でアクセスすることにしたいから。

次は？

ラベルの「見せ方」を考えているところだが、まずは単純にドロワー(NSDrawer)に NSTableView でラベルを列挙する方式にするつもり。

ドロワーは最近ではあまり見かけなくなったけど、標準で用意されている部品だし、使わないときは隠しておけるし。

FeedManager が完成 - オフライン機能の実現 #5 (MacBloggerGlass)

Xcode プロジェクトを git で管理する

2010-12-20T22:28:00.003+09:00

MacBloggerGlass のプロジェクトの git 管理を開始することにした。Xcode はツール自身が生成するファイルがいろいろあって、何を git 管理に任せれば良いのかが難しい。ツールのことを知るためには自分で試行錯誤を繰り返すのが一番だが、ここは素直に先人の知恵に頼ることにした。

Xcode-Git-User-Script

今回利用したのは、github に登録されている Xcode-Git-User-Script というプロジェクトのスクリプトだ。この先、何度も繰り返すことになることだから、ツールの機能として取り込む方が良いと判断した。

このプロジェクトが提供するスプリプトは Xcode のスクリプトメニュー(「ウィンドウ」メニューと「ヘルプ」メニューの間にあるスクロールっぽいアイコン)にユーザスクリプトとして追加するもので、メニューから実行することで Xcode のプロジェクトに対して .gitignore と .gitattributes を追加してくれる。

ユーザスクリプトとして追加

まず、github の Xcode-Git-User-Script プロジェクトを開き、pasteMe_into_xcode_script_menu というファイルの内容を全選択しコピーしておく。その後の手順は以下のとおり。

Xcode のスクリプトメニュー(スクロールっぽいアイコン)から「ユーザスクリプトを編集…」を実行する。
「ユーザスクリプトを編集」ダイアログが現れるので、左下にある「＋」ボタンを押す。
(「＋」ボタンを押すことで現れる)追加メニューの中から「新規シェルスクリプト」を選択する。
右側のペインにスクリプトをペーストする。
必要なら左側のリスト項目から追加したスクリプトの名前を変更しておく(ダブルクリックで編集状態になる)。

右のスクリーンショットは「Create .gitignore」という名前で追加したところ。

スクリプトを実行してみる

スクリプトメニューから追加したスクリプトの名前を選ぶ。するとフォルダを選択するダイアログが出てくる。.gitignore を追加したいプロジェクトのフォルダを選べば良い。README にも書かれているが、このダイアログで「保存」ボタンを押すと、右のスクリーンショットにあるような警告パネルが現れる。気にせず「"."を使用」を押せば良い。

また、このスクリプトでは .gitignore に加えて、.gitattributes というファイルも追加するため、スクリプトの実行中にフォルダを選ぶダイアログが 2 回現れる。当然、警告パネルも 2 回現れることになる。

あとは、対象のプロジェクトのフォルダ(ディレクトリ)で git init すればリポジトリのセットアップが完了だ。

Xcode の次のバージョンに期待

Xcode の次のバージョンでは git のサポートも入るらしい。そうなれば .gitignore のことなんかもツール自身が面倒を見てくれるはず。ま、いつ出てくるのかはわからないけど。β版を試す勇気はないしな。

「詳解 Objective-C 2.0」の改訂版が出た

2010-12-19T22:47:00.000+09:00

詳解 Objective-C 2.0 改訂版

荻原剛志
ソフトバンククリエイティブ ( 2010-12-17 )
ISBN: 9784797361780

物読みファイル (別館)で詳細を見る

荻原(2.0)本の改訂版が出た。「はじめに」に書かれている主な更新点は以下の 5 つ。

ブロックオブジェクトの章を新設 (→ CHAPTER 14)
並列処理に関する記述を一新 (→ CHAPTER 19)
iOS に関する記述を充実 (→ 07-03 等)
Core Foundation の概要を追加 (→ APPENDIX B)
NSURL に関する記述を充実 (→ 08-07)

大きな変化は Snow Leopard で導入されたブロックオブジェクトと GCD に関する解説が追加されたことだろう。これら新しい並列処理機能に興味があるかどうかが、旧版を持っているプログラマが新版を買うかどうかの目安になるか。

今後の参照のため、目次を引き写しておく。章立てレベルで目に付く旧版との差異は「CHAPTER 14 ブロックオブジェクト」が追加されたことと、旧版での「CHAPTER 18 スレッド」と「CHAPTER 19 分散オブジェクトが新版では「CHAPTER 19 並列プログラミング」に統合されたこと、そして「APPENDIX B CoreFoundation フレームワークの概要」が追加されたこと。

CHAPTER 01 オブジェクトに基づくソフトウェアの作成
CHAPTER 02 Objective-C のプログラム
CHAPTER 03 継承とクラス
CHAPTER 04 オブジェクトの型と動的結合
CHAPTER 05 リファレンスカウンタを用いたメモリ管理方式
CHAPTER 06 ガーベジコレクション
CHAPTER 07 NSObjectクラスとランタイムシステム
CHAPTER 08 Foundation フレームワークの重要なクラス
CHAPTER 09 カテゴリ
CHAPTER 10 抽象クラスとクラスクラスタ
CHAPTER 11 プロトコル
CHAPTER 12 宣言プロパティとアクセサ
CHAPTER 13 オブジェクトのコピーと保存
CHAPTER 14 ブロックオブジェクト
CHAPTER 15 メッセージ送信のパターン
CHAPTER 16 アプリケーションの構造
CHAPTER 17 例題: 簡易画像ビューア
CHAPTER 18 例外とエラー
CHAPTER 19 並列プログラミング
CHAPTER 20 キー値コーディング
APPENDIX A Foundationフレームワークの概要
APPENDIX B CoreFoundation フレームワークの概要
APPENDIX C コーディングの指針

ブロックオブジェクト

新設された「CHAPTER 14 ブロックオブジェクト」をざっと読んでみた。まずは章の冒頭部分から引用。

(「詳解 Objective-C 2.0 改訂版」p.322 より)
ブロックオブジェクト (block object) は、Mac OS X 10.6 (Snow Leopard) および iOS 4.0 で利用できるようになった機能で、Objective-C ではなく、C 言語の機能として実装されています。 [...snip...] 他のプログラミング言語ではクロージャ (closure) として知られている言語機能に相当します。

ブロックってクロージャだったのか。それは知らなかったよ。

(「詳解 Objective-C 2.0 改訂版」p.327 より)
どうやら、ブロックオブジェクトは、そのブロックリテラルが記述された位置での自動変数の値を保存しているようです。

なるほど、これなら確かにクロージャだ。これがなければただの関数ポインタになってしまうよな。

この章の前半は、ブロックオブジェクトの使い方と実現のための仕組みの簡単な紹介になっている。仕組みについては、ブロックオブジェクトがスタック上に確保されることの説明があるが、これはブロックを理解するめの基本と言えそうだ。「クロージャはオブジェクトの裏返し」と言われる意味が、この説明を読んで理解できた。

また、後半では、ブロックオブジェクト(という名のクロージャ)の Cocoa アプリでの使用例として、コレクションクラス(配列や辞書)に追加されたブロック対応のメソッドを使ったソートと検索の方法と、シート(パネルの一種でウィンドウにくっついているもの)のデリゲートの置き換えとして使う方法が紹介されている。前者は、ブロックを for (item in collection) の裏返しとして使う方法ってところか。ループの中に記述するコードをクロージャとしてコレクションクラスに適用するもの。

そう言えば、GData ライブラリの実装でも(利用可能なら)ブロックを使うようになっていたな。CHAPTER 19 の並列プログラミングとあわせてじっくり読んでみるか。

参考文献

詳解 Objective-C 2.0

荻原剛志
ソフトバンククリエイティブ ( 2008-05-28 )
ISBN: 9784797346800

物読みファイル (別館)で詳細を見る

こちらは旧版。これまでこのブログでは「荻原(2.0)本」として何度も参照してきた。旧版についても目次を写してある(→「荻原(2.0)本」)

twitter より (2010-12-18)

2010-12-19T07:34:00.002+09:00

15:57 iphone の ipod からairplay で apple tv に音を送るとまるで iphone がリモコンのよう。実際は本体なんだけどな。
16:07 apple tv って iphone (または ipod touch) の再生装置としても良いかも(・∀・)ｂ ipod のささるスピーカーでもいいけど、あれだと iphone 自体で離れた場所から操作できない。大抵リモコンがあるけど操作性はやはり iphone そのものが上。
16:10 ってか、アレだな。airplay 対応の再生装置が出てくればそれでも良いのか。
20:00 iOS/Mac 向けアプリ開発者で iPad を持っているなら、おすすめです。→ http://logrepo.blogspot.com/2010/12/ibook-apple.html (iBook で Apple 提供の開発者向けドキュメントが読める)

iBook で Apple 提供の開発者向けドキュメントが読める

2010-12-18T19:52:00.005+09:00

昨夜(2010-12-17)のこと、iPod touch で App Store を開くと iBook のアップデートが配布されていることに気付いた。他にもいろいろアップデートが出ていたのでまとめてアップデートした。で、ふと iBook を開き、さらに iBookStore を開いてみたところ、iOS 関連の開発者向けドキュメントが配信されていることに気付いた(右のスクリーンショットは iPad で iBookStore を開いたもの)。

そう、ようやく Apple がやってくれた。ずっと、これが欲しかった。もともと PDF 版が配布されているから iPad に取り込んで読むことはできたし、さらに iPad がネットにつながるなら Safari でウェブ版を開けば iPad に最適化された状態で読むこともできた(→「iPad で Apple 提供の開発者向けドキュメントを読む」)。実際、このウェブ版は、iPad というデバイスの特性とあいまって、「ADC のドキュメントを読むならコレだ！」と思わせるぐらい読みやすいものになっていた。iMac で Xcode を開いているときにも、そばに立てた iPad でガイド系の文書(のウェブ版)を開いて参照していた(Xcode のドキュメントブラウザは主にクラスリファレンスを参照するのに使っている)。

とはいえ、ウェブ版のドキュメント(というよりブラウザで長い文書を読むこと)には不満がある。スクロールして読む読書体験と、ページをめくって読む読書体験を比較すれば、後者の方が圧倒的に心地良い。画面上を文字が移動するのは「読む」ことを前提にした場合は気持の良いものじゃない(せめて、iPad 上の Safari に「Page Up」と「Page Down」があれば……)。もっとも、これはわたしがデジタル以前の世界で育った世代からかもしれない。情報の入れ物としての「本」というカタチに慣れてしまっていることがそう思わせるのだろう。

また、いくら Wi-Fi 接続だろうとネット上のリソースを開くのには「遅れ」が生じる。アドレスバーが水色で塗られていくのを眺めていても楽しくない。

だから、iPad で ADC ドキュメントを読むようになってからずっと思っていた。いや、むしろ願っていた。Apple が ebook として提供してくれるようになることを。

iPad で読んでみる

いくつかスクリーンショットを撮ったので貼ってみる。すべて、iPad のスクリーンショット機能(電源ボタン + ホームボタンの同時押し)で撮影したもの。ここに並ぶんでいるのはサムネイル。実際の見え方は画像をクリックして Picasa ウェブアルバムにアップしたものを見てほしい。

iPad の iBook で ADC ドキュメントを読む
iBook の本棚に並んだ iOS 開発者向けドキュメントたち

早速、ダウンロードしてみた。最上段の 5 つが iOS 開発者向けドキュメントだ。O'Reilly の ebook と比べると表紙が文字だけで少しさびしい。
iOS Application Programming Guide を開いてみた (#1)

文字はもちろん、写真もクッキリ。
iOS Application Programming Guide を開いてみた (#2)

図もはっきり見える。図中の文字も十分に判別できる。

もう、なんて言うかさ、iPad はこのために作られたんじゃないか、って思えるぐらい。Apple は開発者向けに ADC ドキュメントを(iOS 用のものだけじゃなく)丸ごと収録した iPad を販売するべきだよ。有料の Dev program (iOS 向けと Mac 向けのものがある)に参加している場合はちょっと安くしてさ。

iPod touch で読んでみる

画素数ではともかく、画面が小さいから iPad ほどの見やすさは得られないとわかっているけど、せっかくなので iPod touch でも試してみた。以下は iPod touch のスクリーンショット機能で撮ったもの。残念ながらスクショでは iPod touch の画面での見た目は再現できないから参考程度に見てほしい。

iPod touch の iBook で ADC ドキュメントを読む
iOS Application Programming Guide を開いてみた (#1)

スクショだとやけに文字が大きく見えるが、実機で見るとこれより小さいと読みづらくなるサイズ。ま、見えやすさには個人差が出ると思うが。
iOS Application Programming Guide を開いてみた (#2)

iPad のスクショと同じ図。実機で見ると、図中の文字の判別はかなり厳しい。
図だけを表示(横向き)

横向きで、図だけを表示させると少し大きくなる。ただ、やはり実機上では図中の文字は読みづらい。

iBook では図をダブルタップすると図だけを表示することができる。この状態ではピンチオープン、クローズによる拡大縮小も可能。iPod touch でも、ダブルタップからピンチオープンで拡大すれば図中の文字も読み取れる。

他のドキュメントも欲しい

iBook 向けに提供されているのはまだたった 5 つだけ。ADC にはそれこそ山ほどのドキュメントがある。iOS 向けだけじゃなくて、Mac 向けの方のものも iPad で読みたい。

Apple さん、どんどん配信してください。お願いします。

FeedManager が完成 - オフライン機能の実現 #5 (MacBloggerGlass)

2010-12-17T23:52:00.003+09:00

ようやく、FeedManager の実装とそれを使うコントローラ(AppController、PreferenceController)部分の修正が完了した。FeedManager は必要に応じてフィードを GData API を通じて入手し、ローカルに保存する。これで、取得ずみのフィードが存在すれば、ネットワークにアクセスすることなく記事を表示することができるようになった。つまりは、オフライン機能が実現できたことになる。

XML テキストの保存と復元

ファイルへの書き出し

最初は、XML テキストの保存に NSString の writeToFile 系のメソッドを使っていた。問題なくファイルに書き込めていたのだけれど、気になったのはファイルの許可情報。保存先が ~/Library の下だということもあり、所有者以外の読み取り許可を付けたくなかった。ところが、NSString の writeToFile だとファイル作成時に許可情報を指定することができない。デフォルトだと 0644 で作られてしまう(グループと全ユーザに対して読み取り許可が付いている)。

作った後に許可を変更することも考えたが、何かまずいことが起きてアプリがクラッシュした際に、許可を変更できないままのファイルが残る(という可能性がある)ことが気持ち悪い。結局、NSString から NSData に変換し、NSFileManager の createFileAtPath:contents:attributes: を使うことにした。該当する部分のコード(FeedManager のメソッド)を以下に示す。

- (void)writeFileAtPath:(NSString *)path contents:(NSString *)text {
    // always overwrites a existing file
    NSData *data = [text dataUsingEncoding:NSUTF8StringEncoding];
    if (! data) {
        NSLog(@"Some data might be lost in converting into the UTF-8 encoding.");
        return;
    }

    NSMutableDictionary *attrs = [NSMutableDictionary dictionary];
    [attrs setObject:[NSNumber numberWithInt:0600]
              forKey:NSFilePosixPermissions];

    BOOL result = [fileManager createFileAtPath:path contents:data attributes:attrs];
    if (! result) {
        NSLog(@"Fail to write a file: %@", path);
    }    
}

実はこの部分はちょっと気になっている。というのも、Feed オブジェクトから XML データをテキストとして抽出する際に、NSData から NSString に変換している。ファイルに書き出す際に、それを FeedManager で NSData に戻していることになる。どう考えてもムダだ。途中で NSString を利用しているわけでもないし。

気が向いたら修正しておこう。

XML テキストからの復元

ファイルから XML テキストを読み込み、Feed オブジェクトを復元しているコードを以下に示す。まずは、FeedManager のメソッドから。ここでは指定されたファイルの内容を NSString として取り出し、Feed クラスのファクトリーメソッドにわたしている。

- (Feed *)restoreFeedFromFile:(NSString *)path feedClass:(Class)classOfGData {
    Feed *feed;
    NSString *xmltext =
    [NSString stringWithContentsOfFile:path
                              encoding:NSUTF8StringEncoding
                                 error:NULL];
    feed = [Feed feedWithXMLText:xmltext feedClass:classOfGData];
    return feed;
}

次は、実際に Feed オブジェクトを生成している部分。こちらは Feed クラスのクラスメソッドだ。

+ (Feed *)feedWithXMLText:(NSString *)xmltext feedClass:(Class)classOfGData {
    NSXMLDocument *xmldocument =
    [[NSXMLDocument alloc] initWithXMLString:xmltext
                                     options:0
                                       error:NULL];
    GDataFeedBase *gfeed =
    [[classOfGData alloc] initWithXMLElement:[xmldocument rootElement]
                                      parent:nil];
    
    Feed *feed;
    if (classOfGData == [GDataFeedBlog class]) {
        feed = [[[FeedBlog alloc] initWithGDataFeed:gfeed] autorelease];
    } else if (classOfGData == [GDataFeedBlogPost class]) {
        feed = [[[FeedBlogPost alloc] initWithGDataFeed:gfeed] autorelease];
    } else {
        NSLog(@"Unexpected class was specified: %@", classOfGData);
        feed = nil;
    }

    [xmldocument release];
    [gfeed release];
    return feed;
}

ここで引っかかったのは、引数としてわたってきた NSString から NSXMLDocument を生成する部分。より正確には NSXMLDocument の initWithXMLString:options:error に対する第 2 引数 options の値だ。始めこれに NSXMLDocumentTidyXML という定数を指定していた。リファレンスによれば構造的に誤りをふくむ XML を正しい XML に修正する、と書いてあった。とくに XML の修正機能が必要だったわけではなく、ただなんとなく選んだだけだ。ところが、この指定で記事内容(HTML で書かれた部分)の pre 要素の改行がすべて取り除かれてしまった。

たしかにリファレンスには「pretty-print で付けられた余分の空白等を取り除く」と書かれていた。ここを見落としたのだ。

ともあれ、この値として 0 (余分な動作は何もしない) を指定して、期待した通りの結果を得ることができた。

Feed オブジェクトをキャッシュする

メモリ中に生成した Feed オブジェクトをキャッシュしておくための仕組みを FeedManager に組み込んだ。といっても、実体は NSMutableDictionary だ。

この仕組みは、ブログ一覧 (FeedBlog) の方はアカウントをキーとしてキャッシュし、ブログ記事 (FeedBlogPost) の方はアカウントと Blog ID をキーとしてキャッシュする。環境設定パネルでブログが切り替えられたとき(またはアカウントが変更されたとき)に、すでに生成ずみの Feed オブジェクトがあれば、ネットワークに取りに行くこともなく、さらにはディスクから読み直すこともせずに、メモリ中のオブジェクトを使うことができるようにするためのものだ。

以下にインタフェース部だけを示す。実装は、単なる NSMutableDictionary へのアクセスで、ほぼ自明だから。Blog ID とアカウントの 2 つをキーとして指定する方は、単に文字列として連結しているだけだ。

// FeedCache is made to encapsulate the implementation detail
// to manage cache for Feed instances.
@interface FeedCache : NSObject
{
    NSMutableDictionary *blogFeeds;
    NSMutableDictionary *postsFeeds;
}

// manage cache for Feed instances
- (Feed *)feedBlogForAccount:(NSString *)account;
- (void)setFeedBlog:(Feed *)feed account:(NSString *)account;

- (Feed *)feedBlogPostForBlogID:(NSString *)blogID account:(NSString *)account;
- (void)setFeedBlogPost:(Feed *)feed blogID:(NSString *)blogID account:(NSString *)account;

- (NSString *)keyForBlogID:(NSString *)blogID account:(NSString *)account;

@end

プロトタイプ #0 の完成まで、もう少し

始めに挙げた機能のうち、残るはラベルによる検索だけとなった(→「欲しいのはオフライン機能」参照)。

必要になる仕組みとしては、おおよそ「ラベルの列挙」と「指定されたラベルが付いた記事の抽出」の 2 つ。前者は記事を表現した Entry オブジェクト (実体は GDataEntryBlogPost) からラベルをかき集めれば良い。後者については、GAE 版では GData API にクエリーをかけたが、Mac 版ではフィードはすべてローカルに保存してある(メモリ中にオブジェクトとして、あるいはディスク中に XML テキストとして)から、GData API をたたく必要はない。GData ライブラリにメモリ中のオブジェクトに対してフィルタをかけられればそれを使うし、できないならその部分を自前で作り込むことになる。

実装よりも「見せ方」をどうするかが悩みどころ。プロトタイプなのだから、凝った UI を作るつもりはないのだけれど……。

参考文献

詳解 Objective-C 2.0

荻原剛志
ソフトバンククリエイティブ ( 2008-05-28 )
ISBN: 9784797346800

物読みファイル (別館)で詳細を見る

Objective-C逆引きハンドブック

林晃
シーアンドアール研究所 ( 2010-02-26 )
ISBN: 9784863540514

物読みファイル (別館)で詳細を見る

twitter より (2010-12-16)

2010-12-17T07:34:00.002+09:00

18:34 Safari の Command + Ctrl + D を知らなかったよ。単語をダブルクリックで選択状態にして、Command + Ctrl + D。単語のそばに小さい辞書ウィンドウが開く。ナニコレ、便利すぎる。→ http://bit.ly/ethdtl

クラスクラスタの導入 - オフライン機能の実現 #4 (MacBloggerGlass)

2010-12-16T23:47:00.003+09:00

FeedManager を実装していて、どうにも FeedBlog と FeedBlogPost の取り扱いがメンドウになってきたので、両者に共通の基底クラスを作ることにした。ついでに、これらをクラスクラスタとしてまとめることにした。

クラスクラスタとは

荻原(2.0)本から引用する。

(「詳解 Objective-C 2.0」p.245 より)
クラスクラスタ (class cluster) とは、同じインタフェースを持ち、同じ機能を提供する複数のクラスの集合体です。インタフェースを表す抽象クラスのみを公開し、これをそのクラスクラスタのパブリッククラス (public class) と呼びます。個々の具体的なクラスはパブリッククラスのインタフェースによって抽象化され、クラスタの内部に隠蔽されます。

Cocoa (Foundation フレームワーク)で提供されている具体的なクラスタには、NSString や NSArray などがある。

公式ドキュメントにも独立した項目として解説されているが(→「Cocoa Core Competencies: Class Cluster」等)、言語および実行環境として特別なサポートの仕組みが提供されているわけではない。設計上の慣習 (convention) と見るべき。デザインパターンよりはもっと広い概念だ。

ずい分、昔のことだけど、C++ で可変 (mutable) オブジェクトとして生成したものを、不変 (immutable) オブジェクトとして返すなんてコードを書いていた。あれもクラスクラスタの一種だと言える。

実例: Feed クラス

MacBloggerGlass のモデルクラスは、これまで FeedBlog と FeedBlogPost として作ってきた。前者は Google アカウントごとのブログの一覧を表し、GData ライブラリのクラス、GDataFeedBlog に対応する。後者は、ブログごとの記事のフィードを表現するもので、GData ライブラリでは GDataFeedBlogPost に対応する。FeedBlog は環境設定パネルでブログの一覧を表示するために使い、FeedBlogPost はメインウィンドウで記事の一覧とその内容表示に使っている。

GData ライブラリのフィードを表現するクラスたちには共通の基底クラス (GDataFeedBase) があり、ほとんどの機能はこのクラス(あるいはさらにその基底クラス)で定義されていて、GDataFeedBlog と GDataFeedBlogPost の違いはわずかなものだ。当然、そのラッパーと言うべき FeedBlog と FeedBlogPost にも大きな差はなかった。

以下に、Feed クラスタの公開クラス Feed のインタフェース部を示す。

@interface Feed : NSObject {
    NSMutableArray *entries;
    NSMutableDictionary *pairOfLinks;
    GDataFeedBase *gDataFeed;
}

@property (readwrite, retain) NSMutableArray *entries;
@property (readonly) NSMutableDictionary *pairOfLinks;

// class factories
+ (Feed *)feedWithGDataFeedBlog:(GDataFeedBlog *)gfeed;
+ (Feed *)feedWithGDataFeedBlogPost:(GDataFeedBlogPost *)gfeed;
+ (Feed *)feedWithXMLText:(NSString *)xmltext feedClass:(Class)classOfGData;

// initializer
- (id)initWithGDataFeed:(GDataFeedBase *)gfeed; // desiginated initializer

// element manipulation
// subclass must be override the following 2 methods.
+ (Class)classForEntries;
+ (Entry *)entryWithGDataEntry:(GDataEntryBase *)gentry;

// for KVC compliance (required)
- (void)insertObject:(Entry *)entry inEntriesAtIndex:(NSUInteger)index;
- (void)removeObjectFromEntriesAtIndex:(NSUInteger)index;
- (void)replaceObjectInEntriesAtIndex:(NSUInteger)index withObject:(Entry *)entry;
// for KVC compliance (optional)
- (int)countOfEntries;
- (Entry *)objectInEntriesAtIndex:(NSUInteger)index;

// utilities
- (NSString *)XMLText;
- (NSUInteger)findEntry:(NSString *)identifier;

// for subclasses
- (void)setGDataFeed:(GDataFeedBase *)gfeed;
@end

継承関係にあるクラス群をクラスクラスタとして機能させるには、状況に合わせて具体的な派生クラスを生成するためのファクトリーメソッドが必要になる。上記の例では 3 つのファクトリーメソッドを Feed クラスのクラスメソッドとして定義している。対応する GDataFeedBase オブジェクトを指定して生成するものが 2 つと、もう 1 つは XML テキスト(フィードの生データ)から生成するものだ。XML から GDataFeedBase オブジェクトを作り、それに対応する Feed クラスを生成することを想定している。このため、どの GDataFeedBase クラスを作るかを引数でわたすようになっている。

また、Feed クラスが要素として抱えるオブジェクトの方も同様の理由でクラスクラスタとしている(Entry)。ただ、こちらの方は Feed よりもさらに派生クラスの差異が目立たないため、ほとんど Entry 単独のクラスのようになってしまった。まあ、クラスクラスタ化してしまえば、後から派生クラスを基底クラスにまとめたとしても(あるいは派生クラスを増やしたとしても)、それを使う側のコードに影響はほとんどない。派生クラスが不要だと思えば、削除してしまえば良い。

実はこのコード、まだ実装が完了していないので、動くかどうかは未確認。正確には、Feed クラスタの実装は完了しているが、それを使う FeedManager の方がまだできていない。明日にはできると思うのだけど……。

参考文献

詳解 Objective-C 2.0

荻原剛志
ソフトバンククリエイティブ ( 2008-05-28 )
ISBN: 9784797346800

物読みファイル (別館)で詳細を見る

MediaMarker

クラスクラスタの説明は「CHAPTER 10 抽象クラスとクラスクラスタ」の「10-02 クラスクラスタ」にある。あと、(インスタンス)オブジェクトの所属するクラスを調べる方法については「07-01 NSObject クラス」に書かれている。

FeedManager の実装 - オフライン機能の実現 #3 (MacBloggerGlass)

2010-12-15T22:59:00.002+09:00

前回の記事で書いたように(→「オフライン機能の実現 #2」)、フィードデータの保存、読み込みは、FeedManager と呼ぶ管理用のクラスを作り、ネットワークからのデータの取得と合わせて、その詳細を隠すことに決めた。

今日は、その FeedManager を作っている。残念ながら FeedManager はまだ完成していない。今回は、この実装の過程で気付いた注意点を 2 点ほど書き留めておく。

シングルトン・パターン

FeedManager にはシングルトン・パターンを使う。Cocoa でシングルトン・パターンを使うには少し注意が必要だ。簡単に言うと、NSObject で定義ずみのいくつかのメソッドを上書きしなければならない。また、シングルトン・パターンには付きもののファクトリーメソッドの定義にも Cocoa 独特の「お作法」がある。詳しくは公式ドキュメントの Cocoa Fundamentals Guide: Cocoa Objects: Creating a Singleton Instance を参照のこと。

この「Creating a Singleton Instance」には、シングルトン・パターンを実装するための実例が載っていて、そのまま流用できる。以下が、FeedManager 用に書き直したもの。sharedManager の戻り値以外は、実例そのままになっている。

+ (FeedManager *)sharedManager {
    if (sharedFeedManager == nil) {
        sharedFeedManager = [[super allocWithZone:NULL] init];
    }
    return sharedFeedManager;
}

+ (id)allocWithZone:(NSZone *)zone {
    return [[self sharedManager] retain];
}

- (id)copyWithZone:(NSZone *)zone {
    return self;
}

- (id)retain {
    return self;
}

- (NSUInteger)retainCount {
    return NSUIntegerMax;
}

- (void)release {
    // do nothing
}

- (id)autorelease {
    return self;
}

コールバック方式への対応

GData ライブラリではフィードデータの取得は非同期に実行される。このため、アプリ(のコントローラ)は、コールバックのメソッドを呼び出してもらうことでその完了を知る。データ取得が非同期に実行されるということは、取得したデータからオブジェクトを生成して返す GetFeedBlog のような関数を定義できないことを意味する。

@implementation FeedManager
- (void)trigger {
    [...snip...]
    FeedBlog *feedBlog = GetFeedBlog(account, password);
    [...snip...]
}
@end

非同期方式の場合は、取得開始のトリガーとなるコードと、取得したデータを受け取るコードの間で、引数と戻り値を使った直接的な情報の交換(通信)ができない。これを解決するための方法は 2 つある。1 つは、トリガーと受け取りのコードを同一のオブジェクトのメソッドとして実装し、オブジェクトのインスタンス変数を介して情報のやり取りを行うもの。以下のような感じのコードになる。

@interface FeedManger : NSObject {
    FeedBlog *feedBlog;
}
@end

@implementation FeedManager
- (void)trigger {
    Service *service = [...snip...]
    [service fetch];
    [...snip...]
}

- (void)callback:(id)dataObject {
    feedBlog = [[FeedBlog alloc] initWithDataObject:dataObject];
}
@end

GData ライブラリの GDataServiceBase クラスでは、上記とは別の方法をサポートしている。それは、サービス(フィードデータの取得)がコールバックに対して送り返すデータの一部として、クライアント(サービスを利用するコード)がユーザデータとして任意のオブジェクトを添付する仕組みだ。具体的には GDataServiceBase のインスタンスメソッド setServiceUserData だ。

GDataServiceBase に setServiceUserData でわたされたオブジェクトは、その後の同サービスオブジェクトに対するフィード取得のリクエストを処理する中で、コールバックに引数としてわたすオブジェクト(GDataServiceTicket)に封入される。コールバックメソッドでは、GDataServiceTicket の userData として、トリガーコードが添付したオブジェクトを受け取ることができる。おおよそ、こういう感じ(↓)。

@implementation FeedManager
- (void)trigger {
    GDataServiceBase *service = [...snip...]
    id userData = /* an arbitrary object */;
    [service setServiceUserData:userData];
    [service fetchFeedWithURL:[...snip...]]n;
}

- (void)callback:(GDataServiceTicket *)ticket [...snip...]] {
    id userData = [ticket userData];
    [...snip...]
}

この userData として、フィードデータ(から生成したオブジェクト)を受け取るオブジェクト(レシーバー)を添付すれば、callback の中でレシーバーにフィードデータをわたすことができる(レシーバーのメソッド経由で)。

FeedManager ではフィードデータから生成されるオブジェクトを保持するインスタンス変数を別の目的(オブジェクトが生成ずみかどうかの判別)で使っているため、GDataServiceBase (のサブクラス)に userData を添付する方法を採用している。

オフライン機能の実現 #2 (MacBloggerGlass)

2010-12-14T23:05:00.002+09:00

GData オブジェクトの保存については実現の目処が立った(→「GData オブジェクトを保存する」)ので、今回はオフライン機能全般について検討してみた。

ユーザ体験

前にも書いたように、MacBloggerGlass はドキュメントアーキテクチャに基づいたアプリではない。言わば(Blogger で作ったブログ専用の)ブログブラウザだが、アプリの分類では特殊用途の RSS リーダだ。そして、ユーザ体験から言えば Mail.app と言ったところ(ただし閲覧専用)。

Mail.app (を始めとするメーラのほとんど)がそうであるように、このアプリの場合もユーザが明示的に保存を指示することはない。Mac (や PC) のアプリでは、こういうタイプは少数派だが、iOS アプリではむしろ主流となっている。データを保存し読み込むというよりは、(アプリの終了によって)中断した状態を復元する方式だ。

現状の UI は、Google アカウントを切り替えることを想定したものではないが(わたし自身、複数のアカウントは使っていないし)、オフライン機能のためのデータ保存はアカウントごとに行う。これは、アカウントを切り替えたとしてもデータを上書きしないことを意味する。この方式を取った場合、アカウントごとにデータを削除する手段も用意すべきだが、それは将来の検討課題としておく。

一方で、ブログを切り替える UI を持つのだから、データの保存をブログごとに独立して行うのは当然。ただし、こちらもデータの削除は将来の検討課題に。

データの保存はユーザに意識させないが、データの更新はユーザに明示的な指示を出してもらう。メニューの「Reload」をそれに使う。アプリの動きとしては、(User Defaults に保管されている)ブログ ID に対応するフィードデータが存在した場合、データの取得は行わなず、保存されたデータから GData オブジェクトを復元し、表示する。もちろん、データが保存されていないければ、特にユーザからの指示がなくとも取得する。

デザイン(設計)

保存先は ~/Library/BloggerGlass とする。この中にアカウント名でフォルダを作る。そこにさらに Blog ID でフォルダを作り、データファイルはこの Blog ID によるフォルダに置く。ファイル名は feedblogpost.xml とする。将来的にフィードデータを分割保存することがあるかもしれない。その場合は feedblogpost-20101214.xml のように日付をファイル名に取り込む。

また、アカウントごとのブログ一覧のフィードも、アカウント名のフォルダ直下に置く。ファイル名は feedblog.xml とする。

データファイルの形式は XML のテキスト。言わゆる human readable な形にしておく。

「ユーザ体験」のところで書いたように、ユーザに保存を指示させない方式だとすると、そのトリガーをどうするか？まずは、フィードの取得が完了し(GData オブジェクトが作られ)た直後に実行される、GData ライブラリのコールバックが良いだろう。ユーザへのレスポンスの速さが気になるなら別スレッドで非同期に保存すれば良い。ただ、今の段階では同期的に保存する方式で。

では読み込みのトリガーは？これはブログの切り替えになる。つまり、環境設定パネルでブログが切り替えられた通知のハンドラで行うことになる。今は、このタイミングでフィードをネットワーク経由で取得に行っている。保存が実現でき後は、ここでまず保存されたデータの有無を確認し、あればそれを読み込み、なければネットワークにアクセスする、となる。

データの保存、読み込みはアプリコントローラとは独立させる。FeedManager クラス(仮名)を作り、ローカルのデータとネットワーク経由の取得の違いを隠す。アプリコントローラは FeedManager にアカウント名と Blog ID をわたして、FeedBlogPost オブジェクトを受け取ることになる。

実装に関する考慮点

~/Library に保存用のフォルダを作る際には、パスを直接指定するのではなく(そもそもユーザ ID を知らずにユーザのホームディレクトリを直接指定できない)、Cocoa に用意された API 経由でライブラリ用フォルダを取得する。それが NSSearchPathForDirectoriesInDomains 関数だ。

NSSearchPathForDirectoriesInDomains 関数は 3 つの引数を取る。1 つ目がフォルダの種類、2 つ目がフォルダのドメイン(のマスク)、そして 3 つ目がチルダ(~)を展開するか否か。

ドメインマスクには NSUserDomainMask、NSLocalDomainMask、NSNetworkDomainMask、NSSystemDomainMask、NSAllDomainMask のうちから 1 つを指定する。今回の実装ではユーザのライブラリフォルダ(のパス)を知りたいのだから、NSUserDomainMask で良い。

戻り値は配列になる。ユーザドメイン(のマスク)を指定すれば要素は 1 つだけだ。

以下に簡単なサンプルプログラムを示す。

int main (int argc, const char *argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    
    NSArray *paths =
    NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,
                                        NSUserDomainMask,
                                        YES);
    
    NSString *path;
    for (path in paths) {
        NSLog(@"Path: %@", path);
    }
    
    [pool drain];
    return 0;
}

上記のプログラムの実行結果は以下の通り(コンソールへの出力)。

2010-12-14 22:35:48.525 ExpApp[11456:903] Path: /Users/mnbi/Library

GData オブジェクトを保存する - オフライン機能の実現 #1 (MacBloggerGlass)

2010-12-13T22:37:00.004+09:00

今回から、オフライン機能を実現するための作業を開始する。まずは、フィードから構築したオブジェクトの保存と復元について実験する。

GData オブジェクトの保存と復元

MacBloggerGlass では内部データとして GData ライブラリのオブジェクト(以下では GData オブジェクトと呼ぶ)をそのままの形で保持している。モデルオブジェクトで覆うことで、表示のために加工が必要なデータ(ID や日付け)はキャッシュしているものの、記事のタイトルや内容は GData オブジェクトのデータをそのまま使っている。このためオフライン機能を実現するためには、GData オブジェクトの保存と復元が必要だ。

GData オブジェクト自体には Cocoa アプリでそのまま保存、復元できるための仕組み(NSCoding プロトコルの実装)はないが、その代わりに NSXMLDocument として参照することができるように作られている。

NSXMLDocument は NSCoding プロトコルこそ実装していないものの、NSData 化するためのメソッドが用意されており、これを抱えるクラスで NSCoding を実装することは難しくない。

GData オブジェクト (GDataObject とその派生クラスたち)を NSData 化するための手順は以下のようになる:

GData オブジェクトから NSXMLDocument オブジェクトを取り出す。 (XMLDocument メソッド)
取り出した NSXMLDocument を NSData 化する。 (XMLData メソッド)

また、NSData から GData オブジェクトを復元する手順は以下の通り:

NSData から NSXMLDocument オブジェクトを作る。 (initWithData:options:error: メソッド)
NSXMLDocument からルート要素を取り出す。 (rootElement メソッド)
取り出したルート要素で GData オブジェクトを初期化する。 (initWithXMLElement:parent: メソッド)

実験的な実装

環境設定パネルのモデルとなっている FeedBlog は内部にブログ一覧のフィード(GDataFeedBlog)を抱えるオブジェクトで、初期化に GDataFeedBlog のオブジェクトを指定する。今回は、このクラスを使って GDataFeedBlog の保存と復元を作り込むことにする。

インタフェース部では NSCodig プロトコルを実装することを宣言する。

@interface FeedBlog : NSObject <NSCoding> {
    NSMutableArray *entries;
    GDataFeedBlog *gDataFeed;
}

実装部では、NSCoding プロトコルの 2 つのメソッドを実装する。

// for conformance to NSCoding protocol
- (id)initWithCoder:(NSCoder *)aDecoder {
    [super init];
    NSData *data = [aDecoder decodeDataObject];
    NSXMLDocument *xmldocument =
    [[NSXMLDocument alloc] initWithData:data
                                options:NSXMLDocumentTidyXML
                                  error:NULL];
    NSXMLElement *xmlroot = [xmldocument rootElement];
    GDataFeedBlog *aFeed =
    [[GDataFeedBlog alloc] initWithXMLElement:xmlroot parent:nil];
    return [self initWithGDataFeed:aFeed];
}

- (void)encodeWithCoder:(NSCoder *)aCoder {
    NSData *data = [[gDataFeed XMLDocument] XMLData];
    [aCoder encodeDataObject:data];
}

NSCoding プロトコルを実装したオブジェクトは、保存時に NSKeyedArchive を使って NSData 化する。逆に、NSData オブジェクトからの復元には NSKeyedUnarchive を使う。

以下は環境設定パネルのコントローラクラス(PreferenceController)の実装の一部で、FeedBlog を NSData 化したものを User Defaults に保存している。本来、ここに保存するようなデータではないが、とりあえずこれで FeedBlog の保存と復元を確認することができる。

    NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
    [...snip...]
    // feed data
    NSData *data = [NSKeyedArchiver archivedDataWithRootObject:self.feed];
    [defaults setObject:data forKey:BGKeyFeedBlogData];

復元時は User Defaults から NSData オブジェクトを取り出し、NSKeyedUnarchive にかけている。

    // load feed blog data
    NSData *data = [self getUserDefaults:BGKeyFeedBlogData];
    @try {
        self.feed = [NSKeyedUnarchiver unarchiveObjectWithData:data];        
    }
    @catch (NSException * e) {
        NSLog(@"Exception: %@", e);
        self.feed = [[[FeedBlog alloc] init] autorelease];
    }
    @finally {
    }

次の一手

保存と復元の仕組みはわかったので、次はアプリとして、どこに、どのような形式でデータを書き出すかを考えなくてはならない。

MacBloggerGlass は、Cocoa のドキュメントアーキテクチャを使ったアプリではない。フィードを XML として書き出すことを選んだとしても Finder からそれをダブルクリックしてアプリを開くというタイプのものではない。ユーザ体験から見たアプリのタイプとしては、Mail.app に近いものを想定している。~/Library の下にアプリ専用のフォルダを作って、そこにブログごとのフィードデータを置くというような方式になるか。

書き出しの形式に関しては、まずは XML (のテキスト)で良いだろう。パフォーマンス上の問題が出てこない限り、人が読める形にしておくとデバッグをふくめて、何かと便利だから。ただ、データをブログごとに分けるのは当然として、同じブログのすべての記事を 1 つにまとめるのか、それとも一定の数で分割するのかについては検討する必要がある。

参考文献

Cocoa Programming for Mac OS X

Aaron Pablo Hillegass
Addison-Wesley Professional ( 2008-05-15 )
ISBN: 9780321503619

物読みファイル (別館)で詳細を見る

MediaMarker

Chapter 10 Archiving では NSCoder を使ったオブジェクトの保存と復元のサンプルが載っている。

Objective-C逆引きハンドブック

林晃
シーアンドアール研究所 ( 2010-02-26 )
ISBN: 9784863540514

物読みファイル (別館)で詳細を見る

MediaMarker

CHAPTER 10 に XML の操作に関する項目が載っている。NSXMLDocument の NSData 化は 187、ルート要素の取り出しは 188。

キーチェーンサービスを使ってパスワードを保存する

2010-12-12T20:46:00.004+09:00

以前の記事で書いたように(→「設定の保存にまつわる問題」)、ユーザのパスワード、それもアプリとは異なる別のサービス用のアカウントのものを、アプリの設定(User Defaults)にそのまま保存するのは望ましくない。たとえ、アプリの設定(~/Library/Preferences に plist ファイルとして保存される)がバイナリ形式で、かつファイルモードが 0600 であったとしても。

パスワードを保存するなら、やはり「キーチェーン」を使うべきだ。

(「Keychain Services Programming Guide: Introduction」より)
Keychain Services provides secure storage of passwords, keys, certificates, and notes for one or more users. A user can unlock a keychain with a single password, and any Keychain Services–aware application can then use that keychain to store and retrieve passwords.

今回は、このキーチェーンサービスについて調べてみた。

アプリへの組み込み

アプリからキーチェーンサービスにアクセスするために必要な関数は以下の 2 つ。

SecKeychainAddGenericPassword (キーチェーンにパスワードを追加)
SecKeychainFindGenericPassword (キーチェーンからパスワードを取得)

これをアプリ内で使う場合の注意点は、(a) security/security.h を import すること、(b) Security.framework をリンクすること、の 2 点だ。(a) はソースに書くだけ。一方、(b) のためには Xcode のプロジェクトウィンドウで以下のような操作を行う。

「グループとファイル」の「Frameworks」グループ上でポップアップメニューを出し「追加」>「既存のフレームワーク...」を選ぶ。
現れたシートから Security.framework を選び「追加」ボタンを押す。

上記を実行すれば「Frameworks」グループ内に Security.framework が追加されるが、実際にはどこでポップアップメニューを開いても大差はない。それよりも重要なのは「ターゲット」のビルドフェーズ「バイナリをライブラリにリンク」に Security.framework が追加されていることだ。

サンプルアプリ

この 2 つの関数を使って、簡単なサンプルアプリを作ってみた。右のスクリーンショットがそのアプリウィンドウだ。Save Password でアカウントとパスワードを指定して「Save」ボタンを押すと、パスワードがキーチェーンに保存される。次に、Load Password でアカウントを入力し「Load」ボタンを押すと、下のパスワードフィールドに保存したパスワードが表示される。もちろん、アカウントが間違っていればパスワードの取得に失敗する。

デフォルトのキーチェーンがロックされていれば、保存時にロックを解除するかというダイアログが出てくるし、同様に取得時にはキーチェーンへのアクセスを許可するかというダイアログも出てくる。また、実際にパスワードが保存できていることは「キーチェーンアクセス.app」を起動すれば確認できる。

以下に、アプリのソースの一部(AppController.{h,m})を示す。

#import <Cocoa/Cocoa.h>


@interface AppController : NSObject {
    NSTextField *accountFieldForSave;
    NSTextField *passwordFieldForSave;
    NSTextField *accountFieldForLoad;
    NSTextField *passwordFieldForLoad;
}

@property (assign) IBOutlet NSTextField *accountFieldForSave;
@property (assign) IBOutlet NSTextField *passwordFieldForSave;
@property (assign) IBOutlet NSTextField *accountFieldForLoad;
@property (assign) IBOutlet NSTextField *passwordFieldForLoad;

- (IBAction)load:(id)sender;
- (IBAction)save:(id)sender;

@end

#import <Security/Security.h>
#import "AppController.h"

NSString * const KCTServiceName = @"KeyChainTest App";

@implementation AppController

@synthesize accountFieldForSave, passwordFieldForSave;
@synthesize accountFieldForLoad, passwordFieldForLoad;

- (IBAction)load:(id)sender {
    NSString *account = [accountFieldForLoad stringValue];

    const char *serviceName = [KCTServiceName UTF8String];
    const char *accountName = [account UTF8String];

    void *passwordData = nil;
    SecKeychainItemRef itemRef = nil;
    UInt32 passwordLength;
    
    OSStatus status;
    status = SecKeychainFindGenericPassword(NULL,
                                            strlen(serviceName),
                                            serviceName,
                                            strlen(accountName),
                                            accountName,
                                            &passwordLength,
                                            &passwordData,
                                            &itemRef);

    NSLog(@"Load password: status = %d", status);
    if (status == noErr) {
        NSString *password =
        [[NSString alloc] initWithBytes:passwordData
                                 length:passwordLength
                               encoding:NSUTF8StringEncoding];
        [passwordFieldForLoad setStringValue:password];

        status = SecKeychainItemFreeContent(NULL,
                                            passwordData);
        [password release];
    } else {
        [passwordFieldForLoad setStringValue:@""];
    }

}

- (IBAction)save:(id)sender {
    NSString *account = [accountFieldForSave stringValue];
    NSString *password = [passwordFieldForSave stringValue];
    // !!!:
    const char *serviceName = [KCTServiceName UTF8String];
    const char *accountName = [account UTF8String];
    const char *passwordData = [password UTF8String];
    OSStatus status;
    status = SecKeychainAddGenericPassword(NULL,
                                           strlen(serviceName),
                                           serviceName,
                                           strlen(accountName),
                                           accountName,
                                           strlen(passwordData),
                                           passwordData,
                                           NULL);
    NSLog(@"Save password: status = %d", status);
}

@end

Cocoa のオブジェクトにくるまれていないサービスのため、使うのが少し面倒(NSString を直接わたせなかったり)だが、実質的に 2 つの関数を呼び出すだけでパスワードのような機密性の高い情報を安全に保管できる。やってみると思ったよりも簡単だった。

実は、この 2 つの関数だけではパスワードを変更することができない(同じアカウントで Add を呼ぶとエラーになる)。実際のアプリ(MacBloggerGlass)に組み込むときは、もちろん変更もできるようにしなければならない。

Cocoa アプリに JavaScript のライブラリを組み込む - Xcode の使い方

2010-12-11T19:30:00.003+09:00

MacBloggerGlass に google-code-prettify を組み込んだ。今回はその手順を説明する。概略は次の通り。

JavaScript ライブラリをプロジェクトのリソースとして追加する。
JavaScript ファイルをコンパイル対象から外す。
アプリバンドルへのファイルコピーのためのビルドフェーズを追加する。

今回の手順は、ビルドにより作られるアプリバンドルを以下のような構造にするためのものだ。また、Xcode でプロジェクトウィンドウの「グループとファイル」で見たときにも lib/prettify という構造に見え、かつ Finder から見えるフォルダ構造(つまりファイルシステム上の構造)も同じになるようにしている。Xcode では、プロジェクトのグループ構造が実際のフォルダ構造と同じである必要はないし、アプリバンドルの構造と一致させる必要もない。しかし、同じにしておく方がわかりやすい。むしろ、異なる構造にしておくと間違いの元だろう。

MacBloggerGlass.app/
+-- Contents/
    +-- Info.plist
    +-- MacOS/
    |   +-- ...
    +-- PkgInfo
    +-- Resources/
        +-- English.lproj/
        |   +-- ...
        +-- template.html
        +-- default.css
        +-- lib/
            +-- prettify/
                +-- ...
                +-- prettify.js
                +-- prettify.css

ちなみに、以下が現在のプロトタイプ #0 のスクリーンショット。google-code-prettify を組み込んだことによりソースコードが色付けされていることがわかる。

MacBloggerGlass プロトタイプ #0
アプリウィンドウ

google-code-prettify を組み込んだ。

JavaScript ライブラリをプロジェクトのリソースとして追加する

google-code-prettify は以下のように ~/tmp の下の lib フォルダに置いてあるものとする。この lib 以下をプロジェクトに追加することになる。

~/tmp/lib/
+-- prettify/
    +-- ...
    +-- prettify.js
    +-- prettify.css

まず、プロジェクトウィンドウの「グループとファイル」から Resources を選択した状態で、メニューより「プロジェクト」>「プロジェクトに追加...」を実行する。ファイル選択シートが現れるので、上記の lib フォルダを選択し「追加」ボタンを押す。

ここで、さらにオプションを選択するシートが現れるが、そこでは右のスクリーンショットのように選ぶ。これにより、プロジェクトのフォルダ内に lib フォルダ、さらにその中に prettify フォルダが作られ、ライブラリのファイルがコピーされている。

また、同時に「グループとファイル」では Resource の中に lib グループ、その中に prettify グループが作られている(右のスクリーンショットを参照)。

JavaScript ファイルをコンパイル対象から外す

Xcode のデフォルトルールでは、JavaScript ファイルはコンパイルが必要な「ソースファイル」の一種に設定されている。このため、JavaScript ファイルをプロジェクトに追加すると、ビルドフェーズの「ソースをコンパイル」に追加されてしまう(右のスクリーンショット参照)。

このままでもビルド時に warning が出るだけで実害はないけれど、大量の黄色の三角を見るのは気に入らない。この warning を消すには「ソースをコンパイル」から JavaScript ファイルを削除すれば良い。具体的には「グループとファイル」から「ターゲット」>「(アプリ名).app」>「ソースをコンパイル」を開き(右のスクリーンショットの状態になる)、js ファイルをすべて選択して削除すれば良い。ここに並んでいるのはファイルへの参照だけなので、ここで削除してもプロジェクトに追加したファイル自体が(プロジェクトから)消えることはない。

もう一つ。google-code-prettify には prettify.css という CSS ファイルがふくまれている。Xcode のデフォルトルールでは CSS ファイルはコピーされるべきバンドルリソースになっており、ビルドフェーズの「バンドルリソースをコピー」に追加される。このままでは適切な場所((アプリ名).app/Contents/Resources/lib/prettify/)にコピーされないので、ここからは削除しておく。手順は js ファイルの場合と同様。

アプリバンドルへのファイルコピーのためのビルドフェーズを追加する

最後のステップは、ビルドによって作られるアプリバンドルに JavaScript ライブラリが構造を保ったままコピーされるようにすることだ。これには、ファイルコピーのためのビルドフェーズを新たに追加すれば良い。

具体的には、メニューから「プロジェクト」>「新規ビルドフェーズ」>「新規コピーファイル」を実行する。右のスクリーンショットのようなダイアログ(インスペクタのパネル)が現れるので、「デスティネーション」として「リソース」を選び(デフォルトでそうなっている)、「パス」に lib/prettify を入力する。これは、アプリバンドルのリソースフォルダ中に lib/prettify を作って対象ファイルをコピーする、というビルドフェーズを意味する。

後は、このビルドフェーズに Resouces/lib/prettify の下にあるファイルをすべて追加するだけ(選択してドラッグ&ドロップ)。右がその結果だ。ビルドフェーズの名前もわかりやすいものに変更している。

確認には、一度、クリーンしてからビルドを行い、Finder から build/Debug (または build/Release) の下にできているアプリバンドル(アプリ名.app)の内容を調べる。つまり、ポップアップメニューから「パッケージの内容を表示」でアプリバンドルを開き、Contents、Resources とたどり、そこに lib があること、またその中に prettify が、さらにその中には js ファイル(と 1 つの CSS ファイル)があることを確かめる。

おまけ

前回の記事(→「内部リンクの置き換えを実現する」)の HTML テンプレートと CSS ファイルの下りで、WebView にわたすベース URL について少し書いた。そこではアプリバンドルのトップの位置を(ファイル URL の形で)ベース URL に指定していた。このため、テンプレート中で CSS ファイルをリンクするために href='Contents/Resources/default.css' と書く必要があった。しかし、前回の記事中にも書いたように、これはベース URL の位置が適切とは言えない。Contents/Resources がベースになるべきだろう。

NSBundle のリファレンスを探してみたが、都合良く Contents/Resources をパスなり URL なりで取り出すメソッドは見つからなかった。そこで考えたのは、Contents/Resources をベースと考えるのではく、template.html の位置をベースとするというものだ。

追記@2010-12-12

上記の「都合良く Contents/Resources をパスなり URL なりで取り出すメソッド」は存在していて(resourcePath と resourceURL)、見つけられなかったのは、単にわたしの目がフシアナだっただけ。別件で「Objective-C逆引きハンドブック」を調べていて見つけた。「NSBundle Class Reference」を見直したら、そこにもちゃんと書かれていた。

このメソッドを使うなら、以下に書いた baseURL メソッドはこう書ける。

- (NSURL *)baseURL {
    return [[NSBundle mainBundle] resourceURL];
}

そうだよなあ。ないはずないよなあ。昨日のわたしはどんな目をしてたんだろう。(´・ω・｀)

Objective-C逆引きハンドブック

林晃
シーアンドアール研究所 ( 2010-02-26 )
ISBN: 9784863540514

物読みファイル (別館)で詳細を見る

MediaMarker

具体的には NSBundle のメソッドで template.html の位置をファイル URL として取得し、パスのコンポーネントに分解。最後の要素(template.html そのもの)を取り除いた上で、残った要素からファイル URL を組み立てる。これで template.html が置かれたフォルダのファイル URL が出来上がる。

該当する部分のコードを以下に示す(AppController.m より)。

- (NSURL *)fileURLForHTMLTemplate {
    NSBundle *mainBundle = [NSBundle mainBundle];
    return [mainBundle URLForResource:BGHTMLTemplateName withExtension:@"html"];
}

- (NSURL *)baseURL {
    // the base URL must be identical to the path of the HTML template.
    NSMutableArray *components = 
    [NSMutableArray
     arrayWithArray:[[self fileURLForHTMLTemplate] pathComponents]];

    [components removeLastObject]; // remove the template name

    return [NSURL fileURLWithPathComponents:components];
}
@end

ただし、この方法では、template.html がローカライズ対象となった場合に他のリソース(CSS や JavaScript)もローカライズ対象にしなければならない。CSS ならフォントの指定あたりで一部ローカライズすることもあるだろうが、さすがに JavaScript をローカライズすることはないと思う。ローカライズ対象に指定したところで English.lproj とか Japanese.lproj にコピーされるだけのことだが、少しムダかなと言う気にはなる。

今回は template.html をベース URL のための目印に使ったが、ローカライズが絡む場合は別の目印を使うか、ビルドフェーズでアプリバンドル内にシンボリックリンクを張るなどの工夫が必要になるかもしれない。

内部リンクの置き換えを実現する (MacBloggerGlass)

2010-12-10T23:06:00.002+09:00

MacBloggerGlass を作り始めたとき(→「欲しいのはオフライン機能 - Cocoa アプリとして作り直す #0」)、機能実現のステップとして以下の 5 つを挙げた。

一覧表示
Google Data API Objective-C Client Library の組み込み
記事表示
ラベル検索
内部リンクの置き換え

多少、順序は入れ替わっているが、これまでの作業で 1 〜 3 が大筋で実現できている。今回は、内部リンクの置き換えを実現する。GAE 版のときにも書いたが、これができるようになると、アプリが実用的になる。以下が現在のプロトタイプ #0 のスクリーンショットだ。

MacBloggerGlass プロトタイプ #0
アプリウィンドウ

ウィンドウの上部に記事一覧、下部に一覧で選択した記事の内容をそれぞれ表示できるようになった。JavaScript を組み込んでいないものの、その他の点では Blogger Glass と同じスタイルで表示している。

Apple イベントの処理の作り込み

前回のサンプルアプリ(→ 「アプリに Apple イベントの処理を作り込む」)と同等の作り込みを行った。

独自スキームの定義

以下の内容を MacBloggerGlass-Info.plist に追加。太字の値はこちらで定義、他は Xcode のエディタではリストから選ぶだけで良い。

URL types
- Item 0
  - URL identifier → MacBloggerGlass Internal Link
  - Document Role → Viewer
  - URL Schemes
    - Item 0 → bgls

独自スキームを使った URL は以下の形とした。記事の識別に必要な情報だけを詰め込んでいる。

bgls://<blog-id>/<post-id>

Apple イベントハンドラの定義

追加するのは Get URL イベントのハンドラのみ。前回のサンプルアプリと同様、公式ドキュメントで推奨されているようにアプリのデリゲートクラス (MacBloggerGlassAppDelegate) に追加している。

追加後の MacBloggerGlassAppDelegate.m を以下に示す。

#import "AppController.h"
#import "MacBloggerGlassAppDelegate.h"

@implementation MacBloggerGlassAppDelegate

@synthesize window, appController;

- (void)applicationWillFinishLaunching:(NSNotification *)notification {
    NSAppleEventManager *appleEventManager =
    [NSAppleEventManager sharedAppleEventManager];
    [appleEventManager setEventHandler:self
                           andSelector:@selector(handleGetURLEvent:withReplyEvent:)
                         forEventClass:kInternetEventClass
                            andEventID:kAEGetURL];
}

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
 // Insert code here to initialize your application 
}

#pragma mark -
#pragma mark apple event handler
- (void)handleGetURLEvent:(NSAppleEventDescriptor *)event
           withReplyEvent:(NSAppleEventDescriptor *)replyEvent {
    NSAppleEventDescriptor *directObjectDescpritor =
    [event paramDescriptorForKeyword:keyDirectObject];
    if (! directObjectDescpritor) return;

    NSString *urlString = [directObjectDescpritor stringValue];
    if (! urlString) return;

    NSLog(@"APPLE EVET(GetURL): %@", urlString);

    // custom URL must be in the form like:
    //     bgls://<blog-id>/<post-id>
    NSURL *objectURL = [NSURL URLWithString:urlString];
    NSString *blogID = [objectURL host];
    // path will return a string with the form '/<post-id>'.
    NSString *postID = [[objectURL path] substringFromIndex:1];

    [appController openPost:postID inBlog:blogID];
}
@end

AppController.h を import しているのは、イベントハンドラの最後で、AppContoller のメソッドを呼び出しているから。アプリデリゲートでは、イベントから URL を取り出し、Blog ID と Post ID を切り出すところまでを行い、その後の処理はアプリコントローラに任せている。

また、アプリデリゲートとアプリコントローラの結びつけは、デリゲート側にコントローラ用のアウトレットを設け、Interface Builder 上で接続している。どちらのオブジェクトも MainMenu.xib 内にインスタンス化されているので、これが一番手軽な方法だと思う。

メインコントローラ (AppController) への作り込み

コントローラ側での処理を以下に示す。ここでは、カスタム URL にふくまれている Blog ID を現在表示中のものと比較している。他のブログ(自分で作ったもの)の扱いについては、ひとまず無視することにしている。どう扱うと実用的かは将来の検討課題だ。

#pragma mark -
- (void)openPost:(NSString *)aPostID inBlog:(NSString *)aBlogID
{
    NSLog(@"Open post request: %@ (%@)", aPostID, aBlogID);
    if (! [aBlogID isEqualToString:blogID]) {
        NSLog(@"The blog requested is not currently displayed. (%@)", aBlogID);
        return;
    }
    NSUInteger index = [feed findPost:aPostID];
    if (index == NSNotFound) return;

    [postTable selectRowIndexes:[NSIndexSet indexSetWithIndex:index]
           byExtendingSelection:NO];

    [self showPostWithIndex:index];
}

指定した Posd ID に対応する記事オブジェクト(EntryBlogPost)を探すメソッドを一覧オブジェクト(FeedBlogPost)に実装している。検索は単純な線形探索。これで表示が遅くなるほどの記事数にはならないと思っている。

- (NSUInteger)findPost:(NSString *)aPostID {
    EntryBlogPost *entry;
    for (NSUInteger i = 0; i < [entries count]; i++) {
        entry = [entries objectAtIndex:i];
        if ([entry.postID isEqualToString:aPostID]) {
            return i;
        }
    }
    return NSNotFound;
}

内部リンクの置き換え

内部リンクの置き換えのために、GAE 版でも作ったように(→「内部リンクを置き換える #2」)、permalink と Post ID のひもづけを保持する仕組みが必要になる。

PairOfLinks は辞書で実現

蓄積と探索の処理を単純にするため、Cocoa 標準の辞書オブジェクト(NSMutableDictionary)を使った。ひもづけを保持するのは FeedBlogPost オブジェクトにした。これはこのオブジェクトが記事オブジェクト(EntryBlogPost)の配列を保持しているから、データを抽出するのに相応しいと考えたからだ。以下に FeedBlogPost.m 内の抽出処理を示す。

- (void)extractPairOfLinks {
    pairOfLinks =
    [[NSMutableDictionary alloc] initWithCapacity:[entries count]];
    EntryBlogPost *post;
    for (post in entries) {
        [pairOfLinks setObject:post.postID forKey:post.permalink];
    }
}

置換処理の実際

記事データ中のリンク文字列の置換は、WebView に HTML データをわたす直前に行っている。href="<permalink>" と href='<permalink>' をそれぞれ置換するという手抜きコーディングにしてある。

- (void)renderHTML:(NSString *)content
             title:(NSString *)title
       withBaseURL:(NSURL *)baseURL {
    // replace internal links into those have custom URL.
    NSString *replacedContent = content;
    NSString *permalink;
    for (permalink in [feed.pairOfLinks allKeys]) {
        NSString *aPostID = [feed.pairOfLinks objectForKey:permalink];
        NSString *customLink =
        [NSString stringWithFormat:@"href='bgls://%@/%@'", blogID, aPostID];

        // replace href attribute values wrapped with double quotation
        NSString *targetLink = [NSString stringWithFormat:@"href=\"%@\"", permalink];
        replacedContent =
        [replacedContent stringByReplacingOccurrencesOfString:targetLink
                                                   withString:customLink];

        // replace href attribute values wrapped with single quotation
        targetLink = [NSString stringWithFormat:@"href='%@'", permalink];
        replacedContent =
        [replacedContent stringByReplacingOccurrencesOfString:targetLink
                                                   withString:customLink];
    }
    
    NSString *htmlData =
    [NSString stringWithFormat:templateData, title, replacedContent];

    NSLog(@"Base URL: %@", baseURL);
    [[postView mainFrame] loadHTMLString:htmlData baseURL:baseURL];
}

このメソッドはアプリウィンドウで記事の一覧が選択されたときに呼ばれる。その際、baseURL としてアプリバンドル(MacBloggerGlass.app)のトップが URL としてわたってくる。その部分を以下に示す。

- (void)showPostWithIndex:(NSUInteger)index {
    EntryBlogPost *entry = [feed objectInEntriesAtIndex:index];
    NSLog(@"Post ID: %@", entry.postID);
    [self renderHTML:[entry content]
               title:[entry title]
         withBaseURL:[[NSBundle mainBundle] bundleURL]];
}

表示機能の作り込み

最後に、記事表示機能の作り込みとして、記事データを流し込む HTML のテンプレートと CSS ファイルの組み込みについて説明する。

HTML のテンプレートと CSS ファイル

テンプレートも CSS ファイルも、アプリバンドル (MacBloggerGlass.app) の中に置くことにした。

以下はテンプレートをロードする処理で、アプリコントローラ (AppController) で定義している。NSBundle を使ってテンプレートファイルのパスを特定し、NSString に読み込んでいる。templateData という変数は AppContoller のメンバ変数だ。

- (void)loadHTMLTemplate:(NSString *)templateName {
    NSBundle *mainBundle = [NSBundle mainBundle];
    NSString *pathForTempalte =
    [mainBundle pathForResource:templateName ofType:@"html"];

    templateData = [[NSString alloc] initWithContentsOfFile:pathForTempalte
                                                   encoding:NSUTF8StringEncoding
                                                      error:NULL];
}

読み込まれるテンプレートは以下のもの。注意すべきは 6 行目のスタイルシートへのリンクだ。このテンプレートと CSS ファイルはアプリのリソースの一部として、アプリバンドル(MacBloggerGlass.app)の中にコピーされる。先に示したように、WebView にわたすベース URL としてアプリバンドルのトップを指定している。このため、CSS ファイルの相対パスは 6 行目のようになるわけだ。ただ、これはベース URL の指定を変えて、Contents/Resources がベースになるようにすべきかもしれない。後で、NSBundle のリファレンスをもう少し調べてみよう。

<!DOCTYPE HTML>
<html lang='ja'>
<head>
<meta content='text/html; charset=UTF-8' http-equiv='Content-Type'>
<title>MacBloggerGlass</title>
<link type='text/css' rel='stylesheet' href='Contents/Resources/default.css'>
</head>
<body>
<article>

<div id='view-header'>
  <h3>%@</h3>
</div>

<div id='content'>
%@
</div>

</article>
</body>
</html>

CSS は Blogger Glass で使っているものを手直しして流用。手直しは、テンプレートの構造の変更に対応するためのもの。冒頭のスクリーンショットは、現在の MacBloggerGlass のものだが、GAE 版の Blogger Glass と同じスタイルが使われていることが見てとれる。

次の一手

記事表示の機能については、まだ細部の詰めが残っている。たとえば、ソースコード表示用の JavaScript を組み込むことなど。

記事表示が GAE 版と同等になったら、その次はラベル検索に取り組むか。機能的には GAE 版と同じく GData を使って検索するもので良いが、問題はユーザ体験だ。まずは、そこからになるな。

いや、それより先に「オフライン機能」すなわちデータの保存について考えるべきだろう。そもそもそのための Cocoa 版なのだから。

twitter より (2010-12-09)

2010-12-10T07:34:00.002+09:00

17:50 荻原本がアップデートするらしい。→ http://www.sbcr.jp/products/4797361780.html

アプリに Apple イベントの処理を作り込む - アプリを開くリンク #2

2010-12-09T20:41:00.000+09:00

前回(→「アプリを開くリンク #1」)に引き続き、Launch Services が送ってくる Apple イベントを処理するための作り込みについて調べた。簡単なサンプルアプリを作って動作を確認した。

以下では、WebView でアプリの独自スキームを持った URL へのリンクをクリックしたときに、アプリに送られてくる get URL という Apple イベントを処理するための作り込みの手順を説明する。

今回の記事のネタは主に「Cocoa Scripting Guide: How Applications Handle Apple Events」から拾っている。

Cocoa アプリにおける Apple イベントの処理

Automator.app を使ってアプリを使った作業の自動化(→「AppleScript を使って URL を Safari のタブで開く」)をしようとしてみると、アプリの中には Apple Script でさまざまな制御が可能なものと、そうでないものがあることに気付く。Safari などは前者で、ウィンドウのサイズを変えたり、指定した URL を開かせたりといったことが Apple Script から制御できる。一方、Cocoa Emacs のように限られた制御(アプリの起動等)しかできないアプリもある。前者のように様々な制御を受けるアプリのことを「スクリプト制御可能(scriptable)」だと言う。

アプリがスクリプト制御可能なように作られているかどうかに関係なく、Cocoa は Mac OS X が GUI アプリに送る必須イベントに対するデフォルトの処理(ハンドラ)を提供している。一番、わかりやすい例はアプリを起動する open application イベントだろう。このデフォルトの実装があるおかげで「Apple Script やイベントのことなんて知らない」と言うアプリでも、Launch Services から起動することができる。また、デフォルトハンドラはデリゲートの仕組みを使っており、NSApplication のデリゲート(NSApplicationDelegate プロトコルを実装したクラス)でデリゲートメソッドを定義してやればハンドラの動作をカスタマイズすることができる(イベントとデリゲートメソッドの組み合わせについては「Cocoa Scripting Guide: How Applications Handle Apple Events」を参照のこと)。

ただ、Cocoa が提供するデフォルトのイベントハンドラは限られていて、具体的には「アプリの起動」「アプリの再起動(アクティベート)」「ドキュメントを開く」「印刷」「コンテンツを開く」、そして「アプリの終了」だ。残念ながら URL を開くイベント(get URL)に対するハンドラはデフォルトの実装には含まれていない。これについては、アプリが独自ハンドラとして追加しなければならない。

Apple イベントハンドラの追加

イベントハンドラの追加はそれほど難しいことではない。特定の形のメソッドを定義し、それをハンドラとしてイベントマネージャ(NSAppleEventManager)に登録するだけで良い。

ハンドラは以下の形にする。ただ、handleAppleEvent の部分はイベントに応じて名前を変えても良いようだ。たとえば、後述するサンプルアプリで定義したハンドラではここは handleGetURLEvent となっている(これは「Cocoa Scripting Guide: How Applications Handle Apple Events」の Installing a Get URL Handler で例として使われている名前でもある)。一方で、Mac OS X Reference Library のサンプルコードでは同じイベントのハンドラに対して handleOpenLocationAppleEvent という名前が付いている。引数の数と型が一致していれば良いのかも。

- (void)handleAppleEvent:(NSAppleEventDescriptor *)event
          withReplyEvent:(NSAppleEventDescriptor *)replyEvent;

「Cocoa Scripting Guide: How Applications Handle Apple Events」には具体的なハンドラの定義は載っていなかったため、Mac OS X Reference Library を検索したところ、サンプルコードに get URL イベントのハンドラの例を見つけた(→ CoreRecipesApp/AppDelegate.m)。次に示すサンプルアプリのハンドラの定義は、ここから流用したものだ。

サンプルアプリ

独自スキームの定義

以下は前回の記事(→「アプリを開くリンク #1」)に載せたスクリーンショットだが、再掲しておく。このサンプルアプリが受け付ける独自 URI スキームに sample を設定している。

Info.plist に URL タイプを追加する様子

URI スキームとして sample という文字列を指定している。

Get URL ハンドラの定義

ハンドラの定義とその登録は、ドキュメントの推奨どおりにアプリケーションデリゲイトで行っている。以下はその部分の抜粋だ。applicationWillFinishLaunching: で、Get URL ハンドラ handleGetURLEvent:withReplyEvent を登録している。

- (void)applicationWillFinishLaunching:(NSNotification *)notification
{
    NSAppleEventManager *appleEventManager = 
    [NSAppleEventManager sharedAppleEventManager];
    [appleEventManager setEventHandler:self 
                           andSelector:@selector(handleGetURLEvent:withReplyEvent:)
                         forEventClass:kInternetEventClass
                            andEventID:kAEGetURL];
}

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
 // Insert code here to initialize your application 
}

// Apple event handler
- (void)handleGetURLEvent:(NSAppleEventDescriptor *)event
           withReplyEvent:(NSAppleEventDescriptor *)replyEvent
{
    NSAppleEventDescriptor *directObjectDescriptor =
    [event paramDescriptorForKeyword:keyDirectObject];

    if (directObjectDescriptor) {
        NSString *urlString = [directObjectDescriptor stringValue];
        if (urlString) {
            NSURL *objectURL = [[NSURL alloc] initWithString:urlString];
            if (objectURL) {
                NSString *host = [objectURL host];
                NSString *path = [objectURL path];
                NSString *description =
                [NSString stringWithFormat:@"%@ in (%@)", path, host];
                [appController updateContent:description];
            }
        }
    }
}

このハンドラは受け取ったイベントの内容から URL を取り出し、さらにそこからホスト名とパスを抽出して、WebView を抱える AppController に渡している。

AppController では、イベントハンドラから受け取った文字列を WebView に渡す HTML に埋め込み、再表示させている。以下にその実装部(AppController.m)を示す。

#import <WebKit/WebKit.h>

#import "LaunchAppAppDelegate.h"
#import "AppController.h"

NSString * const HTMLTemplate = 
@"<html>\n"
@"<body>\n"
@"<h1>%@</h1>\n"
@"<ul>\n"
@"<li>Requested: %@</li>\n"
@"</ul>\n"
@"<p><a href='sample://1234567890/0987654321'>Click me!</a>"
@"(sample://1234567890/0987654321)</p>\n"
@"</body>\n"
@"</html>\n";

@interface AppController (PrivateMethods)
- (void)renderHTML:(NSString *)html;
@end


@implementation AppController
- (void)awakeFromNib
{
    appDelegate.appController = self;
    [self renderHTML:[NSString
                      stringWithFormat:HTMLTemplate, @"Sample App", @""]];
}

- (void)updateContent:(NSString *)request
{
    [self renderHTML:[NSString
                      stringWithFormat:HTMLTemplate, @"Sample App", request]];
}

@end

@implementation AppController (PrivateMethods)
- (void)renderHTML:(NSString *)html
{
    [[display mainFrame] loadHTMLString:html
                                baseURL:[NSURL URLWithString:@"http://localhost"]];
}
@end

HTMLTemplate の定義では見易くするために文字列オブジェクト定数を並べて置いている。これらはコンパイル時に連結され 1 つの文字列オブジェクト定数となる。

動作確認

クリックする前と後のスクリーンショットを示す。これにより、アプリの抱える WebView からそのアプリの独自 URL へのリンクをクリックすることで、実行中のアプリ自身にイベントを飛ばせることが確認できた。MacBloggerGlass で内部リンクの置き換えを実現できる目処が立ったことになる。

WebView で独自 URL をクリックした際の動作確認
クリック前

「Requested」の横には何も表示されていない。Click me! をクリックすると……
クリック後

「Requested」の横に URL にふくまれていた情報が抜き出されてきた。

twitter より (2010-12-08)

2010-12-09T07:33:00.002+09:00

09:51 今の iPad は少々大きいと思う。Retina ディスプレイがあれば同じ画素数でももっと小さくできるよね。B6ぐらいのサイズで作ってくれないかな。 → http://bit.ly/hejP3z
10:10 RT @yukihiro_matz: 字下げ依存構文の解析 - 再帰の反復: http://bit.ly/hzJwtX

アプリを開くリンク #1 - 内部リンクの置き換えのために (MacBloggerGlass)

2010-12-08T20:10:00.000+09:00

以前の記事で、内部リンクの置き換えを実現するためには記事内容をファイルとしてローカルのストレージに書き出すしかないかも、と書いた(→「記事の表示機能を作る (MacBloggerGlass)」)。ここ数日、Cocoa Bindings の使い方をあれこれ調べる間もそのことについて考え続けてきた。今日になって、「あれ、そう言えば iTunes Store のリンクって Safari から iTunes に飛ぶよな」と気付いた。

たとえば、以下のリンクは「itms://」で始まる URL で、Safari でクリックすれば iTunes.app で Coldplay の新曲(2010-12-08 時点)のページが開く(Mac と iPad で確認)。

itms://itunes.apple.com/jp/album/christmas-lights-single/id406970808

ちなみに、Safari 以外のブラウザだと、iTunes.app を開く前に確認のダイアログが現れる。右のスクリーンショットは Google Chrome でこのリンクをクリックしたときに出てくるものだ。

Safari (つまり WebView) でリンクをクリックしてアプリに通知させることができるなら、内部リンクをそれで置き換えれば良い。そうすれば MacBloggerGlass (以下、MBG) から、MBG 自身に開きたい記事の情報を伝えることができる。フィードデータから記事ごとに HTML ファイルを作って書き出して、file:/// でアクセスするよりもスマートだ。

もっとも、MBG を作る動機にもなっている「オフラインでも読める」ようにするためには、記事の内容をふくめたフィードデータをローカルに保存しなくてはならないんだけど。

ともあれ、これで方向性が定まった。まずは「アプリを開くリンク」について調べるところからだ。

itms:// を開こうとしたとき、誰が iTunes を起動するのか？

では、特定の URI スキーム (http://... の http の部分) とそれを扱うアプリの組み合わせを知っているのは誰だろう？ Safari のようなブラウザ自身だろうか？少なくとも Mac OS X では(おそらく iOS でも) 専用のサービス (API) が用意されている。

(「Launch Services Programming Guide: Introduction」より)
Launch Services is an API that enables a running application to open other applications or their document files or URLs (uniform resource locators) in a way similar to the Finder or the Dock. Using Launch Services, an application can perform such tasks as:

Open (launch or activate) another application

Open a document or a URL in another application

Identify the preferred application for opening a given document or URL

[...snip...]

この Launch Services がドキュメントのタイプや URL タイプとアプリの組み合わせを保持している。では、Launch Services はその組み合わせの情報をどこから得るのか？それはアプリが持っている Info.plist の記述からだ。

具体的には、Info.plist 中の CFBundleURLTypes にアプリが開くことのできる URL タイプが記述されている。

Property List の書き方

Info.plist は Property List と呼ばれる XML 形式で記述する。以下に Xcode が作るデフォルトの Info.plist を示す。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>CFBundleDevelopmentRegion</key>
 <string>English</string>
 <key>CFBundleExecutable</key>
 <string>${EXECUTABLE_NAME}</string>
 <key>CFBundleIconFile</key>
 <string></string>
 <key>CFBundleIdentifier</key>
 <string>com.yourcompany.${PRODUCT_NAME:rfc1034identifier}</string>
 <key>CFBundleInfoDictionaryVersion</key>
 <string>6.0</string>
 <key>CFBundleName</key>
 <string>${PRODUCT_NAME}</string>
 <key>CFBundlePackageType</key>
 <string>APPL</string>
 <key>CFBundleShortVersionString</key>
 <string>1.0</string>
 <key>CFBundleSignature</key>
 <string>????</string>
 <key>CFBundleVersion</key>
 <string>1</string>
 <key>LSMinimumSystemVersion</key>
 <string>${MACOSX_DEPLOYMENT_TARGET}</string>
 <key>NSMainNibFile</key>
 <string>MainMenu</string>
 <key>NSPrincipalClass</key>
 <string>NSApplication</string>
</dict>
</plist>

URL タイプは、トップレベルにある dict 要素の子として記述する。つまり、CFBundleExecutable などと同じレベルの要素にする。その際、CFBundleURLTypes が dict の array になるように構成する。そして、各 dict の中身には以下の 4 つの要素を置く。

CFBundleURLType 内の要素 (「Launch Services Programming Guide」より)
Key	Type	Description
CFBundleTypeRole	string	アプリがドキュメントをどのように扱うものなのか。Launch Services が認識するのは Editor、Viewer、そして None の 3 つのみ。
CFBundleURLName	string	URL タイプの名前
CFBundleURLIconFile	string	このタイプの URL を表示する際に使われるアイコンファイルの名前
CFBundleURLSchemes	array	このタイプにふくまれる URL のスキームの配列。各スキームは string として記述する。

典型的な CFBundleURLTypes の構造は以下のようになる。

CFBundleURLTypes
+-- array
    +-- dict
    |   +-- CFBundleTypeRole
    |   |   +-- string
    |   +-- CFBundleURLName
    |   |   +-- string
    |   +-- CFBundleURLIconFile
    |   |   +-- string
    |   +-- CFBundleURLSchemes
    |       +-- array
    |           +-- string
    |           +-- string
    |           ...
    +-- dict
        ...

iTunes.app の Info.plist を覗いてみると、CFBundleURLIconFile は省略しても構わないようだ。

以下のスクリーンショットは、実際に Xcode 中で Info.plist を編集し、URL タイプを 1 つ、追加したところのものだ。

Info.plist に URL タイプを追加する様子

左に表示されている要素の種類はドロップダウンリストの中から選ぶことができる。トップレベルで URL Types を選ぶとその子要素の構造も同時に作られる(デフォルトでは URL Identifier だけが追加されている)。この例では URI スキームとして sample という文字列を指定している。

アプリ側での作り込み

Launch Services はアプリに対してアプリの起動や URL を開く等の Apple イベントを送ってくる。つまり、アプリは送られてきたイベントを適切に処理することができなければならない。

そのためにはどういうコードを書けば良いのか？それは次回の記事で(ドキュメントは見つけてあるがまだ読んでいない→「Cocoa Scripting Guide: How Cocoa Applications Handle Apple Events」)。

twitter より (2010-12-07)

2010-12-08T07:33:00.002+09:00

13:13 もう、4 は見送りかな。ここまで待って、今更、黒を手に入れるっていうのもモヤモヤが残る。5 を待つか。→ http://ipodtouchlab.com/2010/12/iphone4-white-delay-confirmed.html

Cocoa Bindings の肝は KVC 準拠だ

2010-12-07T23:22:00.002+09:00

ようやく Cocoa Bindings の謎が解けたように思う。少なくとも、Cocoa Bindings を使ったアプリを作るための「心得」のようなものを見つけることができた。以下で、それを簡単に説明してみる。

用語の整理

まずは用語の整理。Cocoa Bindings 関連のドキュメントを読むためには以下の KVC の用語とそれが意味する概念を理解しておく必要がある。

KVC (Key-Value Coding) とは、オブジェクトが持つプロパティに対してキーとなる名前を介してアクセスすること、およびそのためのオブジェクト側の実装のことだ。「KVC でアクセスする」とか「このクラスは KVC に準拠させてある」などと使う。

プロパティ(property)とは、オブジェクトがその内部に抱える「何か」のことで、典型的にはオブジェクトの内部状態を示す様々な値のことだ。ただし、プロパティとはオブジェクトの外部から見えるもののことで、必ずしもプロパティの値そのものが内部で保持されているとは限らない。プロパティとはオブジェクトのインタフェースのうち「何か」を返すものと言っても良い。

プロパティはその値とオブジェクトとの関係によって、以下の 3 つに分けられる。

属性(attribute)
対一関係(to-one relationship)
対多関係(to-many relationship)

属性(attribute)とはプロパティのうち、Objective-C で言う単純型のことで、数値や文字列の他、NSColor や NSNumber のような不変オブジェクトもふくまれる。

対一関係(to-one relationship)とは、プロパティがそれ自身のプロパティを持ったオブジェクトの場合を言う。以下に示す、AppController のプロパティ entry がこれにあたる。

@interface Entry : NSObject {
    NSString *title;
    NSString *content;
    NSDate *lastUpdateDate;
}

@interface AppController : NSObject {
    Entry *entry;
}

対多関係(to-many relationship)とは、簡単に言えばプロパティが配列のような集合型になっている場合のことだ。以下の Feed のプロパティ entries がこれにあたる。

@interface Feed : NSObject {
    NSMutableArray *entries;
}

KVC 準拠

あるクラスを(正確にはあるクラスの特定のプロパティを) KVC 準拠にするためには、いくつかの要件を満たさなければならない。これは、要は、プロパティに対するアクセス用メソッドを一定の規則による名前で作る、ということだ。

たとえば、title という文字列のプロパティを持ったクラスの場合なら、以下の 2 つのメソッドを定義する。

- (NSString *)title;
- (void)setTitle:(NSString *)aTitle;

この 2 つがあるなら、必ずしも属性を保持するインスタンス変数を定義する必要はない。

加えて、プロパティへのアクセスにはすべて(クラスの内部でも) KVC 方式を用いる。これは準拠に必須ではないが、こうすることで KVO が正しく機能する。KVC 方式とはインスタンス名に「.」(dot) でプロパティ名を連結した記法のことだ。たとえば、先のクラスのインスタンス名が entry なら、entry.title としてアクセスする。クラス内部では、インスタンス名として self を使えば良い。つまり、self.title で読み書きする。

対一関係の場合も同様だ。さらに、この場合、プロパティも KVC に準拠しているなら「.」でつなげてアクセスする。たとえば、self.entry.title のように。

対多関係の場合の追加

一方、対多関係の場合はプロパティが配列(の類)であるため、その要素にアクセスするためのメソッドも必要になる。最初に挙げた Feed の場合、以下のようなメソッドを定義する必要がある(要素として Entry を抱えると想定)。

// for KVC compliance (required)
- (void)insertObject:(Entry *)entry inEntriesAtIndex:(NSUInteger)index;
- (void)removeObjectFromEntriesAtIndex:(NSUInteger)index;
- (void)replaceObjectInEntriesAtIndex:(NSUInteger)index withObject:(Entry *)entry;
// for KVC compliance (optional)
- (int)countOfEntries;
- (Entry *)objectInEntriesAtIndex:(NSUInteger)index;

これらのメソッド名にはプロパティ名が埋め込まれている。たとえば、insert の場合、insertObject:in<key>AtIndex: の key のところにプロパティ名の entries が埋め込んである。他も同様だ。

KVO 準拠

KVO 準拠で何より大事なことはプロパティのアクセスはすべて KVC 方式で行う、ということだ。たとえば以下は、ここ数日、悩まされてきたエラーメッセージだ。このエラーの原因が、あるクラスで自分自身のプロパティへのアクセスに KVC 方式を使っていなかった(部分があった)ことにあった。

(実行時のログより)
Cannot update for observer <NSAutounbinderObservance 0x113761290> for the key path "feed.entries" from <PreferenceController 0x11375cc50>, most likely because the value for the key "feed" has changed without an appropriate KVO notification being sent. Check the KVO-compliance of the PreferenceController class.

具体的には、以下のようなコードになっていた。本来、reload の中で newArray をプロパティにセットした際に、これを監視しているオブジェクトたちに通知が飛ぶことになる。ところが、reload が実行される前に awakeFromNib の中で KVC 方式を使わずに entries を変更してしまっていたため、この通知が送れなくなっていた。それが上のエラーだ。awakeFromNib の中でも、reload と同様に self.entries という表記を使うようにすることで、この問題は解消した。

@implementation AppController
[...snip...]
- (void)awakeFromNib
{
    [...snip...]
    entries = [[NSMutableArray alloc] init];
    [...snip...]
}

- (IBAction)reload:(id)sender
{
    [...snip...]
    self.entries = newArray;
    [...snip...]
}

また、対多関係プロパティの場合、プロパティへの要素の追加・変更・削除では、先述のように KVC 準拠のために定義したメソッドを使わなければならない。

まとめ

以上が、ここ数日、悩まされてきた問題に対する一応の解答になる。まとめると、Cocoa Bindings を使ったアプリを作る上で肝心なことは、とにもかくにも KVC 準拠ということになる。

そして、KVC 準拠でクラスを作ろうと思うなら徹底して KVC 準拠にすることだ。特定のプロパティだけを KVC 準拠にしようなんて中途半端なことを考えていると、抜けが出てくる。ひとつのクラスの一部は KVC 準拠で他は違うというような状態では、(プログラムが動かないとわかってから)準拠の抜けを探すのは難しい。デバッグで苦労するよりも、コーディング中に少し余分に気を使う方が良い。

Cocoa Bidings を使ったアプリ (MVC アーキテクチャを想定) を作るなら、まずはモデルのクラスをを KVC 準拠で作ること。また、モデル内部の他のメソッドでも、モデルオブジェクトを扱うコントローラの実装でも、とにかくモデルのプロパティへのアクセスには KVC を使うこと。対多関係を使うなら(モデルが配列等を内部に抱えるなら)、内部の配列に直接アクセスするのではなく、insert や remove、replace といったメソッドを KVC 準拠の形式で定義すること。

あとひとつ付け加えるとすれば、やはり Interface Builder に対する慣れだろうか。インスペクタで GUI 部品の設定をあちこちいじっていると、どこをどう変更したのかがわからなくなってくる。どうしても動かなくて困っていたところ、部品を一度削除して最初から設定し直すと動いた、なんてことが時々起こる。こればかりは慣れるしかないと思う。部品を汎用に作ろうとすれば設定項目を増やさざるを得ず、設定項目が増えればそのためのツールは複雑になるものだから。

参考文献

詳解 Objective-C 2.0

荻原剛志
ソフトバンククリエイティブ ( 2008-05-28 )
ISBN: 9784797346800

物読みファイル (別館)で詳細を見る

MediaMarker

まだ Cocoa Bindings の謎が解けない

2010-12-06T23:12:00.004+09:00

前回の状態(→「Cocoa Bindings がわからなくなってきた」)からまだ抜け出せない。以下に、今、ハマっている状況を簡単に説明してみる。

モデルとコントローラの構造と関係は以下のようになっている。Feed の entries は配列(NSMutableArray)で Entry のインスタンスを抱えている。Entry のプロパティは文字列(NSString)や日付(NSDate)といったオブジェクトだ。このモデルをアプリの主コントローラが抱えている、という形だ。Atom 形式のデータの構造を扱うアプリを想定している(MacBloggerGlass もその一つ)。

+--------------+
| AppContoller |
+--------------+        +--------------+
| feed        --------->| Feed         |
| ...          |1     1 +--------------+       +--------------+
+--------------+        | entries     -------->| Entry        |
                        | ...          |1    * +--------------+
                        +--------------+       | title        |
                                               | content      |
                                               | lastUpdate   |
                                               | ...          |
                                               +--------------+

やりたいことは、Feed が抱える Entry オブジェクトのデータを表(NSTableView)に写し出すことだ。

Cocoa Bindings を使わないなら、AppController を NSTableView のデータソースにすることになる。これは簡単に言うと、NSTableView から「この行のここの列に表示するデータはどれ？」という問い合わせに AppController が答える方式だ。行と列を指定して、配列に収められたオブジェクトのプロパティを取り出すコードを AppController に実装することになる。

Cocoa Bindings を使えばそのコードを書かなくて済む。NSArrayController を介してモデルとビュー(NSTableView)を結びつけることでコードを書かずに同じことを実現できる……はずなのだが、なんだかうまくいかない。いや、うまく動くときもある。まったく動かないなら間違っていることだけは確実にわかる。けれど、同じように書いたり設定したりしたつもりのものが動いたり動かなかったりすると、かえってわかりにくくなる。

どうやら、肝となるのはモデルとコントローラが KVC と KVO に準拠することらしい。で、KVC に準拠するにはどうすれば良いか、についてはわかってきた。だが、KVO への準拠のための施策が良くわからない。ドキュメント(Key-Value Observing Programming Guide)に Ensuring KVO Compliance という項目があるものの、そこに書かれているのは 2 つの項目だけ。しかもそのうちの 1 つは KVC に準拠しろ、というもの。残る一つがこれ。

(「Key-Value Observing Programming Guide: Ensuring KVO Compliance」より)

The class must allow automatic observer notifications for the property, or implement manual key-value observing for the property.

これだけじゃなあ。もう少し細かく書いて欲しいよ。(´・ω・｀)

とにかく、今日も先には進めていない。明日も、今日の続きで Cocoa Bindings の謎と格闘することになる。

追記@2010-12-08

この記事に書いた問題はひとまず解決した。「Cocoa Bindings の肝は KVC 準拠だ」を参照のこと。

Cocoa Bindings がわからなくなってきた

2010-12-05T21:28:00.001+09:00

この数日、Cocoa Bindings の使い方で悩んでいる。というより、混乱している。

MacBloggerGlass に環境設定パネルを作る際にモデルとビュー(パネルに配置した GUI 部品)を結びつけるために、Cocoa Bindings を使った。試行錯誤とドキュメントの流し読みで、どうにか動くものができた。その過程で Cocoa Bindings についても理解した、と思っていた。

同じことをアプリのメインウィンドウでもやろうとした。環境設定パネルでブログの一覧をテーブルビューに表示させたように、メインウィンドウでも記事一覧をテーブルビューに表示させるのに Cocoa Bindings を使おうとしたのだ。これがうまくいかない。環境設定パネルの時と同じように書いたら動かない。

試行錯誤を繰り返し、メインウィンドウでも表示できるようになったが、そのコードは環境設定パネルのものとは少し異なっていた。具体的には、プロパティの更新を KVO で通知する部分が違う。

なにかおかしい。もちろん、おかしいのはわたしの理解の方だ。基本に立ち返って、KVC、KVO の理解を点検するところから始めようと思う。ここをクリアにしない限り、先には進めない。

追記@2010-12-08

この問題については、以下の後続記事を参照のこと。一応、解決している。

まだ Cocoa Bindings の謎が解けない
Cocoa Bindings の肝は KVC 準拠だ (これが一応の解決編)

記事の表示機能を作る (MacBloggerGlass)

2010-12-04T23:06:00.003+09:00

右のスクリーンショットは MacBloggerGlass のプロトタイプ #0 だが、アプリウィンドウの上部が記事一覧、下部が一覧で選んだ記事内容の表示となっている。これを見る限り、一応記事表示らしいことはできるが、前にも書いたように、これはフィードから切り出した/データをそのまま、WebView に流し込んでいるだけだ。言わば HTML の断片で、正しい HTML にするためには、いろいろと補わなければならない。

というより、GAE 版のようにテンプレートを用意し、このデータを流し込むようにするべきだ。さらに言えば、テンプレートの HTML 的な構造は GAE 版と同じにしておきたい。そうすればスタイルシートがそのまま使える。

GAE 版の Mac 用(記事表示画面)テンプレートの構造(の概略)は以下のようになっている。この div.content の部分に、フィードから切り出した記事のデータを(多少、記事タイトル等の付加情報を付けて)流し込んでいる。

html
+-- head
+-- body
    +-- header
    +-- section
    |   +-- div.content
    |       ...
    +-- footer

Objective-C でこれ(テンプレートの利用)をやるには、どうすれば良いか？手軽な方法は、テンプレートを div.content で 2 つに分けてしまうものだろう。そして、前半分、記事内容、後半分の 3 つを連結し、一時ファイルに保存するか、または文字列で直接、WebView にわたす。

CSS や JavaScript もアプリの中に抱えることになる。HTML 中からそこへのリンクをどうするか。「file:///」でアクセスすることになるから問題はパス。一時ファイルに書き出すなら、その場所から MacBloggerGlass.app の中のファイルにリンクすることになる。つまり、CSS 等へのリンクは実行時に生成して、HTML に書き込まなければならない。

いっそのこと、CSS 等の付属ファイルも一時ファイルの置き場所にまとめて書き出すか。それなら、リンクは相対表記になりあらかじめテンプレートに書き込んでおける。そうなると一時ファイルというか実行時の環境だな。

そういえば、今、気付いたが、内部リンクをどうすれば良いのか。WebView に HTML としてわたしてしまったらただのリンク、クリックすれば(WebView は)ブラウザとして開くだろう。アプリには手の出しようがない。となると、記事内容はファイルとして書き出すしかないか。そうすれば内部リンクはローカルファイルの参照に書き換えられる。書き出す場所は ~/Library/MacBloggerGlass あたりに。

ウェブアプリなら簡単に実現できること(内部リンクはアプリへのリクエストに書き換える)がローカルなアプリには難しい。そういうものがあるとはね。ちょっと意外だった。

追記@2010-12-08

↑のリストに「内部リンクを置き換える #1 (Blogger Glass)」を追加。

Google App Engine SDK がアップデート (1.3.8 → 1.4.0)

2010-12-03T14:55:00.002+09:00

2010-12-02 付けで Python 版 Google App Engine SDK がバージョンアップしている。iMac で作業をしていると、Google アプリのアップデータが起動して、GoogleAppEngineLauncher.app が更新されたと告げられた。そのままアップデートを実行。Java 版のことはわからないが、公式サイトからダウンロード可能な SDK のバージョンは Python 版と同じ 1.4.0 になっている。

で、何が変わったかを調べようと公式ドキュメントのページから Release Note を開いた。以下に、ざっくりと超直訳してみる。誤解、曲解、いろいろふくまれている可能性がある。訳の品質に期待しすぎないように。

Always On 機能はアプリが 3 つのインスタンスを常時実行状態のまま保持することのできる機能だ(課金対象)。アプリの遅延を著しく削減することができる。
開発者は Warmup リクエストを有効にできるようになった。アプリの app.yaml 中でハンドラを指定すると、App Engine はアプリの新しいインスタンスがユーザからのリクエストを受け付け始める前に、その初期化のために Warmup Request を送ろうとする。これにより、エンドユーザがアプリの初期化にともない感じる遅延を削減できる。
Channle API がすべてのユーザで利用できるようになった。
Task Queue が公式にリリースされ、もはや実験的な機能ではなくなった。'labs' を使った API のインポートパスは非推奨となった。Task Queue で使うストレージはアプリ全般のストレージ割り当て量として計量され、課金の対象となる。
Task Queue と Cron リクエストのデッドラインが 10 分に引き上げられた。それらのリクエスト中であっても、データストアと API のデッドラインは以前から変更されていない。
Task Queue に対して、開発者は queue.yaml でタスクの retry_parameters を指定できる。
課金を有効にしているアプリでは Task Queue API で待ち行列(queue)を 100 個まで使える。
データストアに対して種別、名前空間および実体のプロパティを問い合わせるメタデータクエリが使えるようになった。
URLFetch ではレスポンスのサイズとして 32 MB まで許されるようになった。リクエストのサイズは引き続き 1MB までとなっている。
イメージ API に対するリクエストとレスポンスのサイズが 32BM に増やされた。Memcach のバッチ操作の合計サイズが 32 MB に増やされた。Memcache の個別のオブジェクトに対する 1MB の制限は引き続き適用される。
送信メールへの添付のサイズが 1MB から 10MB に増やされた。受信メールのサイズ制限は引き続き 10MB となっている。
データストア上のバッチ方式による get/put/delete の操作に対する大きさと数量の制限は取り除かれた。個別の実体は引き続き 1MB に制限されているが、データストア全体に対するデッドラインに余裕があれば、バッチ方式で望むだけ多くの実体を同時に get/pub/delete 処理することができる。
クエリー結果をもとに反復する場合、データストアサービスは非同期に結果を先読みするようになった。これにより遅延を 10 - 15 % 削減できる場合がある。
管理コンソールの Blacklist ページは拒絶された訪問者の上位の一覧を表示する。
画像のサムネイルの自動生成サービスは 1600px までの任意の切り取りサイズをサポートする。
管理コンソールに表示される全般的なインスタンス遅延の平均値は、インスタンスごとの QPS に応じた平均値になった。
アプリのあるバージョンをアップロードした開発者は appcfg.py download_app コマンドを使ってそのバージョンのコードをダウンロードできる。この機能はアプリごとに管理コンソールの Permissions タブで無効にできる。一度無効にすると、この機能を再度有効にすることはできない。
独自ドメインで Google Appes を使っているユーザに対して、カスタム管理コンソールのページが機能していなかった問題を修正。
Python 実行環境では、リクエストハンドラが DeadlineExceededError を起こした場合は、インスタンスは強制終了された後に再開される。これは、Django を使っているときに SystemErrors が周期的に起きる問題と関連して修正されるべきだ。
http://code.google.com/p/googleappengine/issues/detail?id=772
webapp.template とピュア Django を混在させたときに起きる Django のバージョンの不一致を避けるため、Django の初期化を appengine_config.py に移動できるようになった。
http://code.google.com/p/googleappengine/issues/detail?id=1758
SSL 上の OpenId の問題を修正。
http://code.google.com/p/googleappengine/issues/detail?id=3393
dev_appserver で login/logout のためのコードが Python 2.6 で動かない問題を修正。
http://code.google.com/p/googleappengine/issues/detail?id=3566
dev_appserver で get_serving_url が透明で長さの足りない(cropped) PNG に対して機能しない問題を修正。
http://code.google.com/p/googleappengine/issues/detail?id=3887
DatastoreFileSub の問題を修正。
http://code.google.com/p/googleappengine/issues/detail?id=3895

Blogger Glass に関係する変更としては、Task Queue が公式に GAE のサービスの一部としてリリースされたことぐらいのようだ。API が変わったとは書いていないから、今までのコードはそのまま動くってことだろう。とりあえず、taskqueue の import から labs のネームスペースを削除しておいた。appspot に配備ずみ。

設定変更を通知する - 環境設定パネルを作る #4 (MacBloggerGlass)

2010-12-02T23:47:00.004+09:00

今回の記事の内容は、環境設定パネルで Blog ID を保存したときに(「Save」ボタンを押す)、アプリウィンドウに表示されているブログ一覧が変更された ID のものに自動的に変わるようにするための実装について。このような動作を実装する意図については、前回の記事(→「次は NSNotification に取り組む」)を参照してもらいたい。

変更点

実装の手順は以下の 4 つ。

(a) 通知の名前を文字列定数として定義する。
(b) 通知を送るオブジェクトで、通知を送るコードを追加する。
(c) 通知を受けるオブジェクトで、通知を処理するメソッド(通知ハンドラ)を定義する。
(d) 通知を受けるオブジェクトで、監視の登録のためのコードを追加する。
(e) 通知を受けるオブジェクトで、監視の登録解除のためのコードを追加する。

(a) はどこで定義しても構わないが、(b) と同じく通知を送るオブジェクトと一緒に定義する方が良いだろう。通知を受けるオブジェクトでは、送るオブジェクト(のクラス)のインタフェース部を #import することになる。

MacBloggerGlass の場合、通知を送るのが PreferenceController で、受けるのが AppController になる。

(b) の通知を送るタイミングは、環境設定パネルで「Save」ボタンが押されたとき。つまり、ボタンに対応するアクションメソッド内になる。

監視の登録 (d) については、少なくとも最初に環境設定パネルが開くより前でなければならない。確実なのは AppController が作られたときだ。AppController はアプリの MainMenu.xib にインスタンスとして登録されているから、アプリが起動した後は NIB がロードされる中で生成(というか復元)される。このタイミングは awakeFromNib で拾うことができる。一般にアプリの起動時に生成(初期化)されるオブジェクトなら init で登録すれば良い(ヒレガス本 Chapter 14 の例はこちらになっている)。また、登録の解除 (e) は dealloc で行う(これはヒレガス本の例と同じ)

実装

PreferenceController

インタフェース部: PreferenceController.h

追加したのは 1 行。クラスのインタフェースにふくまれるものではないので @interface {...} の外側に置かなければならない。こういう定数が増えたら、定数だけを独立させて別ファイルにすべきかも。

extern NSString * const MBGBlogIDChangeNotification;

実装部: PreferenceController.m

ヒレガス本からそのまま引き写し。

- (IBAction)saveSettings:(id)sender
{
    [...snip...]
    // send notification
    NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
    NSDictionary *userInfo = [NSDictionary dictionaryWithObject:selectedBlog.blogID forKey:@"blogID"];
    [nc postNotificationName:MBGBlogIDChangeNotification
                      object:self
                    userInfo:userInfo];
    NSLog(@"Post notification with userInfo (%@)", userInfo);

    [self close];
}

AppController

実装部: AppController.m

通知ハンドラ handleBlogIDChange: は AppController.m だけから参照できる AppController のプライベートメソッドとした(ファイルローカルメソッドと呼ぶべきか？)。これについては荻原(2.0)本の「CHAPTER 09 カテゴリ」を参照のこと。

fetchPosts は GData クライアントライブラリを使って記事のフィードをリクエストするもの。これまで getFeed: というアクションメソッドの一部だったものを今回独立させた。これは、getFeed: と通知ハンドラの両方から呼べるようにするため。もっとも、今回の変更にあわせて、メインウィンドウから Blog ID を入力するフィールドと記事一覧を取得するためのボタンを取り除いたため、getFeed: は無用になってしまったが。

@interface AppController (PrivateMethods)
- (GDataServiceBase *)bloggerService;
- (void)fetchPosts;
- (void)renderHTML:(NSString *)content withBaseURL:(NSString *)baseURL;
- (void)handleBlogIDChange:(NSNotification *)note;
@end

@implementation AppController
[...snip...]
- (void)awakeFromNib
{
    NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
    [nc addObserver:self selector:@selector(handleBlogIDChange:) name:MBGBlogIDChangeNotification object:nil];
}
@end

@implementation AppController (PrivateMethods)
[...snip...]
- (void)handleBlogIDChange:(NSNotification *)note
{
    NSLog(@"Received notification: %@", note);
    blogID = [[note userInfo] objectForKey:@"blogID"];

    [posts removeAllObjects];
    [self fetchPosts];
}
@end

プロトタイプ #0

右のスクリーンショットが今の MacBloggerGlass でこのブログを表示させた様子だ。NSSplitView を使い、上半分で記事一覧、下半分でその内容を表示させている。記事の表示には WebView に対して、取得した記事のフィードのコンテンツをただ文字列として流し込んでいるだけ。つまり、HTML としてきちんとしたドキュメントの構造になっていないし、もちろんスタイルシートや JavaScript も付いていない。ま、GData クライアントライブラリを使った RSS リーダのサンプルアプリといったところか。

今回のプロトタイプでは Blog ID の選択を環境設定に押し込めている。これは、ブログは高々 1 つしか見ることはないし、Blog ID を切り替える頻度は高くない、と想定したから。実際に動かしてみて思うことは、複数のブログを作っているなら他のブログも同時に見たいと思うかもしれない、ということ。つまりは、ブラウザのようにタブやウィンドウで複数のコンテンツを同時に開ける方が良いかもしれない。

ま、それは 1 つのブログをきちんと表示できるようになってから考えよう。せめて、GAE 版と同等の表示ができるようにしてからだ。

おまけ

予告(→「次は NSNotification に取り組む」)では「通知」に関連するドキュメントも探すと書いたが、時間切れで本当に探すだけになってしまった。まだ読めていない。リンクだけは「関連リンク」のところに挙げておく。

また、「通知」に関して書かれたドキュメントを検索していて便利そうなものを見つけた。Devpedia シリーズとでも呼べば良いのかな(URL の一部になっている)。右のスクリーンショットはそれを Safari で開いたところだ。

何が便利かと言うと、たとえば「Cocoa Core Competencies」なら、Cocoa アプリを作るために必要になるさまざまなトピックを一覧できること。また、それぞれについての簡単な説明(使い方をふくむ)が付いていて、より詳しいドキュメントへのリンクもある。ヒレガス本のように、アプリの作り方を順を追って説明するようなタイプのものではないが、実際にアプリを作るときにドキュメントを参照する出発点として役に立ちそう。

検索して見つかったのは以下の 3 つ。

参考文献

詳解 Objective-C 2.0

荻原剛志
ソフトバンククリエイティブ ( 2008-05-28 )
ISBN: 9784797346800

物読みファイル (別館)で詳細を見る

MediaMarker

Cocoa Programming for Mac OS X

Aaron Hillegass
Addison-Wesley Professional ( 2008-05-15 )
ISBN: 9780321503619

物読みファイル (別館)で詳細を見る

MediaMarker

次は NSNotification に取り組む - 環境設定パネルを作る #3 (MacBloggerGlass)

2010-12-01T23:37:00.002+09:00

今回は明日の作業の予告だけ。

MacBloggerGlass の環境設定パネルについて「設定の保存にまつわる問題」で挙げた 3 つの問題は、NSTableView の選択を Cocoa Bindings でモデルと結びつける方法がわかったことですべて解決できた。明日は、本筋の環境パネルの実装に戻ることにする。

以前に挙げた「ざっくり手順」(→「表示するブログの選択 - 環境設定パネルを作る (MacBloggerGlass)」を参照)で言えば、残りは「User Defaults の値を参照するように、メインンアプリのコードを変更する」になる。

とは言っても、単純にメインウィンドウのアクション(右のスクリーンショットの Read ボタン)に組み込むことは難しくない。アクションメソッドの冒頭でテキストフィールドから読み取っている Blog ID を User Defaults から読むだけ。

今ある動作確認用の一時コードは以下のようになっている(Blog ID を入力するフィールドは削除する予定だから、以下はあくまで環境設定パネルの動作確認用)。

- (IBAction)getFeed:(id)sender
{
    blogID = [blogIdField stringValue];
    if ([blogID length] == 0) {
        NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
        blogID = [defaults objectForKey:MBGSelectedBlogID];
    }
    NSLog(@"Blog ID: %@", blogID);
    [...snip...]
}

これだけで「メインアプリのコードを変更する」ことが完了なら、もう終わっていることになる。もちろん、これだけではない。環境設定パネルで表示するブログを選択(変更)し「Save」ボタンを押したときに何が起きるべきかを考えてみよう。

ユーザは表示するブログを変更するために環境設定パネルを開く。その中でブログを変更したなら、アプリウィンドウに戻ってきたときに何を期待するだろうか？もう一度「Read」ボタンを押そうと思うだろうか？ユーザが環境設定パネルで「Save」ボタンを押したときの期待は (a) パネル内の変更が User Defaults として保存されること、(b) その変更がアプリに直ちに反映されること、の 2 つのはずだ。

そこで NSNotification の出番となる(ヒレガス本の Chapter 14 の内容)。これは、言わばアプリ内のオブジェクト間通信で、あらかじめ取り決めた名前を媒介にして、あるオブジェクトから別のオブジェクトに情報を送る仕組みだ。

MacBloggerGlass の場合で言えば、PreferenceController から saveSettings: の中で通知を送り、それを AppController が受け取ることになる。通知には任意のオブジェクトを同封できるため、新しい Blog ID を (NSString) として付ければ良い。受け取った側では、送られてきた Blog ID が表示中のものと変わっていたら、記事一覧を新たに取得する、となる。

明日は、コードの実装に加えて、関連するドキュメントも探すつもり。

twitter より (2010-11-30)

2010-12-01T07:34:00.002+09:00

23:48 ペーパークラフト、すげえ (；゜д゜) → http://jp.makezine.com/blog/2010/11/papercraft_battleship.html

Cocoa Bindings の使い方 #3 - 選択を結びつける

2010-11-30T23:20:00.000+09:00

前回の記事で(→「設定の保存にまつわる問題 - 環境設定パネルを作る (MacBloggerGlass)」)、環境設定パネルの表示状態を保存・復元するためには、表部分の選択もモデルとして保持しなければならない、と書いた。

そこで、今回の内容は、NSTableView で選択されるべき行をモデルに格納する方法。もちろん、両者を結びつけるには Cocoa Bindings を使う。

まず、考えるべきは表の選択(に関する情報)を、Cocoa Bindings ではどう扱えば良いのか？表 (NSTableView) とモデルを結びつけているのは NSArrayController だ。ならば、選択のための結びつきも NSArrayController で用意されているはず。

NSArrayController の Selection Indexes

NSArrayController の「Bindings」パネルを見てみると、それらしい項目が見つかる。それが「Selection Indexes」だ。右のスクリーンショットは「Selection Indexes」を開いたところ。この例では結びつける先は「File's Owner」(この NIB をロードするオブジェクト)の selectionIndex というプロパティになっている。

さて、これで選択のための結びつきを作れることはわかった。次の問題は選択を表現するデータの型は何かということ。NSTableView で選択された行は selectedRow メソッドで取り出すことができるが、この型は NSInteger で、これはつまり int だ。では、上記の結びつきの先となるプロパティは int (あるいは NSInteger) で良いのか？

Interface Builder 上で Selection Indexes のところにマウスを持っていき、しばらくじっとしているとツールチップが表示される。そこには NSIndexSet のインスタンスが選択された行を指定すると書かれている。もっと詳しく知りたければ「Cocoa Bindings Reference」の NSArrayController > Controller Content Parameters Bindings > selectionIndexes を見ること。

サンプルコード

NSTableView の選択を Cocoa Bindings を使ってモデルと結びつける実例として、MacBloggerGlass の環境設定パネルを実現するコードからの抜粋を示す。

まず、モデルとしての NSIndexSet は PreferenceController オブジェクトに抱えさせている。プロパティ名は先のスクリーンショットにも出ていたように selectionIndex だ。

PreferenceController の実装で selectionIndex にアクセスするのは(解放する dealloc を除いて) 3 ヶ所。

プロパティとしてのアクセサ(readonly)
windowDidLoad 内でインスタンスの確保と初期化(空選択として)
ブログ一覧を取得した際に実行される blogListTicket:finishedWithFeed:error で User Defaults に保存された選択の復元

NSIndexSet にはインスタンス生成用のクラスメソッドが用意されていて、空選択の場合には +indexSet を用いる。

保存された選択の復元を行うコードを以下に示す。

処理の内容は、(a) User Defaults から「選択された Blog ID」を取り出し、(b) ブログ一覧の各項目の ID と比較し、(c) 一致するものが見つかれば、(d) それを選択する、となっている。

- (void)blogListTicket:(GDataServiceTicket *)ticket
      finishedWithFeed:(GDataFeedBlog *)aFeed
                 error:(NSError *)error
{
    [...snip...]
    // selectedIndex
    NSString *blogID = [self selectedBlogID]; // ........................ (a)
    int index = 0;
    EntryBlog *entry;
    for (entry in feed.entries) {
        if ([entry.blogID compare:blogID] == NSOrderedSame) break; // ... (b)
        index++;
    }
    if (index < [feed.entries count]) { // ........................... (c)
        [self willChangeValueForKey:@"selectionIndex"];
        [selectionIndex initWithIndex:index]; // ........................ (d)
        [self didChangeValueForKey:@"selectionIndex"];
    } else {
        [selectionIndex init]; // empty NSIndexSet
    }
}

(d) の前後にある willChangeValueForKey: と didChangeValueForKey は KVO の通知を送るためのお作法の 1 つ(→「表示するブログの選択 - 環境設定パネルを作る (MacBloggerGlass)」を参照)。

今さらなんだけど、NSString って == で(文字列としての)比較はできないのな。Ruby や Python に慣れていると、つい == で比較してしまうよ。

設定の保存にまつわる問題 - 環境設定パネルを作る #2 (MacBloggerGlass)

2010-11-29T22:40:00.003+09:00

設定を User Defaults に書き込むことは難しくない。設定値が NSString であるならなおさらだ。PreferenceController の実装部に以下のようなコードを埋め込むだけだ。

    NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
    NSString *accountID = [accountField stringValue];
    [defaults setObject:accountID forKey:@"AccountID"];

また参照する側 (AppController) では、以下のようにすれば良い。

    blogID = [blogIdField stringValue];
    if ([blogID length] == 0) {
        NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
        blogID = [defaults objectForKey:@"blogID"];
    }

今回の記事の内容は、設定を保存するコードではなく、設定の保存を中心としたユーザ体験上の問題について。

UI が提供するユーザ体験は、実際に動かしてみると、デザイン段階での「あら」があちこちに浮かび上がってくる。環境設定パネルでもアプリ本体とつないで見ると、いくつかの不備が見えてきた。今日、「Save」ボタンの機能を実装してみて、(そして動かしてみて)以下の 3 点について気付いた。

パスワードを User Defaults に保存するのはマズい。
「Save」ボタンを押した後のフィードバックがない。
ブログのリストと選択の状態が保存、復元されない。

設定を保存すると ~/Library/Preferences に置かれるファイルに書き込まれる。テキスト形式は言うに及ばず、バイナリ形式にしても、そこにパスワードを平文で書き込むのはマズい。パスワードを保存する場合には、キーチェーンと連携させるのが Mac アプリの作法だろう。とりあえず、パスワードは保存の対象から外しておく。キーチェーンとの連携は棚上げ。

アプリを使う際にさまざまな処理の結果がユーザに対して適切にフィードバックされるかどうかはユーザ体験に大きく影響する。「ボタンを押す」というユーザのアクションに対してユーザの目に見える反応が何も起こらないと、ユーザに不安を感じさせることになる。ありがちなフィードバックとしては「完了しましたダイアログ」を出すことだが、これは使いどころを間違えると、ただわずらわしいだけになる。

今回の環境設定パネルの場合、「Save」が押されたらパネル自体を消すというのが良いように思う。現状ではこのパネルの役割はアプリのメインウィンドウで表示するブログの選択のみだ。そこで「Save」ボタンが押されたのだから、保存処理が完了したのなら何も仕事は残っていない。だから、パネルを消せば処理が(成功のうちに)完了したことは十分に伝わるし、(わずらわしいダイアログのような)余分な UI も増えない。

今、悩んでいるのは、最後の環境設定パネルを(設定を保存し)一度閉じて再び開いたときに、元の状態を復元させる仕組みだ。必要な情報はブログ(タイトル)の一覧と選択された項目へのインデックス。ここで、問題が 2 つほど出てくる。

1 つは、「ブログ(タイトル)の一覧の保存」に関係する。前回の記事(→「表示するブログの選択」)で書いたように、環境設定パネル(右図)の表部分 (NSTableView) は、Cocoa Bindings によって(NSObjectController と NSArrayController を介して)モデルのプロパティに結びついている。表に出てくる項目は EntryBlog のプロパティであり、これを保存することは EntryBlog を保存することになる。Cocoa Bindings で結びついている以上、ブログのタイトルだけを NSStrings を抱えた NSMutableArray として保存しても意味はない。

そう、1 つ目の問題は環境設定パネルにとってのモデルである FeedBlog と EntryBlog の保存(永続化)の仕組みが必要だ、というものだ。

2 つ目の問題は、選択の状態をどうやって復元するか、というもの。何度も書いているようにパネルの表(ビュー)は Cocoa Bindings によってモデルと結びついている。だから、その選択の状態も Cocoa Bindings でどこかの何かと結びつけなければならない。Interface Builder で NSTableView の Bindings パネルを開くと Selection Indexes という「結びつき」を設定する項目がある。これを使えば選択の状態を Cocoa Bindings による結びつきで伝えられそうなんだが、問題はそれを「どこ」の「何」というプロパティにするか。

保存すべき情報という意味でこれもモデルの一部と言える。FeedBlog の一部にすることもできるが、抽象化の障壁に穴を空けてしまうようでイヤな感じだ。別のモデルオブジェクトとして独立させた方が良い。と言っても、情報自体は整数値 1 つなので、実際には PreferenceController に int のプロパティを増やすことになるか。

次回は表項目の「選択」のための結びつきを Cocoa Bindings で作ることを試してみよう。

まあ、ユーザ体験うんぬん以前に、ウィンドウの UI を考えるときに状態の保存と復元について考えていないのがそもそも悪い。経験不足だと切って捨ててしまえばそれまでだけど、Cocoa Bindings を使ってモデルとビューを同期させることに注意が引きつけられていたせいもあるだろう。

表示するブログの選択 - 環境設定パネルを作る (MacBloggerGlass)

表示するブログの選択 - 環境設定パネルを作る #1 (MacBloggerGlass)

2010-11-28T22:40:00.003+09:00

GAE 版 Blogger Glass では表示するブログの Blog ID を config.yaml という設定ファイルで指定するようになっている。また、実行時にユーザが(Google アカウント)でログインすることで、ユーザごとに Blog ID を指定できるように「Settings」画面も用意した(→「GAE アプリでユーザごとの設定を可能にする #5」)。

Mac 版では表示するブログの選択は「環境設定パネル(Preferences)」を開いて行う。GAE 版のように Blog ID を直接指定するのはメンドウなので、Google アカウントの ID をパスワードを入力することで、そのアカウントで作ったブログの一覧から選べるようにしたい。

今回は、そんな「環境設定パネル」でブログ一覧を取得し、表示するところまでを作り込む。

環境設定パネルを追加する

Cocoa アプリに対する「環境設定パネル」の設置手順は「ヒレガス本」の Chapter 12 〜 14 の内容となる。

ざっくり手順を並べると以下のようになる。

「環境設定パネル」を制御するコントローラを、NSWindowController を継承して作る。
適当な場所(AppContoller みたいなものを作っていればそこ)に「環境設定パネル」を表示させるアクションを作る。
Interface Builder でメインメニューのメニュー項目(「アプリ名」>「Preferences...」)に「環境設定パネル」を表示させるアクションを接続する。
「環境設定パネル」用の NIB ファイルを作る(実際には XIB ファイル)。この NIB の File's Owner は「環境設定パネル」を制御するコントローラにする。
Interface Builder でパネルを作る。
「環境設定パネル」を制御するコントローラに、パネルで使うアクション等を作り込む。
「環境設定パネル」の設定を User Defaults に書き込むようにする。
User Defaults の値を参照するように、メインのアプリウィンドウのコードを変更する。

今回の記事の内容は、このうちの 6. までとなっている。7. と 8. は次回に持ち越し。

デザイン (意匠)

環境設定パネルの外観と簡単な使い方を以下に示す。

MacBloggerGlass ウィンドウデザイン
環境設定パネル

Google Account の ID (E-mailアドレス) とパスワードを入力し「Get Blog List」を押すと、下部の Blog for viewing にその Google アカウントで Blogger に作ったブログのタイトル一覧が現れる。アプリで表示させたいブログを選択し、「Save」ボタンを押して保存する。パネルを閉じるには左上のクローズボタンを押すか、ESC キーを叩く。

デザイン (設計)

Google アカウントの ID とパスワードを入力させて、ブログの一覧を取得するという機能は、GData ライブラリのパッケージにふくまれている Blogger 用サンプルにほぼそのままの形で作り込まれている。それをのまま流用しても良かったが(実際、GData を使った Google Data API へのアクセスの部分は流用している)、ここでは Cocoa Bindings を使ってみたい。つまり、「環境設定パネル」のコントローラ(PreferenceController クラスとした)を NSTableView のデータソースとするのではなく、モデルとなるオブジェクトを NSObjectController (あるいはその派生クラスたち)を介して、NSTableView と結びつけるようにしたい、ということ。

後述するように、モデルは、ブログごとの情報を抱えるオブジェクトと、その配列を抱えるオブジェクトの二段構えになっている。これは、Google Data API を経由してユーザのブログ一覧を取得した際に、GData ライブラリが生成するオブジェクトの構成をそのまま写し取ったものだ。

(GData ライブラリによるブログ一覧)
+---------------+
| GDataFeedBlog |
|---------------|            +----------------+
|- entries    --|----------->| GDataEntryBlog |
|  ...          | 1        * |----------------|
|               |            |  ...           |
+---------------+            +----------------+

GDataEntryBlog は個々のブログの ID やらタイトルやらといった情報を保持している。

この二段構えのモデル構造は以前の記事(→「Cocoa Bindings の使い方」)でダミーとして作ったモデルの構造と同じだ。あのサンプルアプリでは、二段構えモデルに対応するため、Cocoa Bindings のためのコントローラも NSObjectController と NSArrayController の二段構えとした。その構成をそのまま、今回の「環境設定パネル」でも用いる。

実装

モデル

モデルクラスは 2 つ。FeedBlog クラスは GData ライブラリが提供する GDataFeedBlog に対応するもので、EntryBlog クラスは同じく GDataEntryBlog に対応するものだ。どちらも対応する GData ライブラリのクラスを内部に抱える(has-a の関係)とともに、ビューで表示するための情報を抽出するためのクラスとして作った。抽出した情報(例: ブログのタイトル)は、主にビューから Cocoa Bindings の結びつきを介してアクセスするために用いる。

どちらのクラスにも、対応する GData ライブラリのオブジェクトをセットするためのメソッドを用意していて、そこで情報の抽出も行っている。

FeedBlog

//
//  FeedBlog.h
//  MacBloggerGlass

#import <Cocoa/Cocoa.h>
@class GDataFeedBlog;

@interface FeedBlog : NSObject {
    NSMutableArray *entries;
    GDataFeedBlog *gDataFeed;
}

@property (readonly) NSMutableArray *entries;
@property (readwrite, retain) GDataFeedBlog *gDataFeed;

@end

//
//  FeedBlog.m
//  MacBloggerGlass

#import "GData/GDataBlogger.h"
#import "FeedBlog.h"
#import "EntryBlog.h"

@implementation FeedBlog
- (id)init
{
    [super init];
    entries = [[NSMutableArray alloc] init];
    return self;
}

- (void)dealloc
{
    [gDataFeed release];
    [entries release];
    [super dealloc];
}

@synthesize entries;
@synthesize gDataFeed;
- (void)setGDataFeed:(GDataFeedBlog *)aFeed
{
    if (aFeed == gDataFeed) return;
    [gDataFeed release];
    gDataFeed = [aFeed retain];

    [entries removeAllObjects];

    EntryBlog *blog;
    GDataEntryBlog *entry;
    for (entry in [gDataFeed entries]) {
        blog = [[EntryBlog alloc] init];
        blog.gDataEntry = entry;        
        [entries addObject:blog];
    }
    NSLog(@"%d blogs was found.", [entries count]);
}
@end

setGDataFeed: で GDataFeedBlog の抱える配列から GDataEntryBlog の要素を取り出している for (var in array) { ... } という書き方が Objective-C 2.0 から導入された高速列挙 (fast enumeration) だ。Ruby や Python ではお馴染みのもの。配列の添字でループし、objectAtIndex: で配列にアクセスするよりもスッキリと書ける。array の部分には配列(NSArray)以外の集合(NSSet)や辞書(NSDictionary)も指定できる。詳しくは荻原(2.0)本 CHAPTER 08 の p.202 〜 206 あたりを参照のこと。

EntryBlog

//
//  EntryBlog.h
//  MacBloggerGlass

#import <Cocoa/Cocoa.h>
@class GDataEntryBlog;

@interface EntryBlog : NSObject {
    NSString *title;
    NSString *blogID;
    GDataEntryBlog *gDataEntry;
}

@property (readonly) NSString *title, *blogID;
@property (readwrite, retain) GDataEntryBlog *gDataEntry;

@end

//
//  EntryBlog.m
//  MacBloggerGlass

#import "GData/GDataBlogger.h"
#import "EntryBlog.h"

@interface EntryBlog (PrivateMethods)
- (NSString *)extractBlogID:(NSString *)identifier;
@end


@implementation EntryBlog
- (void)dealloc
{
    [gDataEntry release];
    [blogID release];
    [title release];
    [super dealloc];
}

@synthesize title, blogID;
@synthesize gDataEntry;
- (void)setGDataEntry:(GDataEntryBlog *)aEntry
{
    if (aEntry == gDataEntry) return;
    [gDataEntry release];
    gDataEntry = [aEntry retain];

    title = [[[gDataEntry title] stringValue] retain];
    blogID = [[self extractBlogID:[gDataEntry identifier]] retain];
}
@end

@implementation EntryBlog (PrivateMethods)

#pragma mark -
#pragma mark PrivateMethods
- (NSString *)extractBlogID:(NSString *)identifier
{
    if (!identifier || [identifier length] == 0) return nil;

    // GDataEntryBlog.identifier is in the format
    // "tag:blogger.com,1999:user-<user id>.blog-<blog id>"
    NSRange rangeBlog = [identifier rangeOfString:@"blog-"];
    int startPos = rangeBlog.location + rangeBlog.length;

    return [identifier substringFromIndex:startPos];
}

@end

EntryBlog.m の方で @interface EntryBlog (PrivateMethods) ... @end として宣言しているのは、このファイルからのみ参照するためのメソッドの定義だ。C でいう static 関数のようなもの。カテゴリの使い方の 1 つ。これも詳しくは荻原(2.0)本 CHAPTER 09 の p.227 〜 228 を参照のこと。

コントローラ

先に述べたように Cocoa Bindings のためのコントローラには NSObjectController と NSArrayController の 2 つを組み合わせて使う。左のスクリーンショットで Feed Observer となっているものが NSObjectController (のインスタンス)、Array Observer となっているものが NSArrayController (のインスタンス) だ。インスタンス名を Observer としているのは、どちらも KVO (Key-Value Observing) のため(だけ)に使っているからだ。

PreferenceController

環境設定パネルを表示するためのクラスで、NSWindowController を継承している。

GData を使ってブログ一覧を取得する部分は以前の記事(→「記事一覧を取得する」)で示したものとほとんど同じなので省略する。

以下に示すのは、ブログ一覧を取得するために GData ライブラリのサービスを呼び出した際に指定するコールバックメソッドだ。注意してほしいのは 102 と 104 行目。これは、KVO でキーに対応する変更通知を発行するための「作法」の 1 つ。103 行目で、feed が保持するオブジェクト(前述の FeedBlog のインスタンス)が抱える配列の内容が変更される。そのことを、PreferenceController に(「feed」というキーで)結びついているオブジェクト(今回の場合、それは Feed Observer という名前の NSObjectController のインスタンス)に通知している。

- (void)blogListTicket:(GDataServiceTicket *)ticket
      finishedWithFeed:(GDataFeedBlog *)aFeed
                 error:(NSError *)error
{
    if (error) {
        NSLog(@"ERROR in fetching the blog list: %@", error);
        return;
    }
    [self willChangeValueForKey:@"feed"];
    feed.gDataFeed = aFeed;
    [self didChangeValueForKey:@"feed"];
}

監視するオブジェクトの変更通知を受け取った Feed Observer (NSObjectController) は、今度は自分自身に(「entries」というキーで)結びついているオブジェクト(Array Observer という名前の NSArrayController のインスタンス)に変更通知を送る。それを受け取った Array Observer は、NSTableView (の中の NSTableColumn) に変更通知を送る。NSTableView は KVC によって結びついたオブジェクトのプロパティ(EntryBlog の title)を取得して、表示を更新する。このようにして、モデルの変更が Cocoa Bindings によって結びついたビューに伝播してゆくのだ。

次の展開

ブログ一覧を取得して表示できるようになっているが、まだ肝心の「Save」ボタンが機能しない。当然、メインウィンドウ(アプリ本体)とも連携していない。現段階では環境設定のためのパネルが単独で動いているだけ。

なので、次は「Save」ボタン(に対応するアクション)の実装と、アプリ本体とのつなぎ部分を実装することになる。

参考文献

詳解 Objective-C 2.0

荻原剛志
ソフトバンククリエイティブ ( 2008-05-28 )
ISBN: 9784797346800

物読みファイル (別館)で詳細を見る

MediaMarker

Cocoa Programming for Mac OS X

Aaron Hillegass
Addison-Wesley Professional ( 2008-05-15 )
ISBN: 9780321503619

物読みファイル (別館)で詳細を見る

MediaMarker

Cocoa Touch では Cocoa Bindings は使えない

2010-11-27T22:37:00.000+09:00

「Interface Builder User Guide: Connections and Bindings」は「About Connections and Bindings」という節で始まっている。その冒頭では Mac OS X (と iOS) アプリで用いる「接続(connection)」の型についての説明がされている。

(「Interface Builder User Guide: Connections and Bindings」より)
There are four fundamental types of connections you can create in a Mac OS X and iOS application:

Outlet connections

Action connections (Mac OS X only)

Event connections (iOS only)

Bindings (Mac OS X only)

action と event がそれぞれ、Mac OS X 専用、iOS 専用となっているのは良い。iOS アプリで action の代わりを務めるのが event だから。気になるのは最後の Bindings が Mac OS X 専用となっていること。そう、Cocoa Bindings は iOS アプリでは使えない技術なのだ(少なくとも今のところ)。

Interface Builder で Inspector を見てみる

前回の記事(→「Cocoa Bindings の使い方 #2」)で、Cocoa Bindings を設定するための Bindings パネルのスクリーンショットを載せた。このパネルは Interface Builder でインスタンスのさまざまな設定を行うための「Inspector」とツールの一部として表示されるものだ(「Inspector」は Interface Builder のメニューから「Tools」>「Inspector」で表示できる)。この「Inspector」の中には、他にも Attributes や Size を設定するためのパネルが並んでいる。

この「Inspector」を Cocoa アプリの部品と Cocoa Touch の部品でそれぞれ表示させ、そこに並んでいるパネルの数と種類を比べてみた。改めて見ると、確かに違う。Cocoa の部品のパネルに比べて、Cocoa Touch の部品のそれは明らかに数が少ない。

Interface Builder が Inspector に表示するパネル数の差
Cocoa の Table View (NSTableView)

パネルは左から順に、Attributes、Effects、Size、Bindings、Connections、Identity となっている。
Cocoa Touch の Table View (UITableView)

パネルは左から順に、Attributes、Connections、Size、、Identity となっている。

設定するためのパネルがない以上、Cocoa Touch の部品では(つまり iOS アプリでは) Cocoa Bindings が使えないことは確かなようだ。

Cocoa アプリと Cocoa Touch アプリ

以前の記事(→「欲しいのはオフライン機能 - Cocoa アプリとして作り直す #0」)で、Mac 版と iPhone アプリでなるべく設計と実装を共通化したいと書いた。そのためにも、ビュー (V) とモデル (M) の分離が明確になる Cocoa Bindings はおもしろそうだと調べ始めたんだが、Cocoa Touch で使えないとは思わなかった (´・ω・｀)。まあ、iPhone アプリのコントローラ (C) が少し大きくなる程度の差で済むと思うがね。

この制約はどうしてだろう？パフォーマンス？メモリ？ KVC と KVO は iOS アプリでも使えるっぽいんだけどな(iOS Reference Library に両者の Programming Guide がある)。そう言えば、ガベージコレクションも iOS アプリでは使えないんだった。デバイスに差がある(あり過ぎる)以上、しかたがないんだろうな。

どうでもいいことだけど garbage collection のカタカナ表記としては「ガベージコレクション」と「ガーベジコレクション」のどちらが適切か？ググってみると前者は 130,000 件で後者が 67,100 件。ま、根拠にするには弱いけど、どちらかと言えば前者の方がポピュラーってことか。

twitter より (2010-11-26)

2010-11-27T07:33:00.002+09:00

20:01 とりあえず、ミウラを手に入れるまではガンバロ。15億、貯めるのはキツいけど。ミウラでニュルをドライブするのが今回の目標だな。 → http://www.gran-turismo.com/jp/news/d11077.html

Cocoa Bindings の使い方 #2 - Interface Builder 編

2010-11-26T23:23:00.002+09:00

前回の記事(→「Cocoa Bindings の使い方」)では、Cocoa Bindings を使うことで、MVC のうち M (モデル) となるコードを書くだけでアプリが作れると書いた(標準部品とその振る舞いだけを使うアプリの場合)。ただし、その設定には Interface Builder に対する慣れが必要だ、とも書いた。

今回は、Interface Builder を使って Cocoa Bindings を設定する手順について書く。ネタ元は公式ドキュメント(Mac OS X Reference Library)の「Interface Builder User Guide」にある「Connections and Bindings」だ。

ヒレガス本の Chapter 8 でも、NSTableView を NSArrayController に結びつける手順が説明されている。サンプルアプリを作る手順をたどるハンズオンの資料としてはわかりやすいが、ツールについての説明が必要最小限にとどめられているため、自分でアプリを作ろうとすると情報が不足していることに気付く。上記のドキュメントはその足りない部分を補完してくれる。

「結びつき(Binding)」を作る

「Connections and Bindings」の説明用に貼られているパネルのスクリーンショットは、(説明に使う)一部だけを開いてあるためダマされてしまうが、このパネルには似たような設定項目を持つセクションがいくつも並んでいる。

たとえば、右のスクリーンショットは、前回の記事で紹介したサンプルアプリの設定をしたときのものだが、複数のセクション(「Availability」とか「Controller Content Parameters」とか)に、右向きの三角が付いた項目がいくつもあることがわかる(「Availability」に「Editable」、「Content Controller Parameter」には「Filter Predicate」や「Selection Indexes」)。この右向き三角を開くとそれぞれに「Content Array」に表示されているのと同様な設定(「Bind to:」、「Controller Key」や「Model KeyPath」など)がある。

それぞれのセクションや項目がどういった「結びつき」を作るためのものなのかを知らないと、うっかり他の項目に「結びつき」を作ってしまうことになりかねない(前回のサンプルアプリでは実際そういう間違いをしてしまった)。これらの項目はオブジェクトのクラスによって変わるため、それぞれの項目がどういう振る舞いのためのものかは個別のクラスのリファレンスを参照するしかないようだ。一方で、それぞれの項目に対する設定のうち共通なものについては、「Connections and Bindings」の Table 7-1 に「Common binding attributes」としてまとめられている。

どの項目であれ、最低限、設定しなければならないのは「Bind to:」と「Model Key Path」の 2 つ。右のスクリーンショットでは、それぞれ Feed Controller、entries となっているものだ(この例では結びつける相手が NSObjectController のため「Controller Key」も指定している)。

「Bind to:」は文字通り、どのオブジェクトに結びつけるかを指定するもので、ドロップダウンリストを開くと Interface Builder のドキュメントウィンドウ(左のスクリーンショット)にあるオブジェクトの一覧が出る。先の例ではこの中の Feed Controller が選ばれている。

前回の記事に書いたとおり、このサンプルアプリでは NSArrayController が制御する配列(NSMutableArray)は別のコントローラ(NSObjectController のインスタンスで Feed Controller という名前にしてある)が制御するモデルオブジェクトが抱えるものだ。この配列に対する結びつきを指定しているのがこのパネルでの設定になる。

一方、Feed Controller 側と(配列を抱える)モデルオブジェクトとの結びつきも Interface Builder で設定している。右のスクリーンショットがその設定となる。ただ、こちらの設定は Cocoa Bindings とは異なり、NSObjectController が直接モデルオブジェクトを持つための設定だ(と思う)。ただ、そのアクセスに KVC が使われている。

「結びつき」のパターン

「Connections and Bindings」では、結びつきのタイプを以下の 3 つのパターンに分類している。

Binding Directory to the Value (値に直接結びつける) [Figure 7-6]
Binding Through an Intermediate Object (中間オブジェクトを介して結びつける)
Binding to a Collection Objects (オブジェクトの集まりに結びつける) [Figure 7-9]

「中間オブジェクト」パターンについては、さらに 2 つに分けている。

Binding through another data object (別のデータオブジェクトを介して結びつける) [Figure 7-7]
Binding through an object controller (別のコントローラを介して結びつける) [Figure 7-8]

この分類にしたがえば、前回のサンプルアプリは、「別のコントローラを介して結びつける」と「オブジェクトの集まりに結びつける」の複合方式ということになる。

まとめ

前回のサンプルアプリはヒレガス本の手順を真似て、さらに「結びつき」を作るための試行錯誤を繰り返して作った。そうして動くモノができたものの、すっきりしない感じが残った。そのモヤモヤが「Connections and Bindings」を読むことで氷解した。とはいえ、最初にこのドキュメントに取り組んでいたとしても、すんなりと理解はできなかったに違いない。試行錯誤の後だからこその理解だと思う。

馴染みの薄い概念がふくまれていると、ドキュメントを読んでも表面的な理解で終わってしまう。そこが難しいところだよね。

ちなみに、この記事では「バインディング」「バインドする」とカタカナ表記で書くのが嫌で「結びつき」とか「結びつける」と書いてみた。Lisp 界隈で bind の訳語として定着している「束縛」を使わなかったのは、以前からなんというか語感が堅いと感じていたから。

ま、自分では、脳内で「bind」に変換して読んでいるんだから、どっちでも良いんだがね。他の人はどう感じるかな (・ω・)？

参考文献

Cocoa Programming for Mac OS X

Aaron Hillegass
Addison-Wesley Professional ( 2008-05-15 )
ISBN: 9780321503619

物読みファイル (別館)で詳細を見る

MediaMarker

Cocoa Bindings の使い方

2010-11-25T23:58:00.006+09:00

追記@2010-11-30

Cocoa Bindings の使い方については以下の後続記事も参照のこと。

ブログの記事一覧を表示するようなアプリでは、記事一覧のデータは、配列(のような何か)に蓄えることになるし、画面の表示は表形式(に似た何か)を使うことになるだろう。

Cocoa アプリでこれをシンプルに実現すると、配列 (NSMutableArray) に蓄えられたデータをテーブルビュー (NSTableView) に表示するものになる。MVC アーキテクチャで言うなら、配列がモデル(正確には配列に蓄えられたオブジェクトがモデル)で、テーブルビューが(その名の通り)ビューになる。

NSTableView にデータを表示させる場合、二通りの方法がある。1 つは、NSTableView のデータソースとなるクラスを定義する方法。具体的には、AppController というようなクラスを定義し(MVC の C)、そこで以下の 3 つのメソッドを定義するというもの。

- numberOfRowsInTableView:
- tableView:objectValueForTableColumn:row:
- tableView:setObjectValue:forTableColumn:row:

3 つ目のメソッドは表示のみのアプリなら必要ない。

この方法の欠点は、NSMutableArray の内容を NSTableView における表示と同期させるコードは、どれも良く似ているものになることだ。

良く似たものになるなら、その仕組みを共通化してフレームワークが提供してくれればありがたい。もちろん、そのためにはある種の「抽象化」が必要になり、利用に際しては一定の「作法」に従わなければならない。この「共通化された仕組み」が Cocoa Bindings であり、「抽象化」が KVC (Key-Value Coding)、「作法」が KVO (Key-Value Observing) ということになる。

サンプルアプリ

今回、サンプルとして作ったアプリのスクショがこれ(→)だ。機能的には(意匠的にも)ヒレガス本の Chapter 8 で作るもの(→ 「MVC と Cocoaバインディング」参照)と同等だが、こちらは、コードとして書いたのはモデルとなる 2 つのクラスのみで、ビューは当然として、コントローラも Cocoa フレームワークの提供するものだけで作られている。

モデル

まずはモデルを構成する 2 つのクラスを示す。これら 2 つは、Atom 形式のフィードから生成することを想定したものだ。Feed オブジェクトが Entry オブジェクトの配列を抱えるようになっている。

Entry の定義

//  Entry.h
#import <Cocoa/Cocoa.h>

@interface Entry : NSObject {
    NSString *title;
    NSDate *updated;
}

@property (readwrite, retain) NSString *title;
@property (readwrite, retain) NSDate *updated;

@end

//  Entry.m
#import "Entry.h"

@implementation Entry
- (id)init
{
    [super init];
    title = @"Hi!";
    updated = [[NSDate date] retain];
    return self;
}

- (void)dealloc
{
    [updated release];
    [title release];
    [super dealloc];
}

@synthesize title, updated;

- (void)setTitle:(NSString *)newTitle
{
    if (newTitle == title) return;
    [title release];
    title = [newTitle retain];
    self.updated = [[NSDate date] retain];
}

@end

Feed の定義

//  Feed.h
#import <Cocoa/Cocoa.h>

@interface Feed : NSObject {
    NSString *title;
    NSDate *updated;
    NSMutableArray *entries;
    int count;
}

@property (readwrite, retain) NSString *title;
@property (readwrite, retain) NSDate *updated;
@property (readwrite, retain) NSMutableArray *entries;
@property (readwrite) int count;


@end

//  Feed.m
#import "Feed.h"
#import "Entry.h"

@implementation Feed
- (id)init
{
    [super init];
    title = @"My Feed";
    updated = [[NSDate date] retain];
    entries = [[NSMutableArray alloc] init];
    [entries addObject:[[Entry alloc] init]];
    count = [entries count];
    return self;
}

- (void)dealloc
{
    [entries release];
    [updated release];
    [title release];
    [super dealloc];
}

@synthesize title, updated, entries;

- (void)setEntries:(NSMutableArray *)newArray
{
    if (newArray == entries) return;
    [entries release];
    entries = [newArray retain];
    self.count = [entries count];
}

@synthesize count;
@end

コントローラ

コントローラには NSObjectController と NSArrayController を 1 つずつ使っている。これらのコントローラは Interface Builder から NIB (今は XIB)ファイルの中にインスタンス化し、設定を変更しているだけだ。コードは一切、書いていない。

これらコントローラの設定で肝となるのは、それぞれのコントローラが保持することになるモデルクラスとの対応づけだ。NSObjectController は上述のFeed クラスのオブジェクトを保持する。NSArrayController は Entry クラスのオブジェクトを生成し(Add ボタンのアクション)、消滅させる(Delete ボタンのアクション)。ただし、Entry オブジェクトたちを保持するのは Feed が抱えた配列だ。このため、NSArrayController は Feed オブジェクトに対して要素となる Entry オブジェクトの追加、編集、削除を指示する必要がある。このとき用いられるのが Cocoa Bindings だ。

NSArrayController は配列を抱えた NSObjectController にバインドされることになる。

ビュー

スクショを見ればわかるように、いくつかのテキストフィールド(いずれも編集不可にしてある)とテーブルビュー(タイトル欄のみ編集可)、および 2 つのボタンから構成されている。いずれも Cocoa フレームワーク標準のビューたちだ。

テキストフィールドおよびテーブルビュー(のセル)は、Cocoa Bindings によって、2 つのコントローラのプロパティを経由してモデルと結びつけられている。このため、モデル(のプロパティ)が変更されれば、KVO の通知により自動的に変更がビューに反映されることになり、ビューによる変更はコントローラを経由してモデルに反映されるようになっている。

まとめ

MVC のうちモデルとなるクラスを書くだけで後は、Interface Builder の操作でアプリが作れてしまう。標準の部品(ビューとコントローラ)を使うアプリであれば簡単にできる。ただし、Interface Builder を使って Cocoa Bindings の設定するのには、ちょっと慣れが必要だ。似たような設定項目が多く、設定する場所を間違えたら、まったく動かない。今日もそれでかなり苦労した。

参考文献

詳解 Objective-C 2.0

荻原剛志
ソフトバンククリエイティブ ( 2008-05-28 )
ISBN: 9784797346800

物読みファイル (別館)で詳細を見る

MediaMarker

Cocoa Programming for Mac OS X

Aaron Hillegass
Addison-Wesley Professional ( 2008-05-15 )
ISBN: 9780321503619

物読みファイル (別館)で詳細を見る

MediaMarker

twitter より (2010-11-24)

2010-11-25T07:34:00.002+09:00

16:23 そうか。何気なくアップデートしたけど、tv は iOS デバイスでありながら母艦を必要としないんだ。 → http://ipodtouchlab.com/2010/11/apple-tv-os41.html
16:31 インタラクティブっていうのはデジタルコンテンツの得意とするところだものな。電子書籍もこっちの方向に進むかね。ただ、子どもに使わせるなら今の iPad はちょっと重すぎるだろう。 → http://bit.ly/gMJsry

日付文字列の変換 - RFC3339 から NSDate へ

2010-11-24T22:34:00.003+09:00

実装

まずは、今回作った Objective-C による実装から示す。関数の機能は単純で、RFC3399 形式で表現された日時を元に NSDate のオブジェクトを生成する。関数内で NSDate オブジェクトを alloc しているが、返す前に autorelease しているため、荻原(2.0)本 (p.96) で言う「一時的なオブジェクト」となっている。また、関数を呼び出す側で自動解放プールを用意する必要がある。通常の Cocoa アプリの場合は、NSApplication がイベントループの管理とともに自動解放プールも用意してくれる(→ 「荻原(2.0)本」p.98)。

この実装では NSString の機能のうち、以下のメソッドを多用している。

- (NSRange)rangeOfCharacterFromSet:(NSCharacterSet*)aSet: aSet で渡された文字集合中の文字が最初に見つかった場所を返す。
- (NSString*)substringToIndex:(NSUInteger)aIndex: 先頭から位置 aIndex までの部分文字列を返す。
- (NSString*)substringWithRange:(NSRange)aRange: aRange.location を開始位置とし、aRange.length を長さとする部分文字列を返す。
- (NSString*)substringFromIndex:(NSUInteger): aIndex を開始位置としする末尾までの部分文字列を返す。

上記の substring...の戻り値はいずれも一時的なオブジェクトになっている。

参照仕様

GData API の Protocl Reference によれば、各種日付には RFC3339 フォーマットが使われる、とある。これは GData API が使うデータフォーマット(Atom 形式; RFC 4287 で定義されている)の仕様によるものだ。

(「RFC 4287」より)
A Date construct is an element whose content MUST conform to the "date-time" production in [RFC3339]. In addition, an uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset.

[...snip...]

Example Date constructs:
<updated>2003-12-13T18:30:02Z</updated>
<updated>2003-12-13T18:30:02.25Z</updated>
<updated>2003-12-13T18:30:02+01:00</updated>
<updated>2003-12-13T18:30:02.25+01:00</updated>

上記の中で例として挙げられている 4 つのパターンを見れば書式のおよそは理解できる。

より詳細な書式の定義は RFC 3339 にある。

date-fullyear   = 4DIGIT
date-month      = 2DIGIT  ; 01-12
date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                          ; month/year
time-hour       = 2DIGIT  ; 00-23
time-minute     = 2DIGIT  ; 00-59
time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                          ; rules
time-secfrac    = "." 1*DIGIT
time-numoffset  = ("+" / "-") time-hour ":" time-minute
time-offset     = "Z" / time-numoffset

partial-time    = time-hour ":" time-minute ":" time-second
                  [time-secfrac]
full-date       = date-fullyear "-" date-month "-" date-mday
full-time       = partial-time time-offset

date-time       = full-date "T" full-time

この定義から、日時の表現は「日付」と「時刻」に二分され、その区切りが文字「T」であること、また「時刻」は「時刻本体」と「時差」に分かれることが読みとれる。

「時差」については、時刻による差分で表現したもの(「+09:00」や「-5:00」など)か、あるいは文字「Z」を用いる(時差として文字「Z」を指定した場合、その時刻は UTC を意味する)。

さらに「時刻本体」の表現については、「時」「分」「秒」をそれぞれ 2 桁の十進数で表現する(1 桁の場合は先頭に「0」を付加する)。また「秒」については 1 秒以下を小数表現で「秒」に付けても良い、となっている。

GData API での時刻の取扱い

実際に GData API が返すフィードを見ると、updated 要素等は以下のようになっていて、確かに上記の書式に従っていることがわかる。

<published>2010-10-03T21:18:00.000+09:00</published>
<updated>2010-10-03T21:18:00.840+09:00</updated>

一方、GData Objective-C Library が返す時刻データは GDataDateTime クラスのインスタンスになっていて、そこから文字列データを取り出すと RFC3339 フォーマットの文字列となる。ただし、それを作る部分は以下のようになっているため、「秒数」の小数点以下が無視されている(GData Objective-C Client ver. 1.10.0)。これは、Cocoa の NSDateComponents が小数点以下の秒数をサポートしていないことによるものだと思われる(以下のコード中の dateComponents は NSDateComponents のインスタンスを保持している)。

- (NSString *)stringValue {
  return [self RFC3339String];
}

- (NSString *)RFC3339String {
  NSDateComponents *dateComponents = [self dateComponents];
  NSInteger offset = [self offsetSeconds];

  NSString *timeString = @""; // timeString like "T15:10:46-08:00"

  if ([self hasTime]) {

    NSString *timeOffsetString; // timeOffsetString like "-08:00"

    if ([self isUniversalTime]) {
     timeOffsetString = @"Z";
    } else if (offset == NSUndefinedDateComponent) {
      // unknown offset is rendered as -00:00 per
      // http://www.ietf.org/rfc/rfc3339.txt section 4.3
      timeOffsetString = @"-00:00";
    } else {
      NSString *sign = @"+";
      if (offset < 0) {
        sign = @"-";
        offset = -offset;
      }
      timeOffsetString = [NSString stringWithFormat:@"%@%02ld:%02ld",
        sign, (long)(offset/(60*60)) % 24, (long)(offset / 60) % 60];
    }
    timeString = [NSString stringWithFormat:@"T%02ld:%02ld:%0l2d%@",
      (long)[dateComponents hour], (long)[dateComponents minute],
      (long)[dateComponents second], timeOffsetString];
  }

  // full dateString like "2006-11-17T15:10:46-08:00"
  NSString *dateString = [NSString stringWithFormat:@"%04ld-%02ld-%02ld%@",
    (long)[dateComponents year], (long)[dateComponents month],
    (long)[dateComponents day], timeString];

  return dateString;
}

おまけ

最初に挙げたプログラムを Xcode で Command Line Tool としてビルドし、実行するとコンソールには以下のように出力される。水平線で区切られた 4 行が、testGetDateObject の一回の呼び出しによるもので、最初が引数として与えられた RFC3339 形式の日時文字列、2 行目が getDateObject による変換結果(の NSDate のインスタンス)、3 行目がそのインスタンスをデフォルトのタイムゾーン(ウチではもちろん JST)で評価した結果、最後の 4 行目は同インスタンスを UTC で評価した結果となっている。

2010-11-24 22:06:14.819 ExpApp[24929:a0b] ----------------------------------------
2010-11-24 22:06:14.821 ExpApp[24929:a0b] RFC3339 Format: 2010-11-22T12:34:56Z
2010-11-24 22:06:14.824 ExpApp[24929:a0b] NSDate object: 2010-11-22 21:34:56 +0900
2010-11-24 22:06:14.824 ExpApp[24929:a0b] Default TZ: 2010-11-22 21:34:56 +0900
2010-11-24 22:06:14.825 ExpApp[24929:a0b] UTC: 2010-11-22 12:34:56 +0000
2010-11-24 22:06:14.825 ExpApp[24929:a0b] ----------------------------------------
2010-11-24 22:06:14.825 ExpApp[24929:a0b] RFC3339 Format: 2010-11-22t12:34:56z
2010-11-24 22:06:14.826 ExpApp[24929:a0b] NSDate object: 2010-11-22 21:34:56 +0900
2010-11-24 22:06:14.826 ExpApp[24929:a0b] Default TZ: 2010-11-22 21:34:56 +0900
2010-11-24 22:06:14.826 ExpApp[24929:a0b] UTC: 2010-11-22 12:34:56 +0000
2010-11-24 22:06:14.827 ExpApp[24929:a0b] ----------------------------------------
2010-11-24 22:06:14.827 ExpApp[24929:a0b] RFC3339 Format: 2010-11-22T12:34:56.123Z
2010-11-24 22:06:14.827 ExpApp[24929:a0b] NSDate object: 2010-11-22 21:34:56 +0900
2010-11-24 22:06:14.828 ExpApp[24929:a0b] Default TZ: 2010-11-22 21:34:56 +0900
2010-11-24 22:06:14.828 ExpApp[24929:a0b] UTC: 2010-11-22 12:34:56 +0000
2010-11-24 22:06:14.828 ExpApp[24929:a0b] ----------------------------------------
2010-11-24 22:06:14.829 ExpApp[24929:a0b] RFC3339 Format: 2010-11-22t12:34:56.123z
2010-11-24 22:06:14.829 ExpApp[24929:a0b] NSDate object: 2010-11-22 21:34:56 +0900
2010-11-24 22:06:14.829 ExpApp[24929:a0b] Default TZ: 2010-11-22 21:34:56 +0900
2010-11-24 22:06:14.830 ExpApp[24929:a0b] UTC: 2010-11-22 12:34:56 +0000
2010-11-24 22:06:14.830 ExpApp[24929:a0b] ----------------------------------------
2010-11-24 22:06:14.830 ExpApp[24929:a0b] RFC3339 Format: 2010-11-22T12:34:56+09:00
2010-11-24 22:06:14.831 ExpApp[24929:a0b] NSDate object: 2010-11-22 12:34:56 +0900
2010-11-24 22:06:14.831 ExpApp[24929:a0b] Default TZ: 2010-11-22 12:34:56 +0900
2010-11-24 22:06:14.832 ExpApp[24929:a0b] UTC: 2010-11-22 03:34:56 +0000
2010-11-24 22:06:14.832 ExpApp[24929:a0b] ----------------------------------------
2010-11-24 22:06:14.832 ExpApp[24929:a0b] RFC3339 Format: 2010-11-22t12:34:56+09:00
2010-11-24 22:06:14.833 ExpApp[24929:a0b] NSDate object: 2010-11-22 12:34:56 +0900
2010-11-24 22:06:14.833 ExpApp[24929:a0b] Default TZ: 2010-11-22 12:34:56 +0900
2010-11-24 22:06:14.834 ExpApp[24929:a0b] UTC: 2010-11-22 03:34:56 +0000
2010-11-24 22:06:14.834 ExpApp[24929:a0b] ----------------------------------------
2010-11-24 22:06:14.834 ExpApp[24929:a0b] RFC3339 Format: 2010-11-22T12:34:56.123+09:00
2010-11-24 22:06:14.835 ExpApp[24929:a0b] NSDate object: 2010-11-22 12:34:56 +0900
2010-11-24 22:06:14.836 ExpApp[24929:a0b] Default TZ: 2010-11-22 12:34:56 +0900
2010-11-24 22:06:14.836 ExpApp[24929:a0b] UTC: 2010-11-22 03:34:56 +0000
2010-11-24 22:06:14.836 ExpApp[24929:a0b] ----------------------------------------
2010-11-24 22:06:14.837 ExpApp[24929:a0b] RFC3339 Format: 2010-11-22t12.34.56.123+09:00
2010-11-24 22:06:14.837 ExpApp[24929:a0b] NSDate object: 2010-11-22 12:34:56 +0900
2010-11-24 22:06:14.838 ExpApp[24929:a0b] Default TZ: 2010-11-22 12:34:56 +0900
2010-11-24 22:06:14.838 ExpApp[24929:a0b] UTC: 2010-11-22 03:34:56 +0000
2010-11-24 22:06:14.838 ExpApp[24929:a0b] ----------------------------------------
2010-11-24 22:06:14.839 ExpApp[24929:a0b] RFC3339 Format: 2010-11-22T12:34:56-05:00
2010-11-24 22:06:14.839 ExpApp[24929:a0b] NSDate object: 2010-11-23 02:34:56 +0900
2010-11-24 22:06:14.839 ExpApp[24929:a0b] Default TZ: 2010-11-23 02:34:56 +0900
2010-11-24 22:06:14.840 ExpApp[24929:a0b] UTC: 2010-11-22 17:34:56 +0000
2010-11-24 22:06:14.840 ExpApp[24929:a0b] ----------------------------------------
2010-11-24 22:06:14.840 ExpApp[24929:a0b] RFC3339 Format: 2010-11-22T12:34:56.123-05:00
2010-11-24 22:06:14.841 ExpApp[24929:a0b] NSDate object: 2010-11-23 02:34:56 +0900
2010-11-24 22:06:14.841 ExpApp[24929:a0b] Default TZ: 2010-11-23 02:34:56 +0900
2010-11-24 22:06:14.842 ExpApp[24929:a0b] UTC: 2010-11-22 17:34:56 +0000

参考文献

詳解 Objective-C 2.0

荻原剛志
ソフトバンククリエイティブ ( 2008-05-28 )
ISBN: 9784797346800

物読みファイル (別館)で詳細を見る

MediaMarker

lifeLOG + REPOsitory

twitter より (2011-11-18)

twitter より (2011-11-07)

twitter より (2011-10-26)

Lion アップデート (10.7.1 → 10.7.2)

関連記事

twitter より (2011-08-25)

Lion アップデート (10.7 → 10.7.1)

関連記事

twitter より (2011-08-10)

twitter より (2011-07-29)

twitter より (2011-07-26)

twitter より (2011-07-21)

twitter より (2011-06-09)

twitter より (2011-06-08)

twitter より (2011-06-04)

twitter より (2011-05-30)

twitter より (2011-05-16)

twitter より (2011-05-15)

twitter より (2011-04-27)

twitter より (2011-03-31)

Snow Leopard アップデート (10.6.6 → 10.6.7)

iMac & MacBook

Mac mini Server

カーネルバージョン

関連リンク

関連記事

twitter より (2011-01-20)

数学で犯罪を解決する ([著]キース・デブリン, ゲーリー・ローデン, [版]ダイヤモンド社)

数学なしには暮らせない

数学は魔術？

数学とはパターンを見つける方法

数学を知らなくても暮らせる

参考文献

関連リンク

オフライン機能の実現 #6 (MacBloggerGlass)

解決の方針

関連記事

Snow Leopard アップデート (10.6.5 → 10.6.6)

iMac & MacBook

Mac mini Server

カーネルバージョン

関連リンク

関連記事

最終定理 ([著]アーサー・C・クラーク, フレデリック・ポール, [版]早川書房)

2 つの物語

SF らしさ

クラークと言うよりはポールの作品

不満は……

参考文献

関連リンク

関連記事

ZSH のパス設定

答えは ~/.zshenv

~/.zshenv を読むより前に起きていること

関連リンク

関連記事

NSTableView でソートしたとき、選択された要素をモデル配列から正しく取り出す方法

NStableView と NSArrayController の関係

iOS アプリではどうする？

関連リンク

関連記事

進捗状況を表示する (MacBloggerGlass)

フィードバックの方法

タイマを使った遅延実行

遅延実行を使った進捗メッセージの表示

フィードの取得開始と完了を通知する

実装: 進捗メッセージの表示

まとめ

参考文献

関連リンク

関連記事

PasswordManager の導入 - 非公開ブログの記事を取得する (MacBloggerGlass)

関連記事

ラベルによる記事の抽出 - ラベル検索の実装 #3 (MacBloggerGlass)

Feed にクエリを指定して Entry を絞り込む

NSInvocation を使った Query の実現

Cocoa 版 BloggerGlass の完成

関連リンク

関連記事