MOSA Multi-OS Software Artists

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

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

MOSA Developer News[MOSADeN=モサ伝]第108号

2004-04-06

目次

  • Cocoaでいこう! Macらしく  第45回  Yoshiki(DreamField)
  • 小池邦人の「Carbon API 徒然草」
  • 「Behind the WebObjects」  第17回  田畑 英和
  • ニュース・解説
  • MOSAからのお知らせ

Cocoaでいこう! Macらしく  第45回 Yoshiki(DreamField)

 今日は、いよいよパネルに情報を表示します。

パネルを表示しよう(その7)

 前回はInfoPanelController.mにupdateImageInfoというメソッドを実装しました。これを実行すれば、パネルにイメージの横幅と縦幅を表示することができます。では、いつ誰がこれを呼び出せば良いのでしょうか。まず、考えられるのは、パネルを表示した直後です。パネルを表示すると同時に、既に表示されているイメージの情報を表示しなければなりません。パネルを表示した直後ですから、実行するのは自分自身ですね。
 それでは、InfoPanelController.mに、次のメソッドを実装してください。場所は、initとupdateの間にしてみてください。

- (void)windowDidLoad {
    [ self updateImageInfo];
}

 NSWindowControllerのリファレンスを見てみましょう。最初の方にSubclassing NSWindowControllerという項目がありますから、見つけてください。ここの一覧の中に、windowDidLoadがあります。説明には「Override to perform tasks after the window nib file is loaded.」と書いてあります。
つまり、nibファイルをロードした後の処理はこれをオーバライドして記述しろ、ということですね。nibファイルをロードする前は、ウィンドウもそれに乗っている部品も実体がありませんから、これに対してメッセージを投げることはできません。そこで、nibファイルをロードした後に実行されるように、これを使うわけです。さらに、windowDidLoadの詳細なリファレンスを見てみましょう。説明の中に「The default implementation does nothing.」と書いてありますね。つまり、元々の実装は空ですから、superクラスのwindowDidLoadを呼び出す必要は無いというわけです。このメソッドの中では、updateImageInfoを呼び出しています。これでパネルを表示した直後に、情報が表示されるはずです。
 では、ビルドしてみましょう。すると、[ self updateImageInfo];の所にワーニングが出ていると思います(fig.01)。とりあえずはこれを無視して、実行してみましょう。何か適当な画像を開いて、それからEditメニューのShow Infoでパネルを開いてみてください。無事に情報が表示されたと思います(fig.02)。

[fig.01] ビルドするとワーニングが出る
http://www.remus.dti.ne.jp/~yoshiki/cocoa/ed1/45/images/fig01.gif

[fig.02] パネルに縦幅と横幅が表示された
http://www.remus.dti.ne.jp/~yoshiki/cocoa/ed1/45/images/fig02.jpg

 ところで、先程のワーニングは何だったのでしょうか。TinyViewを終了させて、Xcodeに戻ってみてください。エラーと警告からInfoPanelController.mを選んでみると、次の2つのワーニングが表示されます。

cannot find method `-updateImageInfo'; return type `id' assumed
`InfoPanelController' may not respond to `-updateImageInfo'

 つまり、InfoPanelControllerはupdateImageInfoを実装していないかもしれないと言っているわけですね。何でこんなワーニングが出るかと言うと、updateImageInfoの実装がこれより後にあるからです。コンパイラは上から順番に評価して行きますから、この時点では実装していることが分からなかったのです。ですから、実装の順番を入れ替えればこのワーニングは出なくなります。でも、いつもこんなことを考えて配置をしていたら面倒ですよね。それよりもインターフェース部できちんと宣言しておけば、順番なんて考える必要がなくなります。
 実は今まで、説明を短くするために、インターフェース部のメソッドの宣言はおざなりにしてきました。でも、本来はこれはきちんと宣言すべきです。今回の様なワーニングが出なくなりますし、どんなメソッドを実装しているのか見やすくもなります。それに、もしミスをしていれば、ワーニングではなく、きちんとエラーになってくれます。ビルド時に解決できることは、ビルド時に解決しておいた方が後々楽ですから、これは重要です。
 それでは、InfoPanelController.hに、次のメソッドの宣言を加えましょう。

- (void)updateImageInfo;

 これでビルドすれば、ワーニングは消えます。ついでに、他のメソッドの宣言も加えておきましょう。これを行った後のインターフェース部は、次の様になります。

