|
|
|
|
|
|
|
HMDT - Back Number / August, 2002 |
August, 2002
macinbasic.info さん経由で知ったけど、MacCentral に Apple が Rendezvous をオープンソースとして公開する、っていうインタビュー記事が載っているよ。 Rendezvous が公開されること自体は、Apple の開発者用の Rendezvous のページに載っていた。Jaguar が公開されたら、Rendezvous のコードも公開するかんね、って書かれている。 さて、公開、公開っていうけど、何を公開するんだ？今回のインタビュー記事と Apple のページによれば、「mDNS Responder の実装」を公開するらしい。これは何？ こないだの「Rendezvous について」によれば、Rendezvous こと ZeroConf のための主要技術は 2 つ。Self-assigned link-local addressing と、Multicast DNS だ。mDNS は、後者の Multicast DNS のことだ。ちなみに Self-assigned link-local addressing は、Mac OS 8.5 の時代から実装されているらしい。 じゃ、Multicast DNS って何？調べてみた。これが Multicast DNS のページ。その説明によると、IETF の ZeroConf グループと、DNS Extensions とが共同で提案したものらしい。つまり、ZeroConf のために新しく作られたプロトコルなわけね。ちなみに仕様書のドラフトはここ（Performing DNS queries via IP Multicast）。 と、いうわけで、そのうち Rendezvous こと ZeroConf networking で必要になる、Multicast DNS の Mac OS X 上での実装が公開されるらしい、ということでした。Darwin の一部として公開されるみたい。興味ある人は期待して待つといいんではないでしょうか。たとえば、Rendezvous 対応のプリタンを作りたい人とか。たとえば、Windows 上で Rendezvous を実装したい人とか。
Jaguar の新機能をとりあえず触ってみるこのシリーズ、今回は AddressBook framework だ。 Jaguar で AddressBook が一新されたのは、ご存じの通り。じつは、アドレスブックっていうアプリケーションが変わっただけではなくて、アドレスを管理するデータベースが追加されて、その API も公開されたんだ。Apple のドキュメントはこちら。Cocoa API と Carbon API が用意されている。使い方は、Foundation に慣れている人ならとっても簡単だ。 と、いうわけで、とりあえず名前と名字を取得するサンプルを作ってみた。ものすごく簡単だけど、よかったらどうぞ。 サンプルコード AddressBook.framework を使うアプリケーションの例は、Apple のアドレスブックより高機能なものを作るか、またはシンプルで使い勝手がいいものを作るか、ってのがあるよね。たとえばメールアドレスに特化したメールアドレスブックとか。作り方によっては面白いかも。
Jaguar の目玉の 1 つ、Rendezvous だ！Rendezvous は大きくとりあげられているけど、「何ができるの？」「どういう仕組みなの？」ってことが、以外と分からない。たとえば、システム環境設定の共有を見ると、「Rendezvous 名」って欄があるけど、これは何？とか。 ということで、Apple のドキュメント、About Redezvous を訳してみた。Rendezvous が目指すもの、そのために必要な技術について分かりやすく書いてあるぜ。デベロッパの人も、そうでない人にもお勧めの文章だ。 簡単に要約すると、Rendezvous の利点は、
を提供すること。そのために、
を使う、ってことだ。具体的なシナリオは、ドキュメントをどうぞー。
Mac OS X 10.2 の Foundation では、NSPropertyListSerialization ってのが追加されたよ。早速使ってみたぜ！ こいつは、Property List を NSData に serialize したり、また戻したりするクラスだ。注目すべきは、バイナリで保存することがサポートされたこと。バイナリの利点は、テキストに比べてデータ量が小さくなること。 実際に比べてみよう。テキストで約 12 KB の Property List を、NSPropertyListSerialization のバイナリ形式と、NSArchiver を使った形式とで保存してみた。
というわけで、1/4 ぐらいのサイズになった。NSArchiver よりも若干小さい。てなわけで、Property List のサイズが大きくなって困ってた人にお勧めです。いるのか、そういう人？ サンプルコード
Jaguar が来たよーん。いいじゃん、いいじゃん。よくできてるよ。10.1 の成熟バージョンって感じだね。PowerBook で使っているけど、液晶での表示がきれいになったのがいちばんうれしい。 Project Builder も完成度上がってきてるし。
ずっと Randezvous って書いてたけど、Rendezvous だったのね。恥っ。 Google で調べてみた。Randezvous は 1,280 件。Rendezvous は 600,000 件。あぁ、わたしが間違っていました。ごめんなさい。
来るべき 10.2 に備えて、Rendezvous についてちょっと調べてみた。とりあえず、主要な情報のリンクを。
Rendezvous、あえて一言でいってしまえば、「AppleTalk の代替品」ってことでいいと思う。TCP/IP によるネットワークが、IP アドレスや DNS サーバがいるのに対して、AppleTalk はそれらの設定がいらない。この使いやすさを目指したものだ。 これって、例えば SCSI と FireWire の関係に似ている。SCSI は ID を設定する必要があったけど、FireWire はいらないでしょう？これは FireWire では、新しい機器がつながったとき、ID を自動的に割り振るからだ（ノード ID の自動設定って呼ばれる）。 ユーザにとっては便利。技術の発展の方向としては正しい。欠点は、技術的敷居が高くなること。プロトコルが複雑になって、コストも高くなる。FireWire（IEEE1394）より USB が普及したのも、これが原因。 さて、Rendezvous と Zero Configuration は、どの辺に落としどころを見つけているのかな？
計算機アルゴリズ研究に多大な足跡を残す、Dijkstra が亡くなりました。ご冥福をお祈りします。 初期の計算機科学の先人達が亡くなるころなんですね。ハードは速くなり、PC も一般に普及したけど、もう 10 年以上ソフトウェアには大きなブレークスルーはない。われわれががんばらないと。
長々とやってたポスト Finder の話。今回でようやくおしまいだ。全部読んでくれた人、ありがとう。すきの多い議論なので、異論反論は山ほどあると思うので、そのへんは是非。 ポスト Finder はやっぱり Navigator てなわけで、iMovie と iPhoto と iTunes を見てきたわけだ。これらのアプリケーションでファイルの取り扱いに共通するのは、
ということ。これはひとことでいうと、「ファイルシステムの隠蔽」っていうことが見えるんだ。ファイルをどこに保存するか？目的のファイルは、ファイルシステムのどこにあるか？などということは、ユーザが気にする必要はない。それはアプリケーションが処理してくれるんだ。そもそも、ユーザがやりたいことは目的のファイルを探すことで、ファイルシステムの中をさまようことじゃないよね。 さてさて、この傾向はなにも iApplication だけではないでしょう。Finder にも移ってくるのではないか？このさき、ハードディスクの容量が増えれば、どんどんファイル数は増えて複雑になっていく。そもそも、UNIX ベースの Mac OS X になった時点で、訳の分からないファイルが増えたしね。ただ単に、目的のファイルを探して、それを読んだり編集したいだけのユーザにとって、Finder によるファイルシステムのブラウズは、余計なものが多すぎる。求められるものは、Finder（のぞき窓）によるファイルシステム探索ではなくて、目的のファイルを訊ねることができる Navigator だ。 （あぁ、Navigator！この甘美な言葉の響き！Knowledge Navigator のコンセプトビデオ以来、Mac ユーザは Navigator にしばられ続けているのだ） こんな場面を想像してみよう。Mac を立ち上げると、Finder の代わりに 1 つのアプリケーションが立ち上がる。アプリケーションには、女性の顔が写し出されている（男性でもいいけど）。彼女に対して、必要なファイルを要求する。「えっとさぁ、きのう編集していたワードのファイルで、明日のミーティングの資料のやつ。それ開いて。あと、バックで音楽かけておいて。U2 のやつ。順番は適当で。」すると、女性はにっこり笑って消え、ワードが開かれて、音楽がかかる。そして、あなたは編集を始める、、、 陳腐だって？ありがちだって？うん、たしかに書いてて恥ずかしかったぞ。別に、Navigator が人の顔を持っている必要はないんだよね。自然言語を理解する必要もない。ただ、イメージとして捉えやすいかな、と思ってあげてみただけ。ポイントは、必要なファイルを探すのに、ファイルシステムの中を探すんじゃなくて、アプリケーションに質問して（クエリーを送って）、選んでもらう、ってことだ。クエリーには、いくつかのポイントがある。ファイルのタイプ、編集した日付け、MP3 ファイルだったらアーティストの名前、などなど。 Navigator のための技術的バックグラウンドは、iApplication に学べるんだ。たとえば、ファイルの保存場所をアプリケーションに決めさせるとか。これでファイルの検索が、ぐっとやりやすくなる。ほかにもブラウズの仕方とか、見るべきところは多い。これからポイントになるのは、クエリーをどうやって設定するか、っていうところでしょう。 Navigator っていうのは新しい概念じゃないけど、これから確実に必要になるはずだ。Apple は iApplication で、その片鱗を見せてくれた。ぜひ、その概念を押し進めて、Finder にとって変わる OS の新しい顔として育ててほしいと思うんだよ。 （この項終わり）
iTunes のアプローチ とうぜん、最後は iTunes のアプローチだよ。現在、最も完成に近付いたといえる iApplication だ。ごぞんじ、CD をリッピングして MP3 にするアプリケーションね。iPod との連係もあるし。 じゃ、iTunes を立ち上げるところから。iTunes もシングルウィンドウアプリケーションだ。いきなりウィンドウが 1 つ開いて、すべての操作はそこで行われる。ウィンドウのオーバーラップはなし。左側の入力源のところには、ライブラリが 1 つある。 iTunes の最初の仕事は、CD からの音楽の取り込み。CD を挿入すれば、iTunes のウィンドウに出てくる。それをライブラリにドラッグしてやれば、取り込みが始まる。エンコードされた MP3 ファイルは、勝手に保存される。 で、取り込んだらファイルのブラウズ。右側に、ブラウズのためのカラムビューが表示されてるよね。基本的にアーティスト、そしてそのアルバムっていう順序で絞り込んでいくんだ。 別のブラウズのしかたもある。1 つは検索。検索ウィンドウに単語を入れてやれば、串刺しで検索できるんだ。他にはプレイリストを作る方法。自分の好きな曲を選択して、リストを作ってやる。 さらに iTunes3 では、スマートプレイリストが加わった。これは、ファイルを直接指定するんじゃなくて、アーティスト名とか、再生した回数とかで条件を付けて、それに合う曲を集めてくる、動的なプレイリストだ。 といったところで、iTunes のファイル管理のやりかたをまとめてみよう。まず、ファイルの取り込みは、他の iApplication と同じ。対象となる CD をしてやれば、勝手に取り込み始める。そして自分でフォルダを作ってそこにいれる。また、曲に附随する情報は、MP3 ファイルのタグという形で保存されるんだ。 ファイルのブラウズには、バリエーションがある。アーティストとアルバム名による絞り込み。串刺し検索。プレイリスト。そしてスマートプレイリスト。もちろん、ぜんぶ一気に表示も可能。 もう、目的のファイルが、ディスクのどこにあるか？なんてことにはとらわれてないね。手がかりとなる情報をもとに（アーティスト名や、曲名や、最近使ったかどうか）、目的となるファイルへまっしぐらだ。 （この項続く）
iPhoto のアプローチ 続いては、iPhoto のアプローチ。iPhoto はデジカメ用の写真管理アプリケーション。写真の管理とブラウズがメインだ。 まずは iPhoto を立ち上げてみよう。そうするとウィンドウが 1 つ開き、ここですべての作業をすることになる。いわゆるシングルウィンドウアプリケーション。ウィンドウの左側がアルバムの管理で、右側が写真の表示になってるね。 次にやることは写真の取り込み。デジカメから写真を取り込むんだ。これも、つなげるだけで始まる。そして写真は勝手に保存されるんだ。 そうすると、右側に写真が表示される。iPhoto の最大の特徴は、この写真の表示。すべての写真が一気に表示される、もう、Apple のエンジニアがやけになったのか、写真を生涯で 64 枚しか撮らないと決めてたのかよく知らんけど、そういうインタフェースになってるんだ。 これだけではあまりにあまりなので、別の表示方法もある。1 つはフィルムロール表示。これは写真の取り込みセッションごとにわけて表示するもの。もう 1 つはアルバム表示。これは自分の好きな写真を選んで、アルバムとして表示するものだ。 んじゃ、iPhoto のファイル管理コンセプトを見てみよう。まず、iMovie と似てるんだけど、デジカメをつなぐと写真を取り込んで、適当に名前をつけて、保存する。保存する場所は、iPhoto が決めるんだけど、これは撮影した日付けごとにディレクトリにわけられるんだ。たとえば、2002/07/15/IMG-0224.JPG って感じにね。 そして、アルバム表示では自分の好きな写真だけを集めることができる。ただし、オリジナルのファイルの位置は変わらない。実際にどうやって管理しているかっていうと、アルバムごとにディレクトリを作って、そこにエイリアスを入れているんだ。 ということで、iPhoto で見られるアプローチは次の通り。まず、ファイルの取り込み。ファイルを取り込んだら、しかるべき情報を付加して保存する。ここでは撮影日付け情報をディレクトリの形で付加して、他の情報もその下に別のファイルとして保存しているんだ。そして、それをブラウズするときは、そのディレクトリ構造にとらわれない。基本的には、一気に全部表示する。自分で好きなものを集めることもできるけど、オリジナルのファイルは動かさない、ってやり方だ。 ふむふむ。なんか iApplication のファイルの取り扱い方が見えてきたかも？ ちなみに、iPhoto のファイルの管理については、MacWire での荻窪圭さんの記事がやたらと詳しいです。 （この項続く）
こっからは、iApplication たちが、どうやってファイルを取り扱っているのか見ていくよ。それは「ファイルの取込み」と「ファイルのブラウズ」の 2 つに分かれる。 iMovie のアプローチ お気楽ムービー編集ソフト iMovie。これは DV (Digital Video) の映像をとりこんで、編集するためのアプリケーションだよね。ここでは、DV から取り込んで、編集を始める状態にするまでに注目する。 ところで、このソフトはのっけから Finder との協調を否定しているんだ。なにせ、全画面表示ソフトなんだもん。iMovie を起動すると画面がすべて iMovie のウィンドウで覆われて（通常のウィンドウとは違い、タイトルバーとかはない）、もちろん Finder は見えなくなる。この動作は Windows 系のアプリケーションに近いね。 で、起動すると、新規のプロジェクトを作るか、プロジェクトを開くかを迫られる。つまり、iMovie 動作中は、常になんらかのプロジェクトを開いていることになる。プロジェクト無しはだめ。うーむ。 新規プロジェクトを作ったら、DV から編集素材を取り込むことになる。これは、DV をつなぐと勝手にやってくれる。取り込まれたムービーは、適切なところでクリップに（これも勝手に）切られ、画面右側にプレビューとともに表示される。 あとは、クリップを切ったり貼ったりして、ムービーを編集していくんだ。 さて、ここまでのところを振り返ってみよう。まず、iMovie は取り込んだクリップをどうしているのか？DV をつないでムービーを取り込むと、いくつかのクリップに分割される。このクリップには、iMovie が名前を付けて（クリップ 1 とか）、プロジェクトの下のフォルダにファイルとして iMovie が保存することになる。ユーザは関知しない（またはできない）。 そして、取り込まれたファイル（クリップ）は、プレビューとともに、iMovie のウィンドウの中に表示される。表示される位置は、ユーザが好きに変えることができる。 まとめると、ユーザがやるのは DV をつなぐことと、ファイルをブラウズすることだけ。ファイルの保存場所を指定したり、ファイルに名前をつけたり、それらをオープンしたり、っていう作業はすべて iMovie まかせになっているんだ。 どう？楽でしょ？それとも、なんか気に食わないなぁー、って思う？ （この項続く）
話を戻して、CFXML で遊ぶ話。XML には TreeViewer っていうデモアプリケーションがあるけど、それと同じようなサンプルを、CFXML と Cocoa を使って作ってみた。
このアプリケーションは、XML ファイルをパースして、木構造で表示するプログラム。遊びなので、エラー処理とか細かいところは入ってないけど、とりあえず動いた。 もちろん、Mac OS X なら、Java の XML 環境は動かせる。そっちの方が Apple の XML よりも信頼性があるでしょう。でもやっぱり、Objective-C から使える CoreFoundation は気軽だよなぁ。Java に比べて、アプリケーションの起動も速いし。 ダウンロード
|
|
Home | Link | Download | Back Number | Speciall Issue
|
