MOSA Multi-OS Software Artists

MOSAはソフトウェア開発者を支援します

  • iPhone/iPod touch アプリ紹介
  • MOSA掲示板
  • 活動履歴
  • About MOSA(English)

MOSA Developer News［MOSADeN＝モサ伝］第190号

2006-01-24

目次

  • 「WebObjects Dev Report」　　　　第36回　　田畑 英和
  • 小池邦人の「Carbon API 徒然草」
  • SqueakではじめるSmalltalk入門　　第54回　　鷲見 正人
  • ニュース・解説　　　　　　　　　　　　　　 木下 誠

「WebObjects Dev Report」　　第36回　　田畑 英和

　今回はユーザ情報の閲覧について解説します。閲覧機能では、ユーザが登録した様々な情報を表示することができ、閲覧画面の表示にはDirectActionを使用しています。

・閲覧のURL
/cgi-bin/WebObjects/MOSAJobMatch.woa/wa/browse

　このURLにアクセスするとユーザの一覧が表示されます。DirectActionを使用する場合、表示する画面の作り方に注意する必要があります。セッションを使わないためにDirectActionを使用していても、表示する画面の作り方によっては自動的にセッションが生成されてしまいます。具体的には、セッションを必要とするDynamicElementやクラスを使用した場合にセッションが自動的に生成されます。

　例えば、ユーザの一覧を表示するためにWODisplayGroupを使ったとしましょう。WODisplayGroupを使用すれば変数を追加して、WebObjects Builder上でパラメータを設定するだけでユーザの一覧を表示することができます。このとき、WebObjects Builder上で次のような設定を行います。

・Display Group Option
Entity：MOSAUser
Fetches on load：On
Fetch Spec：PublicUsers

　モデルについて少し補足しておきますと、”MOSAUser”は3種類存在するユーザ用Entityの親Entityです。つまりWODisplayGroupのEntityに”MOSAUser”を指定することによって、すべてのユーザをFetchすることができます。
　ですが、ユーザは自分の情報を登録するときに、情報を公開するかどうかを設定できます。そこでFetch Specを指定することにより、情報を公開しているユーザだけをFetchするようにします。WODisplayGroupで指定するFetch Specは、あらかじめモデルに定義しておきます。モデルには”PublicUsers”という名前でFetch Specを作成しておき、このとき次のようなQualifierを設定します。

・Fetch Spec “PublicUsers”に設定したQualifier
(mosaUserdata.scope = 1)

　”mosaUserdata”はユーザデータEntityへのリレーション名であり、ユーザデータの”scope”の値によって、情報を公開するかどうかを切り分けています。
　そしてFetches on loadをOnにしておくことにより、画面を表示したときに自動的にデータベースからデータをFetchすることができます。
　これでユーザの一覧が表示できるようになるわけですが、先ほどの話に戻ります。WODisplayGroupクラスを用いた場合、内部的にセッションがもつデフォルトのEditingContextが必要になり、自動的にセッションが生成されてしまいます。これではせっかくDirectActionを用いてユーザの一覧を表示するようにしても、ユーザの一覧を表示するためにセッションが生成されてしまいます。本当にセッションが必要であればもちろんセッションを生成してもよいのですが、WODisplayGroupを使用せずにユーザの一覧を表示する方法を紹介しておきます。WODisplayGroupを使った場合に比べて、若干コードの量は増えるのですがセッションを生成せずに処理が行えるようになります。
　まず、WODisplayGroupを使用していたときのDirectActionの実装ですが、次のようになっています。これは最初に紹介したURLに対応するメソッドです。

     public WOActionResults browseAction() {
         return pageWithName("UserList");
     }

　単純に”UserList”コンポーネントを生成してreturnしているだけです。このコードを書き換えて、あらかじめDirectAction内でユーザの一覧を取得し、次に表示する”UserList”コンポーネントに渡すようにしてみたいと思います。
　WODisplayGroupを使用した場合は、WebObjects Builder上でパラメータを指定していただけですが、今度は同様の処理をコーディングしてみたいと思います。モデルに設定されているFetch Specを呼び出すにはEOFetchSpecificationクラスのstaticメソッド”fetchSpecificationNamed”を使用します。
　Entity “MOSAUser”に設定されたFetch Spec “PublicUsers”を取得するには次のようなコードになります。