@interface InfoPanelController : NSWindowController {
    IBOutlet NSForm *infoForm;
}
- (id)init;
- (void)windowDidLoad;
- (void)updateImageInfo;
@end

 さて、これでパネルを表示すれば、その時点のメインウィンドウが表示しているイメージの横幅と縦幅を表示することができるようになりました。でも、このパネルの表示はそれだけではいけないですよね。後から他の画像を開いた時は、その画像の情報表示に変わらなければいけませんし、メインウィンドウが切り替わった時にも、そのウィンドウの画像の情報表示に切り替わらないといけません。この実装は、次回です。

小池邦人の「Carbon API 徒然草」(2004/04/02)

メインオブジェクトを確保する-その2

今回はサンプルアプリケーションのソースコードから一時的に離れ、アプリケーション開発におけるメモリに関する問題点を考えてみます。また、オブジェクト操作の仕組みを自分では実装せず、Frameworkの汎用APIに頼ってしまうやり方(ヒント)についてもお話ししたいと思います。

Carbon Frameworkのメモリ領域確保用APIは、NewPtr()とNewHandle()です。NewPtr()ではPtr(ポインタ)で参照する静的メモリ領域が、NewHandle()ではHandle(ハンドル)で参照する動的メモリ領域が確保できます。メモリ領域確保と同時にその内容をゼロで埋めたい場合には、NewPtrClear()やNewHandleClear()の方を使います。確保した領域を開放するのは、DisposePtr()とDisposeHandle()の役目です。また、領域のサイズ(容量)を得るためにGetPtrSize()とGetHandleSize()が、Handle同士やHandleとPtr間でデータの複製や結合をするために、HandToHand()、PtrToHand()、PtrAndHand()、HandAndHand()などのAPIが用意されています。Handleとして確保した領域のサイズ変更や再配置を実行するAPIも幾つかあるのですが、筆者は使用したことがありません。上記APIに加え、2つのメモリ領域間でデータのブロック転送を行うBlockMoveData()と、メモリ領域内をすべてゼロで埋めるBlockZero()が筆者が利用しているメモリ関連のAPIです。

Carbon Frameworkのメモリ関連APIを詳しく調べたい方は、CoreServices FrameworkのMacMemory.hを参照してください。このヘッダを調べると、Mac OS X採用で消えてしまったAPIが沢山あることが分かります。
それこそが、Mac OS 9とMac OS Xでメモリ管理の仕方が大きく異なる証拠なのです。前回、Mac OS 9においてNewPtr()を使い確保したメモリ領域はフラグメンテーション(メモリ領域の断片化)を発生させる可能性が高いと説明しました。加えて、NewPtr()で大量のメモリを確保しようとすると、非常に時間がかかる欠点があったため、筆者の場合には、なるべく大きなメモリ領域はアプリケーションの起動時に先んじてNewHandle()で確保し、それをHLock()して使うという「癖」が付いてしまいました。確かにHLock()したHandleもフラグメンテーションを引き起こす可能性はあるのですが、この手法を取ればその確率は最小に押さえられます。

先んじて構造体を指定個数だけ確保する手法の最大の欠点は、利用できるオブジェクト個数を限定してしまうという点です。予想できる範囲内で最大数を確保しておくべきなのでしょうが、そうすると多数の未使用メモリ領域を保持することになり、メモリの使用効率を悪くするのも難点です。しかし、開発するアプリケーションの種類にもよるでしょうが、筆者がこの欠点により問題(ユーザからのクレームを含め)に遭遇したことは一度もありません。現実的には、そうした欠点をそれほど問題視することはないようです。逆に利点としては、オブジェクトの最大使用量が読めるということ、オブジェクトの解放忘れによるメモリリークを気にする必要がないこと、アクセス、確保、解放といった処理が非常に高速であることなどでしょうか。また、オブジェクトの消費により利用可能な「個数」は減りますが、メモリ領域の変動を起こすことがないのも強みです。

今回のサンプルは、オブジェクトの確保や解放の仕組みを勉強するという意味もあるので、あえて自分自身でその仕組みを用意しています。しかし、自分自身で作るまでもなく、Mac OS XのCarbon Frameworkには、オブジェクトの確保や保存をサポートしているAPI群がいくつも用意されています。その中でも一番古株なのはResource Managerでしょう。Resource Managerのオブジェクト(リソース)は、すべてHandleとして保持されています。Resource Managerは、Mac OS Xが登場する時点で抹殺されてしまうという噂も流れたのですが、ドッコイしぶとく生き残っています(笑)。その役目自体はNib関連のAPIに取って代わられようとしていますが、Resource ManagerのほとんどのAPIは今でもちゃんと利用できます。残念ながら、ツリー構造(多階層構造)でオブジェクトを保持するような目的には向いていませんが、使い道によっては今でも大きな利便さと手軽さを持ち合わせています。

