MOSA Developer News[MOSADeN=モサ伝]第98号
2004-01-27
目次
- Cocoaでいこう! Macらしく 第36回 Yoshiki(DreamField)
- 小池邦人の「Carbon API 徒然草」
- 「Behind the WebObjects」 第12回 田畑 英和
- ニュース・解説
- MOSAからのお知らせ
Cocoaでいこう! Macらしく 第36回 Yoshiki(DreamField)
前回説明したように、実際にプログラムを組む時には色々と考慮すべきことがあります。今回は、説明を分かりやすくするために、あえて手を抜いて説明から除外していた部分で、しかしプログラムを組む上では考慮しておいた方が良いことを説明します。
オブジェクトをセットするメソッドで気をつけるべきこと
MyImageViewクラスでは、イメージをセットするメソッドを次の様に実装していました。
- (void)setImage:(NSImage *)newImage{
image = newImage;
[ image retain];
[ self setFrameSize: [ image size]];
}
実はこれはあまり良い実装ではありません。どこがまずいのかと言うと、2回以上呼び出されることを考慮していないからです。
確かに今回のプログラムでは、2回呼び出されることはありません。しかし、将来どんな改良を加えることになるか分かりませんし、他のプログラムに流用するかもしれません。あるいは、バグによって2回以上呼び出されることだって考えられます。従いまして、どの様な使われ方をしても、妥当な動作をする様に組んでおくことが、将来に渡って問題を起こしにくくするコツであると言えます。
では、このメソッドが2回以上呼び出されたら、何が起こるのか考えてみましょう。1回目は、imageに新しいイメージへのポインタがセットされ、retainすることにより所有することになります。2回目も、imageに新しいイメージへのポインタがセットされ、retainすることにより所有します。プログラムの動作上、特に問題は起こりません。しかし、良く考えてみて下さい。1回目に受け取ったイメージはどうなってしまったのでしょうか。自分がretainしたのですから、自分でreleaseする義務があります。ところが、このプログラムではこれを行っていません。つまり、1回目にセットしたイメージは、既に必要無いのに、プログラムが終了するまで所有しっぱなしです。この様に、2回以上呼び出されると、メモリリークを起こしてしまうのです。
これを防ぐためには、既にセットされているイメージをreleaseしてから、新しいイメージをセットする必要があります。そこで次の様に実装してみましょう。
- (void)setImage:(NSImage *)newImage{
[ image release];
image = newImage;
[ image retain];
[ self setFrameSize: [ image size]];
}
このプログラムはimageをreleaseしてから、新しいイメージをセットしています。こうすれば、前回セットしたイメージが残ってしまうことを防げます。では、1回目に呼び出された時はどうなるでしょうか。1回目は、イメージがセットされていないのに、releaseメッセージを送ってしまっています。ですが、これは問題になりません。何故なら、クラスを生成した時に、全てのインスタンス変数は0クリアされており、imageの値はnilだからです。nilにメッセージを送っても、何も起こりません。
さて、これで一見問題は無いように見えます。ですが、実はこれでもまだ駄目なのです。どんな時に駄目なのかと言うと、2回以上連続で同じイメージをセットしようとした時です。どうなるのか考えてみましょう。1回目はimageはnilですから、releaseメッセージを送っても何も起こりません。そしてimageに新しく渡って来たイメージのポインタがセットされ、retainして所有します。2回目は、imageには前回セットしたイメージへのポインタが入っています。releaseメッセージを送れば、このイメージは解放されます。そして、今解放したのと同じイメージへのポインタをimageにセットし、これにretainメッセージを送って・・・。ちょっと待って下さい。解放してしまったイメージにretainメッセージを送ったら、このプログラムは誤動作してしまいます(おそらくは吹っ飛びます)。そもそも、一度解放して消えてしまったイメージを、今更所有なんて出来ません。つまり、まったく同じイメージを2回以上連続でセットすると、吹っ飛ぶという、とても危険なプログラムになってしまったのです。
それでは、このことも考慮した実装にしましょう。
- (void)setImage:(NSImage *)newImage{
NSImage *tmpImage;
tmpImage = image;
image = newImage;
[ image retain];
[ tmpImage release];
[ self setFrameSize: [ image size]];
}
imageの値を退避しておき、後で使えるようにした上で、imageに渡って来たイメージのポインタをセットしています。そして、こちらを先にretainし、その後で退避していた値を使って、今まで所有していたイメージをreleaseしています。この様にすれば、同じイメージが来ても、先にretainしていますから、releaseしても解放されません。違うイメージの場合でも、それぞれに対してretain、releaseしていますから問題は起こりません。とてもシンプルな方法です。
もう一つの書き方を紹介しましょう。私は普段、こちらの書き方で組んでいます。
- (void)setImage:(NSImage *)newImage{
[ newImage retain];
[ image release];
image = newImage;
[ self setFrameSize: [ image size]];
}
まず、新しいイメージをretainしてしまいます。それから、今までセットされていたイメージをreleaseします。そして、その後imageに新しいイメージへのポインタを格納します。この例の場合も先ほどと同様、新しいイメージのretainを先に行っていますから、たとえ同じイメージが来たとしても、releaseで解放されません。違うイメージの場合も、それぞれに対してretain、releaseしているのですから、大丈夫です。imageに格納するのはあくまでポインタであって、オブジェクトそのものではありませんので、この様な書き方も出来るわけです。
小池邦人の「Carbon API 徒然草」(2004/01/23)
プログラミングを楽しむために
Carbon API 徒然草の連載は2002年7月から始まりました。およそ1年半にわたり、Carbon Frameworkに巣くう(笑)個性的なAPIをいくつか紹介してきたわけです。Framework内のAPIが個別にどんな機能を有しているかを知ることはとても大事です。この点は、CarbonだけでなくCocoaや別のFrameworkについても言えることでしょう。しかし、アプリケーションを開発していると、API個々の能力を知るだけではうまくいかないケースに遭遇します。アプリケーションでは、いくつものAPIが有機的に結びつくことでひとつの機能を実現しています。またそうした機能が再度結びつくことで、より大きな仕組みをユーザに提供することになります。
API個々やそれを使った関数を勉強することが単語や文章の記述を身につけることに相当するならば、アプリケーション開発は、ひとつの小説を執筆することに相当するのかもしれません。また、アプリケーションを開発する時には、それを使う「ユーザ」、つまり小説に対する読者の存在を考慮に入れる必要もあります。実際にやってみないと分からない、もしくは理解できない色々な問題にも遭遇することにもなります。そこで、Carbon API 徒然草も本年から「実践編」ということで、一本のちゃんとしたアプリケーションを開発する過程をたどりながら、その中で登場してくるAPIの有機的なつながりや仕組みを解説していきたいと思います。
今回、実践編のサンプルとして利用するのは「2003年MOSA湘南セミナー」でCarboとCocoaの比較に利用した「MOSA_Sample_Carbon版」です。実際のセミナーは非常に短い時間でしたし、参加された方にも限られた解説しかできませんでしたので、それを補う意味でもこのサンプルを選んでみました。サンプルアプリケーションは「MOSA2003_Sample.sit」という名称で、筆者のサイトにアップされています。
http://www.ottimo.co.jp/library/index.html
利用している開発環境は、Metrowerks CodeWarrior 8.3ですが、ソースやリソースをそのまま移動すれば、Xcodeでも利用できると思います。当然CodeWarrior 9.0や 9.1でも問題ありません。ライブラリやヘッダファイルの保存場所アクセスパスに関して何か問題が生じた場合には、ご自分の環境に合わせてパスを変更してご利用ください。また、プリコンパイルドヘッダの名称などにもご注意ください。
このサンプルアプリケーションは、Carbon FrameworkとNibファイルによるコラボレーションにより開発されています。Carbonも、Nibファイルとの連動、Carbon Eventの実装、HIObject、HIViewの登場などにより、そこそこ(笑)モダンなFramewrokへと変貌しています。そうした最近の成長をあまり体験されていない方にとっては、この期にもう一度Carbonを見直してみても良いかもしれません。開発言語には「ピュアC」を利用しC++は使いません。ソースコード内で使うCの文法表記も、if、else、while、for、switch、case、break、returnに限ります。言語、環境、概念などの難しい話は抜きにして、純粋に「プログラミング」という行為を楽しみたいと思います。
また、現状のソースコードをそのまま解説して行くのも芸がないので、サンプルのReadmeにも記載されていますが、タイミングを見計らって以下のような機能をアプリケーションに追加してみたいと思います。もちろん、途中で面白いアイデアが湧いてくれば、そちらを優先してインプリメントするかもしれません。本線から脱線していくのがプログラムの楽しみ方のひとつですので…(笑)
・アプリケーションの初期設定の保存
・ウィンドウ(ドキュメント)設定の保存
・ファイルからの復帰、別名保存
・ページ設定、プリントダイアログ
・データブラウザ内のアイテムの順序変更
・アイテムからFinderへのドラッグ&ドロップ
・ウィンドウに表示した画像のカット&ペースト
・矢印キーによる選択アイテムの移動
・ダイアログやアラートのシートウィンドウへの対応
・ファイル保存を構造体のサイズに依存させない
・長いファイル名に対応させるためFSSpecをFSRef対応に変更
・上記にからんでユニコード文字列への対応
最近のプログラミングと言うと、言語に縛られ、APIに縛られ、Frameworkに縛られ、開発環境に縛られ、プログラミング概念に縛られ(笑)…どうも、筆者がBASICを使い徒然なるままに、好奇心のおもむくままに、創造の世界に浸っていたころの楽しさがなくなってしまったような気配です。まあ楽しいばかりでは仕事にならないという現実も存在しますが(笑)もう少し「気軽な体験」としてのプログラミングが戻ってきてくれればと思う今日この頃です。Macintosh用のアプリケーションを開発しながら、思いつくまま新しいアイデアをどんどん実現してみましょう!プログラミングが本来もっている、積み木で遊んでいるような「創造の楽しさ」を共有できればと考えています。
「Behind the WebObjects」 第12回 田畑 英和
前回はD2Wのルールについて解説しましたがいかがでしたでしょうか。D2Wではルールを記述することによりアプリケーションの挙動を定義していくことができます。ですが、いきなりルールを直接記述していくのはハードルが高いとおもいますので、以前紹介したアシスタント機能を使ったアプリケーションのカスタマイズ方法についてみていきたいと思います。
アシスタント機能を用いればGUI上である程度のカスタマイズができますが、背後ではアシスタント上での設定に応じて自動的にルールの生成がおこなわれています。つまり間接的にルールを生成していることになるわけですが、このようにして自動生成されたルールを応用することにより、さらに作り込をおこなっていくこともできます。
まずアシスタントの画面構成ですが、”Standard Mode”と”Expert Mode”の2つに分かれており、”Expert Mode”ではより細かい設定ができるようになっており、ページのGeneration機能が利用できます。どちらのモードを用いる時も基本的には1ウィンドウのシンプルな形式になっており、いくつかの機能がタブによって分けられています。
・”Entities”タブ
Entityはデータベース上では「テーブル」に相当します。この画面ではアプリケーションの処理対象に、プロジェクトに登録済みのモデルで定義されている各Entityを含めるかどうかを設定することができ、指定方法としては以下の3種類があります。
Hidden Entity:Entityをアプリケーションの処理対象から外します。
Read-Only Entity:Entityを処理対象に含めますが編集不可にします。
Read-Write Entity:デフォルトの設定であり、データの編集が可能です。
アシスタント上で設定をおこなった場合、「Save」ボタンで設定内容を実際にルールに反映させることができます。このときアプリケーションは動作させたままの状態でよく、アシスタント上での変更内容は直接起動中のアプリケーションに反映され、すぐに変更結果を確認することができます。「Save」をおこなう前であれば「Revert」ボタンにより変更をキャンセルすることができます。変更の保存をおこなった後にルールファイルを開いてみると、ルールが追加されていることが確認できます。Entityの設定をおこなったときには以下のようなルールが追加されます。
Lhs = *true*
Rhs Key = readOnlyEntityNames
Rhs Value = (Movie, MovieRole)
Lhs = *true*
Rhs Key = visibleEntityNames
Rhs Value = (Movie, MovieRole, Talent)
”Entities”タブでの設定は全画面に反映されますので、ルールを適用する条件のLhsは”*true*”になっています。Rhsですがkeyが”readOnlyEntityNames”のルールではRead-Onlyに指定したEntityの名前がValueに設定されています。またkeyがvisibleEntityNamesのルールにはRead-OnlyとRead-Write両方のEntityのEntity名一覧がValueに設定されています。
・”Properties”タブ
ここではアプリケーションの各画面についてのプロパティを設定します。例えば”Movie”テーブルの検索をおこなう画面をアシスタント上で設定するとします。このとき検索対象に含める”Movie”テーブル上のアトリビュート(カラム)や表示順をプロパティとして設定することができます。また”Movie”テーブル上のアトリビュートだけでなく、リレーション先のテーブルのアトリビュートも検索対象として指定することができます。
検索対象として、”Movie”テーブル上の”category”と”title”の2つのアトリビュートと、リレーション(studio)先の”name”を指定した場合には次のようなルールが生成されます。
Lhs = ((task = ‘query’) and (entity.name = ‘Movie’))
Rhs Key = displayPropertyKeys
Rhs Value = (category, title, stdio.name)
今回は特定のページでの処理を指定していますので、Lhsの指定もおこなわれています。ここで”task”の指定がおこなわれていますが、これはD2Wであらかじめ定義されている処理の種類を指定するキーです。検索処理に関するルールを定義しましたので、ここでは”task”が”query”として設定されています。
”entity.name”は名前のとおり処理対象のEntity名を指定するキーであり、ここでは”Movie”が指定されています。このようなルールが定義されていたときに”Movie”テーブルに対して検索処理がおこなわれると、D2Wエンジンがこのルールを解釈して、Rhsの”displayPropertyKeys”で指定されたアトリビュートを使用した検索用の画面を生成します。つまり「”Movie”の”query”を行うときには、category, title, stdio.nameの3つを使用します」といった意味のルールが設定されたわけです。
・”Page”タブ
ページのバックグラウンドカラーなど、ページの外見に関するパラメータを設定することができます。またD2Wではあらかじめ処理の内容ごとに数種類のページテンプレートが用意されており、ここで使用するテンプレートの切り替えをおこなうこともできます。テンプレートはあらかじめ用意されているだけでなく、自作してそちらを使用することもできます。
例えば、”Movie”テーブルを検索した結果を表示するページのテンプレートを別のものに設定した場合以下のようなルールが生成されます。
Lhs = ((task = ‘list’) and (entity.name = ‘Movie’))
Rhs Key = pageName
Rhs Value = BASPlainListPage
ニュース・解説
今週の解説担当:新居雅行
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃WebObjectsの講習会。Javaを使わないセミナーと入門・初級向け
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
テクニカルピットは、倉橋浩一氏によるWebObjectsの講習会を次の予定で開催する。
2004年2月24〜26日は、「JavaなしWebObjectsセミナー」(受講料40,000円)として、Javaの知識がないような開発者や利用者に向けて、WebObjectsを使ったデータベース処理を伴うWebアプリケーションを開発する方法を解説する。2004年3月15〜16日は「WebObjects 5.2 入門セミナー」(受講料30,000円)として、WebObjects初心者向けのツールの利用方法や動作原理などを解説する。
2004年3月17〜19日は「WebObjects 5.2 初級セミナー」(受講料50,000円)として、リレーションを含むようなデータベース利用やユーザインタフェースを作成する方法などを説明する。
入門セミナーと初級セミナーを連続受講する場合は受講料が6万円に割引となる。また、いずれのコースも通常3万円の自習用教材Homeworkパーソナル・ライセンス版を1万円で購入することができる。いずれも、自身の機材を持ち込んでの受講が可能であるが、機材をレンタルして利用する事もできる。
テクニカルピット:WebObjectsのページ
http://www.techpit.co.jp/WO/
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃Javaによるプロセスを「ヘッドレスモード」で動かす
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Technical Q&Aで、Javaでバックグランドプロセスを稼働させたとき、Dockにアイコンが出てきてしまう問題を解消する方法が掲載された。Javaのプロセスを動かしたとき、その中でAWTを利用すると、そこでCocoaのイベントループが動き出して、現在ログインしているユーザのDockにアイコンが出てきてしまう。場合によってはそこでプロセスを止められてしまう。Java 1.4ではヘッドレスモードとしてユーザに何も見せないで稼働させる事が可能で、システムプロパティのjava.awt.headlessをtrueにして稼働させるという手段がある。
ヘッドレスモードは、オリジナルのJavaでサポートしているモードである。
QA1328: Server Processes and the Dock
http://developer.apple.com/qa/qa2001/qa1328.html
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃Core AudioのMusicPlayerとその接続先
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Technical Q&Aに、Core AudioのMusicPlayerの利用方法についての文書が掲載されている。エンドポイントやディスティネーションの設定を、MusicPlayerにシーケンスを設定した直後に行わないといけないことが解説されている。
QA1330: Music Player Sequence Destinations
http://developer.apple.com/qa/qa2001/qa1330.html
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃Mac OS Xネイティブなリソースエディタ
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The La Jolla Undergroundからリリースされた「ResFool 1.0」は、Mac OS Xネイティブのリソースエディタだ。リソースフォークを開き、タイプごとにリソースを表示し、追加や修正などができる。16進数表示だけでなく、タイプごとに用意されたテンプレートの機能により、システム定義の設定などは、データに合わせた編集作業ができるようになっている。惜しいのは日本語文字列が化けてしまう事であり、フォント設定を変えても化けるので、その点は使いにくい面もある。データフォークに保存するリソースにも対応する。価格は$19.50のシェアウエアとなっている。
ResFool 1.0
http://www.ljug.com/sw/resfool.html
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃ファイルメーカーProでのファイル処理を行うプラグイン
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Troi Automatiseringから発売されているファイルメーカーPro用のプラグイン「Troi File Plug-in」がVer.2.7になった。以前のバージョンから約1年ぶりのバージョンアップとなる。ファイルメーカーProでファイルの読み書きあるいはコピーなどのファイル処理の機能を利用できるようになる。新しいバージョンでは、Mac OS X 10.3での動作を改良し、長いファイル名の場合の問題などを解消している。
Troi File Plug-in 2.7
http://www.troi.com/software/fileplugin.html
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃AppleScriptで使えるXSLT処理プロセッサ
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Late Night Softwareは、AppleScriptでXMLデータを扱うための機能拡張「XSLT Tools 2.0」のβ版を公開した。OSAX形式の機能拡張とサンプルプログラムなどからなっている。XML処理のコア部分は、ApacheプロジェクトのXerces 2.3.0やXalan 1.6を使用し、IBMのUnicode関連ライブラリのICU 2.6も使用している。スタイルシート変換などの機能が使え、以前のバージョンではできなかったノードの並べ替えなどにも対応している。XSLT Toolsは無償で利用できるソフトウエアだ。
XSLT Tools 2.0b1
http://www.latenightsw.com/freeware/XSLTTools/beta.html
MOSAからのお知らせと編集後記は割愛します
Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
このメールの再配信、および掲載された記事の無断転載を禁じます。
http://www.mosa.gr.jp/
Copyright (C)2004-2006 MOSA. All rights reserved.