・モデルからのFetch Specの取得
EOFetchSpecification.fetchSpecificationNamed(
“PublicUsers”, “MOSAUser”);

　Fetch Specが取得できればあとはEditingContextを使用してデータを取得することができます。今回はDirectAction内でセッションを利用しない処理をおこなうため、EditingContextは新たに生成して処理をおこないます。このときのコードは次のようになります。

    public WOActionResults browseAction() {
         EOEditingContext ec = new EOEditingContext();
         ec.lock();
         EOFetchSpecification.fetchSpecificationNamed(
                                        "PublicUsers", "MOSAUser");
         NSArray users = ec.objectsWithFetchSpecification(fetchSpec);
         ec.unlock();

         UserList nextPage = (UserList)pageWithName("UserList");
         nextPage.setMosaUsers(users);

         return nextPage;
     }


　これで、ユーザの一覧をセッションを使用せずに表示できるようになりました。それでは次回はEditingContextの扱いについてもう少し考えてみたいと思います。

小池邦人のCarbon API 徒然草（2006/01/20）

アプリケーションのUniversal Binary化（その1）

今回からは、本サンプルアプリケーションのUniversal Binary化（Intel x86 CPU対応）について解説していきたいと思います。最初に、現在の開発プロジェクトを、Metrowerks CodeWarrior 9.6からXcode 2.2.1（最新バージョン）へ移植する作業から始め、次に、ソースコードの一部分をPowerPC用からx86用に修正し、最終的にUniversal Binary対応のMach-Oアプリケーションを完成させます。

開発プロジェクト移行の解説をする前に、まずは「Universal Binary化とは何ぞや？」と言う話をしておきたいと思います。本サンプルアプリケーションは、Carbon FrameworkとNibファイルを用いたMach-O形式アプリとして開発されています。また、若干のリソースデータも用いています。Universal Binary化を実行すると言っても特別なことはなく、こうした開発の仕組みについては何も変更する必要はありません。簡単に言えば、開発環境のコンパイラをPowerPC用からx86用に切り換え、再コンパイル＆リンク（Make）をし直せば完了となります。

こう書いてしまうと、Universal Binary化の作業はとても簡単のように聞こえるのですが（笑）、実際にはプロジェクト形式（CocoaかCarbonかJavaか）やアプリケーションの規模（ソースコード量）、利用している専用フレームワークの種類などにより、その困難さは大きく変化します。ちなみに、移行作業の大部分は、アプリケーションのソースコードの一部分を、PowerPC対応からx86対応に書き換えるという作業に割り当てられることになります。この書き換え量が多いか少ないかにより、そのアプリケーションのUniversal Binary化が完了するまでの作業時間（困難さ）が決定します。

まずは、Apple社が提供しているUniversal Binary化に関連するドキュメントを調べてみましょう。Apple社のDeveloper Webサイトには、x86トランジション関連のリソースを集中的に集めた「Developer Transition Resource Center」というサイトがあります。ここからは、ドキュメントだけではなく、開発ツールやWWDCにおける関連セッションの映像にもアクセスできます。また、ここから「Xcode Users Mailing List」や「Performance Optimization Development Mailing List」といったメーリングリストへの参加も可能となっています。

http://developer.apple.com/transition/

このサイトの日本語訳サイトは以下のURLです。こちらからは、上記サイトに掲載されているドキュメントの日本語訳ドキュメントにアクセスすることが可能です（すべてが日本語訳されているわけではないが…）。

http://developer.apple.com/jp/transition/

また、ここからはIntel社の「Development Support for Intel-based Macs」というWebサイトにもリンクされており、Intel CPU版のMacintosh向け開発ツール（C/C++やFortranなど）のβ版リリースを無料でダウンロードすることが可能です。これらの開発ツールは、将来的には販売される予定だそうです。

http://www.intel.com/cd/ids/developer/asmo-na/eng/255716.htm