次に紹介するのはCollection Managerです。「コレクション」とはあまり聞いたことがない名称ですが、QuickDraw GX(憶えてますか?)で図形データやプロパティを管理するために用いられていた仕組みです。QuickDraw GX自身はすでに消滅し存在しませんが(ソースコードはQuartz 2Dに引き継がれている)、そのオブジェクト管理の仕組みは独立して生き残っているという訳です(笑)。APIの種類やその使い方については、CoreServices FrameworkのCollections.hを参照してください。ヘッダファイルには、NewCollection()、DisposeCollection()、ReleaseCollection()など、名称を見れば何をするのかすぐに分かるAPIが並んでいます。いにしえのQuickDraw GXとQuickDraw 3Dは、オブジェクト指向を土台に構築された先進的なソフトウェア・モジュールだったのですが、それがMac OS Xでは採用されず、代わりにQuartz 2DとOpenGLという「原始的」な方が採用されていると言うのは皮肉な結果です(ソフト業界ではよくある話)。

続いてQuickTimeで用いられているオブジェクト管理用APIを紹介します。QuickTimeの様々なオブジェクトは、「コンテナ(QTAtomContainer)とアトム(QTAtom)」という仕組みで管理されています。これらもリソース同様にHandleとして保持されています。コンテナとアトムでは各オブジェクトをツリー構造で保持できることから、一時はこの仕組みを土台にしHyperCardの新版を開発しようという試みがありました(昔のWWDCでQuikTimeチームがよくデモしていた)。しかし、どうも頓挫してしまったようですね(涙)。Movieのプロパティ、エフェクトのデータ構造、QuickTime用の各種コンポーネントのプロパティ、Wired Movieのデータ構造などなど、コンテナとアトムはQuickTimeのありとあらゆる場所で使われています。自作アプリケーションにQuickTimeに依存した機能を実装しようとすれば、必ずこれらに遭遇することになります。関連ヘッダファイルはQuickTime FrameworkのMovies.hとなりますので、まずはそちらを参照してみてください。

最後に紹介するのは、CoreFoundation Frameworkに属するCFTree、CFArray、CFStringといったAPI群です。CoreFoundationはNEXTStepから引き継がれたFrameworkですので、すべてのモジュールがオブジェクト指向を土台に構築されています。今からCarbonでMac OS Xネイティブアプリケーションを開発しようと考えている方は、オブジェクト管理の主役としてCoreFoundation APIを採用するのが近道かもしれません。こうして色々と調べてみると、「システムのオブジェクト管理方法を何かひとつに統一しろよ!」とApple社には言いたいところです(彼らはCoreFoundationに一本化したいのだろう…)。しかし、今となってはもう手遅れなのかもしれませんね(笑)。

次回は、サンプルアプリケーションのソースコードに話を戻し、引き続き各初期化ルーチンの内容を見ていくことにします。

つづく

「Behind the WebObjects」  第17回  田畑 英和

 今回はDirect Actionの解説の続きの予定でしたが、WebObjectsのUpdateがリリースされましたので、ここでVer 5.2からこれまでのUpdateの流れをまとめてみたいと思います。各Updateではそれぞれ動作環境が異なっていますので単純に最新版を使えばよいというものでもありません。そこでVer 5.2から最新のUpdateである5.2.3までをまとめておきます。

WebObjects 5.2

 まずAppleStoreなどで現在販売されているWebObjectsはVer 5.2です。このバージョンがリリースされたのが2002/11ですから、もう1年以上前になります。その後OSやJava環境のアップデートに合わせて計3つのUpdateがリリースされ、それぞれ以下のURLからのUpdateをダウンロードすることができます。

[[UpdateのURL]]
・5.2.1
http://til.info.apple.co.jp/cgi-bin/WebObjects/TechInfo.woa/wa/showTIL?id=75433
・5.2.2
http://til.info.apple.co.jp/cgi-bin/WebObjects/TechInfo.woa/wa/showTIL?id=107649
・5.2.3
http://til.info.apple.co.jp/cgi-bin/WebObjects/TechInfo.woa/wa/showTIL?id=107873

 ここではWebObjectsがサポートしている各プラットフォームごとの説明や開発環境と運用環境それぞれに関する解説があります。Macの場合はソフトウェアアップデートの機能を使ってUpdateを入手することもできます。各Updateのインストール方法ですが、OS/Java/開発環境のバージョンをあらかじめUpdateに合わせて調整しておく必要がありますので詳しくは上記のTILページを参照してください。それでは各Updateについて詳しくみていきます。

