MOSA Developer News[MOSADeN=モサ伝]第111号
2004-04-27
目次
- Cocoaでいこう! Macらしく 第48回 Yoshiki(DreamField)
- 藤本裕之のプログラミング夜話 #44
- 高橋真人の「プログラミング指南」 第43回
- ニュース・解説
- MOSAからのお知らせ
Cocoaでいこう! Macらしく 第48回 Yoshiki(DreamField)
パネルを表示しよう(その10)
前回までで、メインウィンドウが切り替わる度にパネルの表示も切り替わるようになりました。ところで、Cocoaに詳しい方は、そういう場合は、NSWindowDidBecomeMainNotificationを使うのではないか? と思ったのではないかと思います。実は、自分で通知しなくても、フレームワークは様々な通知を行っており、プログラムではこれを自由に活用できます。NSWindowクラスのリファレンスの下の方に、Notificationsという項目がありますので、見てください。NSWindowDidBecomeMainNotificationの説明もここにあります。
大抵の入門書はこれを使っていますし、私も最初の頃はこれを使っていました。ですが、何故か大抵の入門書では、メインウィンドウが切り替わった時のことは書いてありますが、最初にパネルを開いた時や、メインウィンドウがまったく無くなった時の説明がおざなりになっていることが多いです。もちろん、フレームワークが用意している通知だけを使っても、これに対応することは出来ますが、色々とやっている内に、こっちの方が楽なのではないか? と思うようになりました。それに、情報が変化したという通知ですから、メインウィンドウが切り替わったというのとは、ちょっと意味合いが異なります。今はたまたまメインウィンドウが切り替わった時しか情報が変化していませんが、そうで無い場合でも対応できるというわけです。もちろん、これが正解というわけではありませんので(と、言うより、多分正解は無いのですが)、一般的な入門書に書いてある、(おそらくは)正当である方法も一読することをお勧めします。
さて、今の話にも出て来ましたが、現在の実装では全ての画像を閉じて、メインウィンドウが無くなった時の事が考慮されていません。その場合は、最後に開いていた画像の値が表示されたままになってしまいます。これをクリアするようにしましょう。この処理はどこに組み込めば良いでしょうか。
全てのドキュメントが閉じられた時に、それを知ることが出来るのは誰でしょう。一番単純に考えると、それは全てのドキュメントを生成しているオブジェクトですね。この様なオブジェクトが存在することは、第5回の「Document-based Applicationの構造」で説明しましたが、それが何であるのかは今まで説明していませんでした。
プロジェクトを生成する時にDocument-based Applicationを選んだ場合、これはNSDocumentControllerクラスのインスタンスオブジェクトが行っています。これのリファレンスを見てみましょう。開いているドキュメントの数が0になった時に呼ばれるメソッドがあれば、パネルをクリアする処理を組み込むのは簡単だったのですが、残念ながらそういうのは無いようです。では、ドキュメントを閉じる処理に組み込むことを考えたらどうでしょうか。ドキュメントを閉じる処理は、removeDocument:というメソッドで行っています。と言うことは、これをオーバーライドし、ドキュメントを閉じた後に残りのドキュメントの数を数え、これが0になっていた時にパネルの値をクリアするようにすれば、望みの動作になるはずです。では、これを実装して行きましょう。
NSDocumentControllerクラスを継承したMyDocumentControllerクラスを作ります。まずはMyDocumentController.hとMyDocumentController.mをTinyViewのプロジェクトに加えてください。そして、MyDocumentController.hを次の様に書き直してください。
#import <Cocoa/Cocoa.h>
@interface MyDocumentController : NSDocumentController {
}
- (void)removeDocument:(NSDocument *)document;
@end
続けてMyDocumentController.mを次の様に書き直して下さい。
#import "MyDocumentController.h"
#import "ImageInfo.h"
@implementation MyDocumentController
- (void)removeDocument:(NSDocument *)document {
ImageInfo *imageInfo;
[ super removeDocument:document];
if( [ [ self documents] count] == 0){
imageInfo = [ ImageInfo sharedImageInfo];
[ imageInfo setImageSize:NSZeroSize];
[ imageInfo change];
}
}
@end
順番に見て行きましょう。
[ super removeDocument:document];
まず、removeDocument:本来の処理を行わなければなりませんから、superクラスにremoveDocument:メッセージを投げています。
if( [ [ self documents] count] == 0){
その後、自分にdocumentsメッセージを投げてドキュメントを管理しているNSArrayクラスのインスタンスを教えてもらい、これに対してcountメッセージを投げてドキュメントの数を教えてもらっています。そしてこれが0の時に、以下の処理を行います。
imageInfo = [ ImageInfo sharedImageInfo];
imageInfoは第43回に出て来ました。皆が共有して使用する、メインウィンドウのイメージの情報をセットするオブジェクトです。
[ imageInfo setImageSize:NSZeroSize];
これに画像の縦横のサイズとして、0サイズをセットしています。
[ imageInfo change];
そしてchangeメッセージを投げて、「情報が変わったぞ」という通知を行ってもらいます。これで、ドキュメントの数が0になった時に、パネルに表示される値は0になるはずです。
ところで、せっかくコーディングしたMyDocumentControllerクラスですが、これをインスタンス化するのはどうすれば良いのでしょうか。フレームワークはアプリの起動時に、勝手にNSDocumentControllerクラスをインスタンス化してしまっています。これをMyDocumentControllerクラスにすげ替えなければなりません。実はこれは、第25回で行ったことの応用で出来ます。その説明は、次回行います。
藤本裕之のプログラミング夜話 #44
今の指導要領ではもしかすると男女差別だとか言ってなくなってしまったかも知れぬが,ワタシが中学生の頃には「技術・家庭」という授業があって,男子は製図や木工,ハンダ付けなどをやり,同じ時間に女子が裁縫とか料理とかを勉強していた。ワタシの行ってた中学にはこの科目,しかも男子向けだけに結構でかい建物がひとつあって(昨年11月に帰省してみたら跡形もなくなってたが),そこに何台か旋盤がおいてあった。中学何年生の時だったかは憶えてないが、われわれは授業で旋盤の使い方を教わり、確かタオルハンガーみたいなものを各自一つずつ作ったはずだ。
あ、もしかすると知らないヒトもいるかも知れないので説明すると、旋盤というのは金属を削る機械である。基本的には削りたい金属を回転する軸に固定し、横から刃物(バイトと言う)をあててシュルシュルシュルと削る。構造としては100円くらいの鉛筆削りと同じだ(高い鉛筆削りは鉛筆の方を固定している)。金属の削りかすがクルクルクルと丸まって光る。なんつうか、これまた叱られるかもしれないが「男の機械」という感じの機械なんである。
それで思い出したが、「巨人の星」と同じ梶原一騎・川崎のぼるコンビで「男の条件」というマンガがあって、これの主人公が名前は忘れたけど旋盤工だった。自分たちと同じ旋盤工が主人公の根性マンガがあって愛読しているんだが、それに描かれた旋盤の形がウソッパチであることを悲しみ、マンガ家のところに「本物の旋盤を見に来てくれ」と頼みに行く。その旋盤を描いたのは自分と同年代のスカしたアシスタントで「そんな機械、それらしく見えればいいんだ」とぬかす。怒った主人公は「本物を描いてやる」と旋盤工を辞めてマンガ家を志す……って書いてみるとちととんでもない話だが、このマンガの影響もあって、少年フジモトは旋盤の授業が好きであったのです。
その旋盤工を50年務めた小関智弘というヒトが書いた「職人学」という本があって、「イメージできないから見積もりをふっかける」という話がでて来る。「図面を見て、どんな段取りをするか、どんな治具(製品を作る過程で使われる製品以外の製作物、プログラマが作るツールに近いか)を作って加工すべきか、それにはどれくらいの時間が必要かを適確にイメ−ジできる工場でないと」いけないのだ、という。
この話、ソフトウェアも全く同じだと思うのだ。クライアントの要求する仕様を聞き、それを実現するためのおおまかな方法を頭の中で組み立てる。まずは可能か可能でないかを判断し、可能であれば自分のスキルやスケジュール、その他諸々を勘案してどのくらいの期間が必要かを考え、最後にそれに対して要求したい報酬の額を計算する。そうでないといけない、というか、そうであるのが当たり前だと思いませんか。
ところが現実は全然そうぢゃない。プログラミング仕事は基本的に一品料理なのに、マクドナルドみたいな見積もりしかできないSEばっかりだ。あ、データベースですか、データベースの構築でしたらウチでは予想される総件数に応じていくらいくらとお勉強させていただいております。はい、メンテナンスはまた別契約で。あ、インターネットとの連動も必要? でしたら、こちらWEBアンドDBのセットがお得になっております、はい。ええ、それはもう当社には優秀なエンジニアが揃っておりますから。いえいえ情報の流出など絶対にございません。では、WEBアンドDBのセットで最大件数10,000件までのコースですね。定期メンテナンスは月単位、はい。……それで、お飲物はよろしいでしょうか?
絶対こんなヤツにプログラムを頼んぢゃいけません。
(2004_04_024)
高橋真人の「プログラミング指南」第43回
オブジェクト指向のとっかかり(29)
こんにちは、高橋真人です。早速、前回新しく書き直したプログラムの解説を始めましょう。
まずは、今回のプログラムの全体的なコンセプトを説明します。もともとこのプログラムは「改行コードの変換プログラム」ということで作っています。
改良前のバージョンでは「入力ファイルの改行はMac(CR)でなければならない」ことや「書き出し時の改行コードは、コンパイル時に指定したものに固定」ということで、実用的だとはどうあがいても言い難いものでした(笑)。
今回の書き直しによって、改行コードに関しては読み込み時も書き出し時も柔軟に対応できるようになりました。(ただし、文字コードに関してはシフトJISに限定)
まずユーザーにファイル名を指定させることによって入力ファイルを決定します。あとは、プログラム自体がファイルのデータを解析することによって、改行コードを識別するようになっています。ファイルの内容は、TextContentクラスのサブクラスのうちのいずれかの中に格納されるのですが、これらのクラスの違いは「改行コードが何であるのか」だけです。
前回のプログラムでは書き出す、つまり変換後の改行コードの種類によって生成するサブクラスのインスタンスを切り替えていましたが、今回は読み込み時にも別のインスタンスを生成しています。
処理の流れを箇条書きにすると、以下のようになります。
1. ファイルの中身を先読みし、改行コードを判別
2. 判明した改行コードに従って、インスタンスを生成
3. インスタンスがファイル内容を読み取る
4. ユーザーから変換後の改行コードを得る
5. 変換後の改行コードに従って、新たなインスタンスを生成。この時コンストラクタに変換元のデータを保持したインスタンスを渡して、データを受け渡す
6. 書き出し処理
つまり、2と5において別々のサブクラスから(同じサブクラスでは変換する意味がないので)新規にインスタンスが生成され、それらが改行コード以外のファイルの中身を受け渡すのです。
前バージョンにおいては、実装ファイルがからっぽでサブクラスのためのプレースホルダ的な役割しか果たしていなかったTextContentクラスですが、今回のバージョンにおいてはずいぶん活躍しています(笑)。むしろ、サブクラスの方が単に「改行コードの保持」という役割ぐらいしか担わなくなって、ファイルからの読み込み、書き出し処理に関しては、TextContentクラスが中心となって処理を行っているのです。
それでは、次回から細部に目を転じて解説していきます。
ニュース・解説
今週の解説担当:小池邦人
Carbon ドキュメント & サンプル & SDK ナビゲーション(2004/04/23)
【開発環境】
Apple社からWWDC2004におけるカンファレンスのスケジュールが発表されました。開催までもうしばらく期間があるからなのでしょうか? 例年と比較して、TBA(To be announced …内容未定)と記されているセッションの数が多いような気がします。そうしたセッションが、現状では発表できないような新しい話題を提供するためにキープされているのなら大歓迎ですが、単にネタ不足からそうなっているだけであれば寂しいかぎりです(笑)。さて、実際はどうなのでしょう? 前号でも紹介しましたが、WWDC2004の参加費用の早期割引($300引き)は4月30日までです。参加を予定されている方は忘れないように登録いたしましょう。
http://developer.apple.com/wwdc/calendar/monday_pm.html
Absoft 社が、IBM社から発表されていた「IBM XL C/C++ Compiler for Mac OS X」の取り扱いを開始しました。USでの価格は、通常購入者の場合が $400 、政府機関の購入者で$300、教育関係者だと$200だそうです。筆者が予想していたよりも安く提供されるようです(学生に戻りたい…)。しかし、これにより「WWDC2004でXcodeへの無料バンドルが発表!」という筆者の夢は、はかなく消えてしまいました(笑)。コンパイラの仕様には、Apple社のXcodeに対応していることが明記されていますので、USでの購入者が、実際の使用感やベンチマークなどをウェブで紹介してくれると嬉しいですね。早期に日本での販売元が決まることを期待したいと思います。
http://www.absoft.com/Products/Compilers/C_C%2B%2B/XLC/XLC.html
【テクニカルドキュメント】
前回から4月23日の期間中、Apple社のDeveloperサイトにはドキュメントが5つ登録されました。すべて4月に発表された新製品に関するハードウェア仕様書です。今回でアルミ筐体のPowerBook G4は3代目です。前回の機種と比較すると、AirMacなどのオプションもディフォルトとなり、随分と価格が抑えられていることが分かります。チタン筐体のPowerBook G4も3代目は「名品」でしたので(と筆者は思う)、ポータブルマシンの買い換え時期の方は、今回が狙い目かもしれません。PowerBook G5の方は、今のところ発表される雰囲気がないようですしね(油断大敵)。
「eMac Developer Note」(PDFあり)
「12-inch PowerBook G4 Developer Note」(PDFあり)
「15-inch PowerBook G4 Developer Note」(PDFあり)
「17-inch PowerBook G4 Developer Note」(PDFあり)
「iBook Developer Note」(PDFあり)
http://developer.apple.com/documentation/index-rev-date.html
また、デベロッパ向けの読み物としてFinal Cut Proについての解説が登録されています。
「Final Cut Pro 4 Opens up with XML Interchange Format」(読み物)
http://developer.apple.com/appleapplications/fcpxml.html
前回から4月23日の期間中、新規のテクニカルノートとテクニカルQ&Aはひとつも登録されませんでした。
http://developer.apple.com/technicalnotes/index-rev-date.html
http://developer.apple.com/technicalqas/index-rev-date.html
【サンプルソースコード】
前回から4月23日の期間中、Apple社のSample Codeサイトにはサンプルソースコードが3つ登録されました。DiscRecording関連が2つ含まれていますが、今回は、3つとも新作のサンプルソースコードとなっています。
「CFHostSample」(Networking)
「DRDataBurnCarbonUI」(DiscRecording)
「DREraseCarbonUI」(DiscRecording)
http://developer.apple.com/samplecode/index-rev-date.html
【デベロップメント SDK】
前回から4月23日の期間中、Apple社のSDKサイトにはひとつもSDKが登録されませんでした。
http://developer.apple.com/sdk/
MOSAからのお知らせと編集後記は割愛します
Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
このメールの再配信、および掲載された記事の無断転載を禁じます。
http://www.mosa.gr.jp/
Copyright (C)2004-2006 MOSA. All rights reserved.