関連ドキュメントのうち、まず最初に読むべき物は「Universal Binary Programming Guide,Second Edition」、日本語訳名は「Universal Binaryプログラミングガイドライン（第2版）」です。最新版PDFの発行日付は、2006年1月10日ですので注意してください。このドキュメントを一読すれば、Universal Binary化に必要な知識をほとんど入手することが可能です。Universal Binary化の過程ついてもう少し大ざっぱに把握したい人は、「Adopting Universal Binary on Mac OS X」、日本語訳「Universal Binaryの導入」を先に読むのが良いでしょう。

ちなみに、開発アプリケーションがMach-O形式でなくCFM形式であったり、未だCarbon化されていない状況の場合には、最終ゴールは随分と遠くなります（笑）。その場合には、先んじて「Carbon Porting Guide」「Moving Your Code to Mac OS X」を、この機会にCarbonでなくCocoa Frameworkを利用して新規開発を行いたい人は、「The Objective-C Programming Language」、日本語訳名「Objective-C プログラミング言語」を参照されることをお勧めします。色々なタイプのプロジェクトを、どのようにx86対応へと移行させるのかのヒントは、「Scoping Your Transition Project」、日本語訳名「タイプ別移行計画」を参照してください。また、Mac OS Xのバージョン番号にセンシティブなアプリケーションを開発している場合には、「Cross-Development Programming Guide」、日本語訳名「クロス開発プログラミングガイド」が参考になります。

また、ソースコードでAltiVecコードを利用しているソフトは、この部分を完全に別コード（通常のCコードかx86のSSEコード）に差し換える必要があります。これは、x86 CPUにはAltiVecユニットがないためですが、この作業については、「AltiVec/SSE Migration Guide」が参考になります。また、AltiVecコードを直接記述しないで、特定の処理を高速にしたい場合には、関連ドキュメントとして「Taking Advantage of the Accelerate Framework」、日本語訳「Accelerateフレームワークの活用」を調べてみてください。また、「Optimizing Image Processing With vImage」「vecLib Framework Reference」「vDSP Library」などのドキュメントも処理の高速化についてのヒントを提供しています。ただし、残念ながらこれらのドキュメントには日本語訳が存在していません。

現在、最新版のCodeWarrior 10にはPowerPC用コンパイラしかなく、このバージョンを最後にメーカ側のサポートは終了してしまいます。つまり、現時点ではx86用gccコンパイラが使えるXcode 2.2.1を利用しないかぎり、アプリケーションのUniversal Binary化は行えません。開発環境をCodeWarriorからXcodeへ切り換える必要がある人は、「Xcode 2.2 User Guide」「Working with Xcode build Setting」「GCC Porting Guide」「Porting CodeWarrior Projects to Xcode」、日本語訳名は「Xcode 2.2ユーザガイド」「Xcodeビルド設定の取り扱い」「GCC ポーティングガイド」「CodeWarriorからXcodeへのプロジェクトの移行」（概要と詳細）などを読まれることをお勧めします。

次回は開発環境の移行について詳しく解説します。サンプルアプリケーションの開発プロジェクトを、Metrowerks CodeWarrior 9.6からXcode 2.2.1へ移植する話です。

つづく

SqueakではじめるSmalltalk入門　　　第54回　　鷲見 正人

　本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。今回は、“生命感”をテーマに作られたGUIフレームワーク、「Morphic（モーフィック）」概要とモーフのごく基本的な操作についてです。

▼Morphicとは
　Squeakの前身であるApple Smalltalkや、さらにさかのぼって、ALTOコンピュータのOSだったころの古いSmalltalkシステムでは、今はCocoaや一般的なWebアプリケーションで知られるようになったMVCアーキテクチャと、単純なビットマップ描画を組み合わせたGUIフレームワークが用いられていました。Squeakも当初はせいぜいカラー化を施した程度でこの枠組みをそのまま受け継ぎますが、すぐに、扱わなければならない視覚的情報の多様化に対応するためGUIフレームワークの刷新を迫られることになります。こうして昔ながらのMVCに代わって新たに採用されたのがMorphicです。