WebObjects 5.2.1

 Mac上でJava 1.4.xが利用できるようになるまで長い時間がかかりましたが、このUpdateで、WebObjectsもようやく部分的にJava 1.4.1への対応がおこなわれました。ただし、Java 1.3.1と1.4.1の間にある非互換性が一部解消されたとアナウンスされており、この時点でもサポートされる正式なJava環境はJava 1.3.1でした。また1.3.1を正式にサポートする最後のUpdateがこの5.2.1でもあります。
 さいわいMac上では1.3.1と1.4.1が共存するようになっていますので、1.4.1をインストールしてしまった場合でも、1.3.1上でアプリケーションを動作させることができ、その方法が以下のURLで公開されています。

http://til.info.apple.co.jp/cgi-bin/WebObjects/TechInfo.woa/wa/showTIL?id=75505

 5.2.1の開発環境は以下のようになっています。

OS : Mac OS X 10.2.4以降
Java : 1.3.1
Dev Tools : Dev Tools December 2002

WebObjects 5.2.2

 Pantherリリース後にリリースされたのがこのUpdateです。このUpdateによりWebObjectsもPantherに対応しました。Pantherでは最初からJava 1.4.1がインストールされていますが、このUpdateによってWebObjectsもようやく1.4.1を正式にサポートするようになりました。逆にこのUpdateでは1.3.1はサポート外となっています。
 Pantherでは開発ツールがProject BuilderからXcodeに移行しましたが、このUpdateによってXcodeへの対応もおこなわれています。ただし、Xcodeでは使用する言語によって機能的な違いがあり、Objective-Cで使える機能がJavaでは使えない場合もあります。開発環境は以下のようになっています。

OS : Mac OS X 10.3以降
Java : 1.4.1
Dev Tools : Xcode 1.0

 このバージョンの運用環境については少し注意が必要です。Panther Serverにはあらかじめ5.2.2のDeploymentがプレインストールされています。Jaguar時代にもMac OS X ServerにはWebObjectsのDeploymentが付属していましたが、使用するには別途インストールをおこなう必要がありました。
 Panther ServerではOSをインストールするとWebObjectsのDeploymentも同時にインストールされるようになりましたが、OSをインストールしただけではWebObjectsの実行環境(wotaskd)は自動的に起動しません。実行環境を起動させるためにはWebObjects用のStartupItemsを編集する必要があります。
 またデフォルトの状態ではCGIタイプのHTTPアダプタが使用されますので、Apache用のHTTPアダプタを使用するのであればhttpd.confを編集する必要があります。StartupItemsとhttpd.confの詳しい編集方法については上記の5.2.2のTILに解説があります。

WebObjects 5.2.3

 2004/3にリリースされた現時点でのUpdateの最新版になります。このUpdateではJava 1.4.2を正式な動作環境としており、同時にいくつかのバグフィックスもおこなわれています。開発環境は以下のようになっています。

OS : Mac OS X 10.3.3以降
Java : 1.4.2
Dev Tools : Xcode 1.1

 新規にWebObjects 5.2.3の開発環境を用意するのは少し手間がかかります。まずOSを10.3.3にアップデートし、Xcodeを1.1にアップデートし、WebObjectsのUpdateをインストールするには5.2.2をインストールしてから5.2.3をインストールします。またJava環境も1.4.2にアップデートしておく必要があります。
 運用環境についてこのバージョンでも注意が必要です。最初にリリースされた5.2.3のDeployment Update(3/18以前に配布されたもの)にはWebObjects用のStartupItemsを削除してしまうという問題がありました。この問題については次のURLで解決方法が紹介されています。

http://docs.info.apple.com/article.html?artnum=107909

 ただし現在は修正済みのものが公開されています。ちなみに5.2.3の運用環境はWebObjects単体ではなくApplication Server Updateという名称でJBossやTomcatのUpdateといっしょに配布されています。

 以上がWebObjects5.2から5.2.3までの流れになります。使用中の環境に応じて適切なUpdateをインストールしていただければと思います。また今回説明しましたようにUpdateのリリース直後に問題が発生したこともありますので、新しいUpdateをインストールする場合はまずテスト環境でインストールするなどの対応をおすすめします。またメーリングリストなどで情報収集することも重要でしょう。それでは次回はあらためてDirect Actionの続きを解説したいと思います。