Morphic GUIフレームワークは、もともと、Smalltalkにインスパイアされて（あるいは批判的精神で）作られた「SELF」と呼ばれるオブジェクト指向言語/環境向けに開発されたものです。SELFは、仮想マシンの高速化技術がJavaに応用されたり、インスタンスベース（プロトタイプベース）という考え方がNewtonScriptやJavaScriptに強い影響を与えたり、Morphicの委譲ベースのGUIパーツの協働の仕組みが、やはりNewton OSのGUIのあり方を決定づけたりと、地味ながら、なかなか示唆に富んだソフトウエアであります。Win版はないのに、なぜかMac版の提供が続いていて、今もOS Xで動かすことができます。

http://research.sun.com/self/
http://research.sun.com/self/release_4.2/release.html
http://research.sun.com/self/release_4.0/Self-4.0/Tutorial/index.html

　このSELF向けMorphicの主要な開発者の一人であるジョン・マロニーが、Squeak開発チームに参加、Smalltalkへの移植を行なった結果できあがったのがSqueakのMorphicです。Morphicの名前は、ギリシャ語の「形」や「姿」を意味するmorph（モーフ）からとられたものだそうです。変形を意味するmetamorphose（メタモルフォーゼ）といった英単語にも含まれていますね。Morphicでは、これと同じ「モーフ」と呼ばれる視覚化されたオブジェクトの組み合わせによりGUIを具現化しています。

モーフというのは、端的にはドロー系描画アプリで使う基本図形オブジェクト（特に矩形オブジェクト）を思い浮かべていただければよいと思います。ただ、ドロー系の図形は色や線の太さや大きさなどの属性しか持ち合わせていないのに対し、モーフはそれに加え自らが積極的に機能し、あるいは、複数で協働することでGUIパーツの役割を果たすことが可能な点で異なります。SELFやSqueakシステムでは、およそ画面上で目に付くものはすべて（ウインドウもメニューも文字も画像も、そしてデスクトップやマウスポインタ(!)すら）このモーフによって成り立っています。

▼モーフの基本操作
　モーフはすべて、クラス「Morph」を継承したクラスのインスタンスです。Morphクラスとそのサブクラス群のありようは、Application KitのNSResponderとそのサブクラス群の関係に似ていなくもありません。が、APIとして洗練され、すっきりと分かりやすく整理されたNSResponderとは違って、Morphはそれを継承するサブクラスの数と、そこで定義されたメソッドの数の多さは尋常ではなく、けっして学びやすい（使いやすい）ものとは言えなさそうです。

Morph allSubclasses size ” => 434 ”
Morph selectors size ” => 1287 ”

　この数のものを、いきなり全体から把握しようとすることは無謀なので、身近なところから少しずつ見て行くことにしましょう。まず手始めは、モーフのドロー系オブジェクト的側面に着目して、モーフに付与された基本的な操作方法を紹介します。とりあえず、モーフを画面に出してみます。

Morph new openInHand

　この式をdo itすると、マウスポインタに青い矩形が付いてまわるようになります。これがもっとも基本的なモーフ（クラスMorphのインスタンス）です。デスクトップのどこかでクリックすると、その場に設置できます。

[fig.A]マウスポインタに付いてまわるモーフ
http://squab.no-ip.com:8080/mosaren/uploads/54a.png

　このモーフはクリックするとピックアップできますが、モーフの種類によっては、クリックが別の振る舞いに割り振られていたり、そもそもピックアップが制限されていることがあります。そんなときは、コマンドキーを押しながらモーフをドラッグすると移動できます。この操作に伴って、モーフの周りに現われるのが「ハロー」と呼ばれるボタン群で、モーフに関わる各種機能を提供すると同時に、このモーフが選択されたことを意味します。ドラッグ操作をしなければ（つまりコマンドクリックで）移動させずに選択だけすることも可能です。

[fig.B]選択されたモーフと現われたハロー
http://squab.no-ip.com:8080/mosaren/uploads/54b.png

　ハローとは英語で後光や光輪を意味する「Halo」で、より正確にはヘイローなのですが、比較的よく知られた心理学用語で「ハロー効果（後光効果、halo effect）」というのがあるので、これにならってハローと呼んでいます。ハローは、モーフの種類によって出る数や種類が若干異なりますが、ほぼこの12個は共通しています。ここでは、上段中央の移動に関わるハロー2個と、上下左右の端にある4つの操作ハローの機能を紹介しましょう。

上段中央の黒いハローはモーフをピックアップして（持ち上げて）移動するためのボタンです。すぐ右隣の茶色ハローは、先のコマンドドラッグと同じです。

コマンドドラッグ（茶ハロー）とピックアップ（黒ハロー）との違いは、他のモーフに対する前後の位置関係や従属関係を維持したまま移動できるかどうかです。たとえば、デスクトップ上で他のモーフとの前後位置関係を変えずにモーフを移動したいときは、コマンドドラッグや茶ハロー使います。他方で、後で出てくるゴミ箱からモーフを取り出してデスクトップに移動したいとき（主従関係にあるモーフを変更する）には、コマンドドラッグ（茶色ハロー）ではなくピックアップ（黒ハロー）を使います。

右下の黄色いハローは、Macのウインドウのサイズボックスに相当するもので、縦横比や大きさを変えることが可能なモーフで機能します。多くのドロー系ツールがそうであるように、シフトキーを押しながらドラッグすると、縦横比を固定したまま大きさだけを変更することも可能です。左下の青いハローはモーフの回転、右上の緑のモーフは複製、左上のピンクのモーフは削除（ゴミ箱へ移動）を担当します。

ゴミ箱は、初回削除時に画面に現われます。画面にあるときは、Finderでのアイコン操作のように、ピックアップしたモーフをドロップインして捨てることも可能です。ゴミ箱から完全に消去するには、ゴミ箱をダブルクリックして現われる“ゴミ箱の中身”を表示するためのウインドウもどき（やはりこれもモーフ）の右上にある「E」ボタンをクリックします。

[fig.C]ゴミ箱アイコンと、その中身を確認するためのモーフ
http://squab.no-ip.com:8080/mosaren/uploads/54c.png

　次回は、デスクトップや、ウインドウ、メニューといった複雑なGUI構成要素が、どのようにしてこの「モーフ」の組み合わせにより実現されているのかを調べてみましょう。

バックナンバー：
http://squab.no-ip.com:8080/mosaren/

ニュース・解説

今週の解説担当:木下 誠

———————————————————————-
インテルMac出荷開始！
———————————————————————-

すでにご存知の通り、サンフランシスコのエキスポでインテル版CPUを搭載したMacintoshが発表されました。同時に出荷も始まり、そろそろ皆さんのお手許に届いていることでしょう。

ADCの方でも早速動きがありました。まず、先週の小池さんの記事でも触れられていますが、開発用に貸し出していたDeveloper Transition Kit (DTK)を、Intel iMacと交換する、DTK交換プログラムが始まっています。4月1日までですので、対象となる方は忘れずに交換しておきましょう。

Mac OS X Universalロゴプログラムも始まっています。PowerPCに移行した時もありました、パッケージやWebサイトに、Universalアプリケーションであることを示すロゴを付けることができます。ロゴマークは、白と青の「陰陽」をモチーフにしたものですね。ライセンス契約書の郵送が必要です。

他にも、Universal Binaryプログラミングガイドラインが第2版になり、Developer Transition Resource Centerにもドキュメントが追加されています。Universal化のために、細かくチェックをしておきましょう。

DTK Exchange Program（日本語）
http://developer.apple.com/jp/dtkexchange/

Software Licensing Agreements: Mac Logo Program（日本語）
http://developer.apple.com/jp/softwarelicensing/agreements/maclogo.html

Universal Binary Programming Guidelines, Second Edition（日本語）
http://developer.apple.com/jp/documentation/MacOSX/Conceptual/universal_binary/index.html

Developer Transition Resource Center（日本語）
http://developer.apple.com/jp/transition/