ニュース・解説

 今週の解説担当:新居雅行

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃Navigation Servicesの利用方法を解説する文書が公開
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ファイルを開いたり保存するときに表示されるダイアログやシートを管理するNavigation Servicesの解説ドキュメントが公開されている。これらのダイアログボックスは単に表示するだけでなく、その中にコンポーネントを追加したり、動作をカスタマイズしたいこともよくあるため、プログラミングが必要な場面でもある。Carbonアプリケーションでの利用方法をプログラミング例を示して解説している。

Introduction to Providing Navigation Dialogs
http://developer.apple.com/documentation/Carbon/Conceptual/ProvidingNavigationDialogs/

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃ファイルメーカーProの新版Ver.7でのAppleScriptの違いを解説
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
.com Solutionsは、FileMaker Pro 6と7でのAppleScriptの違いをまとめたPDF文書を公開した。
7ページの文書であるが、FileMakerを使う上でのいろいろな場面で、Ver. 6と7でのスクリプトの作り方の違いを対比させて記載しており、FileMakerデベロッパは非常に参考になる文書だろう。文書自体はフリーで入手できる。

.com Solutions: Download and Demo Software
http://www.fmpromigrator.com/downloads/demo_software/index.html

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃OpenBase 8.0.2がリリース、自動的にフェイルオーバーする機能が追加
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Mac OS Xなどで稼働するSQLデータベースエンジンのOpenBaseがVer.8.0.2となった。新しいバージョンでは、データベースのミラーリングやクラスタリングの機能が向上し、問題が発生しても自動的に復活する。クライアントからの切断のない利用が可能となり、可用性が向上した。またストアドプロシージャのスクリプト言語OpenScriptがVer.2となって例外処理などが組み込まれている。他に、Cocoaフレームワークとの互換性を高めることで、Cocoaアプリケーションからの利用がやりやすくなった。

OpenBase
http://www.openbase.com/

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃REALbasicでユニットテストを実行するフレームワーク
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LogicalVue Softwareは、REALbasicでユニットテストを行うフレームワーク「RBUnit 1.0」をリリースした。フレームワークをREALbasicのプロジェクトの中に含めておくことでユニットテストを実行できる。また、実行結果を参照するユーザインタフェースも提供されている。無償のStandard版と、$39.95のProfessional版がある。違いは、テストの数がStandardでは10項目までだが、Professionalは無制限であるということと、Pro版ではソースコードも公開されているということ。また、Pro版ではコンパイル結果でのユニットテストも可能になっている。REALbasic 5.5以降で利用でき、Mac OS XとWindowsに対応する。Classic版は今後にリリースが予定されている。

RBUnit
http://www.logicalvue.com/Products/RBUnit.htm

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃Core Audioの解説文書が公開
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
サウンドやMIDIを扱うシステム機能であるCore Audioのドキュメントが公開されている。これまでも限定的には公開されているようであるが、Core Audioは先にAPIが公開されており、解説ドキュメントは待ち望まれていたものである。Core Audioの全体像から、各種APIの解説や利用方法を含んでいる。解説はすべてC言語ベースのもので、Javaでの解説は含まれていない。

Core Audio
http://developer.apple.com/documentation/MusicAudio/Reference/CoreAudio/

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃Mac OS X向けドライバの作成方法を解説した文書が公開
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Mac OS Xのドライバの作成方法を解説した文書が公開されている。Mac OS XではI/O Kitという独自のアーキテクチャで稼働するドライバが必要になるが、他のOSなどでのドライバを移植するための知識としてまとめられているが、I/O Kitの基礎的なことやドライバの基本的なこと、そしてC++言語でのプログラミングなどがまとめられている。

Porting Drivers to Mac OS X
http://developer.apple.com/documentation/Porting/Conceptual/PortingDrivers/

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃Apple Design Awardsの募集を開始
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Apple Design Awardsの募集が始まっている。Mac用の製品やQuickTimeコンテンツに対するコンテストで、WWDC 2004で発表が行われる。今年から、パフォーマンスを競う部門が新たに設けられた。締め切りは、5月17日となっている。

Apple Design Awards 2004
http://developer.apple.com/wwdc/ada.html

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

MOSA Developer News   略称[MOSADeN=モサ伝]
Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
このメールの再配信、および掲載された記事の無断転載を禁じます。
http://www.mosa.gr.jp/
Copyright (C)2004-2006 MOSA. All rights reserved.