———————————————————————-
インテル製Mac OS X向けコンパイラ
———————————————————————-

これも先週小池さんが触れていましたが、インテルからMac OS X向けの開発ツールが登場しています。C++コンパイラ、Fortranコンパイラ、Math Kernel Library、Integrated Performance Primitivesが含まれています。最後の1つは、メディア用の最適化されたライブラリでしょうか。

これに関しては、CNETの記事「インテルのMac用開発ツール – そのベータ版の内容とは」が、詳しく報じています。それによりますと、インテルコンパイラはXcodeに組み込んで、gccと置き換えて使うことができるようです。記事では、Universal Binary (UB)の開発に使えるとありますが、UBのインテルビルドに使える、ということでしょう。

この開発ツールの利点は、OpenMPを利用してデュアルコアに最適化できる、SSEに最適化できる、あらかじめ最適化された数学ライブラリなどが使える、といったところでしょう。また、Fortranコンパイラもあるので、科学技術計算用途にも向くと思われます。

注意すべき点は、Objective-Cのサポートはないところでしょう。インテル製コンパイラの恩恵を受けるには、C/C++で書く必要があります。まぁ、もともと速度重視のところにはObjective-Cは向かないですからね。

というわけで、インテル版Mac向けに、特にメディア処理を行うアプリケーションを最適化したい方などは、利用を検討してはいかがでしょうか。ベータ版は無料で利用でき、夏に登場する予定の正式版では、C++コンパイラ$399、Fortranコンパイラ$499、Math Kernel Library $399、Integrated Performance Primitivesは$199になるそうです。

Intel Software Development Products for Mac OS*
http://www.intel.com/cd/software/products/asmo-na/eng/227389.htm

インテルのMac用開発ツール – そのベータ版の内容とは
http://japan.cnet.com/news/ent/story/0,2000047623,20094739,00.htm

———————————————————————-
QuickTimeを用いた、圧縮と展開に関するQA
———————————————————————-

最近、ドキュメントやサンプルの公開ラッシュが続いているQuickTimeですが、またQuickTimeに関する新たなTechnical Q&Aが公開されました。ICM(Image Compression Manager)に関する一連のQAです。

Compress SessionsまたはDecompress Sessions、つまり画像の圧縮と展開に関する解説を行っています。

QA1450: Compression Sessions – Enabling multi-pass encoding
http://developer.apple.com/qa/qa2005/qa1450.html

QA1455: Compression Sessions – Temporal compression options
http://developer.apple.com/qa/qa2005/qa1455.html

QA1456: Compression Sessions – Configuring options using the Standard
Compression dialog
http://developer.apple.com/qa/qa2005/qa1456.html

QA1457: Compression Sessions – Multipass encoding and the pass mode flags
http://developer.apple.com/qa/qa2005/qa1457.html

QA1460: Decompression Sessions – Setting codec accuracy and field mode
http://developer.apple.com/qa/qa2005/qa1460.html

———————————————————————-
Quartzに関するQAとTN
———————————————————————-

Quartzに関するQAとTNが更新されています。

QA1236では、QuartzDebugの使い方が説明されています。QuartzDebugは、開発環境に付属する、Quartz周りのパフォーマンスを調べるためのツールです。このドキュメントは前から公開されていましたが、10.4用にアップデートされました。

TN2133では、画面の更新がどのように行われているかを解説しています。画面の更新は、Quartzで統合されて行われています。アプリケーションが、どのように自身描画の更新を行うべきかが議論されています。今回の更新では、10.4.4で追加されたInfo.plistのキー、CGDisableCoalescedUpdatesを説明しています。

QA1236: Debugging Graphics with QuartzDebug
http://developer.apple.com/qa/qa2001/qa1236.html

TN2133: Coalesced Updates
http://developer.apple.com/technotes/tn2005/tn2133.html

MOSAからのお知らせと編集後記は割愛します

MOSA Developer News　　　略称［MOSADeN＝モサ伝］
Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
このメールの再配信、および掲載された記事の無断転載を禁じます。
特定非営利活動法人MOSA
Copyright (C)2006 MOSA. All rights reserved.