みるくCocoa

関数型言語でよく話に出てくる「副作用」。今回は、その副作用についてまとめてみる。

まず、副作用とは「別の世界に与える影響」または「別の世界から受ける影響」のことです。

int function(int a, int b);

例えば、C言語で上記のように定義された関数について、同じ値の引数なら戻り値も必ず同じになるとき、この関数には副作用がありません。おそらく、２つの引数からなんらかの演算によって戻り値を算出する内容のコードになっているのでしょう。

void action(int a, int b);

しかし、上記のように戻り値が無い関数の場合、引数として入力された値はどこへ行ってしまったのでしょうか。この関数は何もしない関数なのでしょうか。もし何か処理を行っているとすれば、その結果はどこに出力されたのでしょうか。
これが、副作用を持つ関数です。この関数の処理結果は「別の世界」へと送られたのです。

「別の世界」をもう少し具体的に言うと、「自分と平行して動作しているもの」となります。

コンピュータでは、CPU、GPU、USBコントローラ、IDEコントローラ、Audioデバイスなどが、全て同時平行的に動作しています。CPU動作中はGPUが停止してて画面が表示されない、などということはありません。
つまり、全てのI/Oデバイスへのアクセスは副作用なのです。

また、１台のコンピュータにCPUが２つあった場合、２つのCPUは平行して動作します。そして、OSのカーネルが提供するマルチプロセスやマルチスレッドなどは、仮想的なCPUを作り出すサービスです。
つまり、プロセス間通信やスレッド間通信も副作用です。

さらに、下記のようなコードを書いた場合、

int a = 3;
int b = 4;
a = a + b + 5;

変数aは、再代入によって内容を書き替えています。これは、メインメモリをデータストレージデバイスのように扱っていることになるため、これもI/Oデバイスへのアクセスと同様に副作用です。ちなみに、変数bは再代入を行っておらず、実質的に定数であると考えられるため、これは副作用にはなりません。

副作用の伴うコードは、可能な限り排除しなければなりません。なぜなら、副作用はバグの発生と大きな関係があるからです。
例えば、I/Oデバイスへの書き込みは失敗するかもしれません。また、I/Oデバイスからはどんな値が読み込まれるか完全に予測することはできません。プログラムを組む際は、これら予想外の事態に配慮しなければなりません。もし、予想外の事態に対処できなければ、これがバグという形になって表れるからです。

この予想外への対応は、副作用を含むコードと共に行われます。そして、「予想外」に対応するコードは、大抵は面倒で書くのに時間の掛かるコードです。副作用があまりにも多いコードだと、この予想外への対応が困難になります。面倒だからといってここでコードを省略すると、それがバグに繋がってしまいます。

関数型言語では副作用を特別扱いするものが多く、副作用への対処がやりやすくなっています。逆に、手続き型言語では、副作用の存在自体が見えにくく対処しづらくなっています。

あるアプリケーションで書類を開こうとしてファイルを読み込んだとき、もしそのファイルのデータが破損していた場合どうしたら良いでしょうか？

これまでは、「この書類は破損しています」とアラートパネルを表示し、書類を開く処理は失敗に終わらせる。というのが、ほとんど常識でした。そのファイルは、おそらくアプリケーションのバグなどによって、壊れた状態で最後に保存されてしまったのです。運良くバックアップでもないかぎり、もう諦めるしかありません。

ところが、MacOSX10.7の「バージョン管理」機能によって、この状況は変わります。
「運良く」ではなく、ごく日常的に書類のバックアップを取るような形になるからです。
しかし、Cocoaのデフォルトの実装では、書類を開かないと、その書類の過去バージョンにアクセスできません。バージョン管理は、書類の変更履歴を残すもので、破損したファイルを復旧させることは想定されていないのです。

でも、破損したファイルでもエラーにせず、とりあえず開けるようになっていれば、破損したファイルを救うことも可能になります。MacOSX10.7用のアプリケーションを開発する際は、このような配慮も必要になってくるのかもしれませんね。

iCloud Storageの動作を確認するべく、サンプルコードを作って見ました。

iCloud Storageを利用するには、まずそのアプリケーションを登録しなければなりません。iCloud Storage内には、アプリケーションごとに別々に領域が確保されます。
登録するには、Mac Developer Programの会員になり、メンバーセンターで登録手続きを行う必要があります。
1. アプリケーションIDの登録
2. 開発者としての証明書の登録
3. 開発モードなら、開発機の登録
4. 規定書の作成とダウンロード
ダウンロードした規定書は、システム環境設定のプロファイルとXcodeオーガナイザーのDevicesにインストールします。


Xcodeでプロジェクトを作成したら、規定書に基づいてセットアップします。
1. Summaryで、Identifierに登録したアプリケーションIDを設定
2. Summaryで、Code Sign Applicationにチェック
3. Summaryで、Enable Entitlementsにチェック
4. Summaryで、Entitlements Fileを設定
5. Summaryで、iCloud ContainersにアプリケーションIDを設定
6. Build Settingsで、規定書に対応したCode Signing Identityを設定
これでやっと準備完了です。

iCloud Storageは、iDiskと違ってファイルシステムにマウントされません。そのため、FinderからはiCloud Storageのファイルを基本的に見る事はできません。ただし、iCloud Storage内のファイルはローカルにキャッシュされるようになっており、実際にはこのキャッシュファイルを読み書きすることで、間接的にiCloud Storageのファイルをアクセスします。このキャッシュファイルは、デーモンプロセスによりiCloud Storage内のファイルと同期が取られます。

iCloud Storageにファイルを保存するには、一度ローカルに普通にファイルを書き出したあと、NSFileManagerのsetUbiquitous:itemAtURL:destinationURL:error:メソッドで、iCloud Storage（のキャッシュエリア）にファイルを移動させます。
逆に、ファイルを開くときは、NSMetadataQueryのスコープにNSMetadataQueryUbiquitousDocumentsScopeなどの値を設定して、ファイル検索を行いURLを取得します。
iCloud Storage内には自由にフォルダ（ディレクトリ）を作ることができますが、Documentsフォルダ配下に置いたファイルだけは、システム環境設定のiCloudのストレージ管理で見る事ができます。


iCloud Storageのファイルを取り扱う上で最も大変なのが、ファイルの競合解決です。これに関連して、ファイルは必ずバージョン管理しなくてはなりません。そのために、NSFilePresenterの実装と、NSFileCoordinatorやNSFileVersionの使用は不可欠です。NSDocumentには、これらのものが既に実装されていますが、今回のサンプルコードではNSDocumentを使わずに手動で実装してみました。
なお、iCloud Storageに保存されるのは、現在のバージョンのみなので、歴代のバージョンはそれぞれのデバイスのローカルに保存されるだけで同期されません。

ちなみに、一般的に「クラウドコンピューティング」というものには、インターネット全体を１台の巨大なコンピュータにするという概念があります。インターネット経由でiCloud Storageに接続された各デバイスも、この巨大なコンピュータの一部です。
そのため、実はファイルの同期どころか、ファイルの共有すらしていないことになります。１台のコンピュータが１つのファイルをアクセスしてるだけなので。当然、ファイルの競合など起こるはずがありません。
そういった背景からか、iCloud Storageのドキュメントでは、ファイルの競合は可能な限り静かに解決することが推奨されています。ユーザーに競合の解決を求めるのは最後の手段です。NSDocumentには、この最後の手段が実装されています。

今年の４月から開発を開始したMIDIWindシーケンサの今の状況はこんな感じです。

まだまだ未完成ですが、それっぽい形が出来上がってきたところです。
MIDIファイルの中身が表示されて、再生もできますが、編集機能はまだありません。

オーバーレイ・スクローラーは、MacOSX10.7で大きく変化したユーザーインターフェースの一つです。
今までNSScrollViewのdocumentViewに隣接して配置されていたNSScrollerが、documentViewの上に半透明で重ね置きされるようになりました。
このNSScrollerは、複合ビューであるNSScrollViewに含まれており、特別な苦労もなく簡単に利用することができます。しかし、特殊なスクロール環境を作るために単体でNSScrollerを使おうとすると、単純にNSScrollerをView上に配置するだけで済んでいた以前と比べて、数倍もの手間が掛かことが分かりました。

まず、スクローラーのスタイルとして「オーバーレイ」と「レガシー」が選択できるようになっています。そして、この２つのスタイルを任意のタイミングで切り替えられるようにしなければなりません。

Lionのスクローラーは必ず「オーバーレイ」スタイルになるわけではなく、入力デバイスによってスタイルが変化します。また、システム環境設定によって手動で切り替えることもできます。その際は、アプリケーションの実行中であっても、リアルタイムに設定が反映されなければなりません。例えば、MagicMouseを使っていて突然電池が切れ、普通のUSBマウスに切り替えたとき、スクローラーが隠れたままだとスクロール不能になってしまいます。

この設定変更通知を受け取るために、NSPreferredScrollerStyleDidChangeNotificationが用意されました。現在のスタイル情報は[NSScroller preferredScrollerStyle]で取得できます。

@implementation MyScrollView

@synthesize documentView, scroller;

- (id)initWithFrame:(NSRect)frame
{
  ...
  [[NSNotificationCenter defaultCenter]
    addObserver:self selector:@selector(styleChange:) 
    name:NSPreferredScrollerStyleDidChangeNotification object:nil];
  ...
}

- (void)styleChange:(NSNotification*)notify
{
  NSScrollerStyle style = [NSScroller preferredScrollerStyle];
  scroller.scrollerStyle = style;
  scroller.frame = scrollerRectForStyle(style);
  documentView.frame = documentRectForStyle(style);
  [self setNeedsDisplay:YES];
}

スタイルの変更は、スクローラーのプロパティ変更だけにとどまらず、ビューの配置変更を伴います。

このようなスタイル変更だけならまだ楽だったのですが、少し大変なのが「スクローラーを隠す」処理です。
オーバーレイなスクローラーはドキュメントの一部を覆い隠しており、そのためにドキュメントの一部は画面に表示されていても見えず、しかもマウスクリックにも反応しなくなっているのです。オーバーレイなスクローラーは、必要の無い時は隠れていなくてはならないのです。
しかし、スクローラーを隠す処理は自動的には行われません。手動で実装する必要があります。最も簡単な実装方法は-[NSView setHidden:]を使う事です。でも、もう少し本格的に実装しようとしたとき問題となるのが、スクローラーの「ノブ」と「スロット」を独立して透過処理する方法です。
オーバーレイなスクローラーは、常時隠れていて、ビューがスクロールするときのみ「ノブ」が表示され、そこでさらにマウスをスクローラーにフォーカスさせると「スロット」が表示される仕組みです。しかし、以前よりスクローラーのノブとスロットは一体もので、ノブのみを表示させるようなAPIはMacOSX10.7のリファレンスにも載っていません。

このノブとスロットの独立透過処理をプライベートな領域に片足を入れて実装すると以下のようになります。

- (void)hideSlot
{
  [NSAnimationContext beginGrouping];
  NSAnimationContext* animeContext = [NSAnimationContext currentContext];
  [animeContext setDuration:0.25];
  id animeProxy = [scroller animator];
  NSNumber* alphaValue = [NSNumber numberWithDouble:0.0];
  [animeProxy setValue:alphaValue forKey:@"overlayScrollerTrackAlpha"];
  [NSAnimationContext endGrouping];
}

これを実行すると、スクローラーのスロットのみが0.25秒かけてなめらかに透明になっていきます。"overlayScrollerTrackAlpha"の代わりに"overlayScrollerKnobAlpha"というキーを使うと、ノブとスロットを合わせた透明度をアニメーション付きで制御できます。
上記のコードは一応プライベートなAPIを一切使用していませんが、"overlayScrollerTrackAlpha"などのキーの使用を許容するかどうかで議論が分かれるかもしれません。

プライベートな領域に一切触れずに実装するなら、以下のようにNSScrollerのサブクラスを作って、drawRect:をオーバーライドしなければなりません。

@interface MyScroller : NSScroller
@property(readwrite) CGFloat knobAlphaValue;
@property(readwrite) CGFloat trackAlphaValue;
@end

@implementation MyScroller
@synthesize knobAlphaValue, trackAlphaValue;

+ (BOOL)isCompatibleWithOverlayScrollers
{
  return self == [MyScroller class];
}

- (void)drawRect:(NSRect)dirtyRect
{
  [[NSColor clearColor] set];
  NSRectFill(NSInsetRect([self bounds], -1.0, -1.0));
  CGContextRef context = [[NSGraphicsContext currentContext] graphicsPort];
  CGContextSaveGState(context);
  CGContextSetAlpha(context, trackAlphaValue);
  NSRect knobSlotRect = [self rectForPart:NSScrollerKnobSlot];
  [self drawKnobSlotInRect:knobSlotRect highlight:NO];
  CGContextSetAlpha(context, knobAlphaValue);
  [self drawKnob];
  CGContextRestoreGState(context);
}

@end

上記のコードでは、knobAlphaValueとtrackAlphaValueの２つのプロパティによって、ノブとスロットの透明度を独立して設定できるようになっています。あとは、NSAnimationを使って透明度を制御すれば、先ほどと同じようなものが実現します。
なお、NSScrollerをオーバーレイ対応でサブクラス化する場合は、上記のような形でisCompatibleWithOverlayScrollersを実装する必要があります。ここでYESを返さないと、オーバーレイは無効です。

６月から各プロバイダ一斉にIPv6のネイティブ接続サービスがスタートしました。うちのOCNもPPPoEのIPv6接続を無料のオブションサービスという形で提供を開始したので、早速申し込みしました。

それで、OCN側の工事は６月下旬には終わっていたのですが、YAMAHAのルーター(RTX1200)の対応が遅れて、やっとIPv6のPPPoE接続に対応したのが７月下旬。そこから、ルーターの設定で、いろいろ苦労があって、実際の使用開始は８月上旬となってしまいました。
まあ、別に急いでいたわけじゃないから、どんなに遅れてもいいんだけどね。

ちなみに、OCNの申込書には「別途、NTTのIPv6トンネル対応アタブタが必要です。」と書かれていましたが、YAMAHAのRTX1200があれば不要です。一応買ってしまいましたが。

それから、参考までにルーターのコンフィグはこんな感じです。

# RTX1200 Rev.10.01.32 (Wed Jul 13 17:42:17 2011)
ipv6 route default gateway pp 1
ipv6 prefix 1 2400:xxxx:xxxx:11::/64
ipv6 prefix 2 2400:xxxx:xxxx:22::/64
ipv6 vlan1 prefix 2400:xxxx:xxxx:11::/64
ipv6 vlan1 rtadv send 1 o_flag=on
ipv6 vlan2 prefix 2400:xxxx:xxxx:22::/64
ipv6 vlan2 rtadv send 2 o_flag=on
pp select 1
 pppoe use lan3
 pp auth accept pap chap
 pp auth myname xxxx xxxx
 ppp ccp type none
 ppp ipv6cp use on
 ipv6 pp secure filter in 1 2 3 4 5
 ipv6 pp dhcp service client
 pp enable 1
ipv6 filter 3 pass * * * * 546-547

設定のポイントは、

• 「ipv6 route default gateway pp 1」で、ppをゲートウエイにする。
• 「ppp ipv6cp use on」で、ipv6cpを有効にする。
• 「ipv6 pp dhcp service client」で、DHCPv6を有効にする。

といったところです。
今回は、プロバイダから/56のアドレスを固定で割当てもらっているので、LAN側のアドレスは手動で設定しています。アドレスの割当が/64の場合は、DHCPv6で受信したアドレスをそのままLAN側に割り当ててください。
ちなみに、NTTのIPv6トンネル対応アダブタだと、/64のアドレスしか対応していないようなので、今回は本当に使い物になりませんでした。

IPv4のPPPoE接続のときは、unnumbered接続だったので、ただ単純にppをゲートウエイにするだけでよかったのですが、IPv6のPPPoE接続の場合は、ppでDHCPv6を稼働させてアドレスを受信しないと正常に繋がらないようです。ppにフィルターを設定する場合はDHCPv6のパケットが通るようにポート546-547に穴を開けてください。
今回は、このDHCPv6の設定に気づかず苦労したというのもありますが、設定に気づいてDHCPv6のコンフィグを投入したのに、なぜかDHCPv6が正常に稼働しなかったため、泥沼にはまってしまいました。
ルーターの電源をOFF/ONしてもダメで、最終的にはcoldstartでルーターを初期化してからコンフィグを入れ直して、やっと正常に稼働するようになりました。

サーバーの方は、HTTPとDNSだけIPv6で見えるようにしているつもりですが、未確認です。なにぶん、IPv6の回線が１本しかないので、外部からの接続試験ができません。

非同期保存などのMacOSX10.7の新機能が気になったので、サンプルコードを作って見ました。

まず、一番簡単なのはフルスクリーンモード。単純にNSWindowのプロパティでFull ScreenをPrimary Windowに設定するだけで、ウインドウの右上にフルスクリーンボタンが付きます。


つぎに、Auto Layout。当初、XcodeではGUIでの編集がサポートされていないと思っていましたが、実はサポートされていました。しかし、分かりづらい。
.xibファイルのプロパティで、「Use Auto Layout」にチェックを入れると、レイアウトの編集が通常モードからAuto Layoutモードへと切り替わります。

Editorメニュー配下にPinメニューがが追加されて、これでNSLayoutConstraintオブジェクトが追加できるようになります。

Auto LayoutではPriorityという、そのレイアウトをどの程度強制するのかを示すプロパティの使い方がポイントのようです。例えば、自由にリサイズするビュー内部をレイアウトするとき、すべてをPriority=1000にしてしまうと、ビューのサイズが縮小し過ぎたときにレイアウトを維持できなくなる可能性があるため、実行時に警告が出たりします。

そして、自動保存とバージョン管理については、プロジェクトのテンプレートにあるように +autosavesInPlaceでYESを返すようにするだけで有効になります。

@implementation MyDocument

+ (BOOL)autosavesInPlace
{
    return YES;
}

- (IBAction)editModelObject:(id)sender
{
    [modelObject edit];
    [self updateChangeCount:NSChangeDone];
}

- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
{
    return [NSArchiver archivedDataWithRootObject:modelObject];
}

- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName 
    error:(NSError **)outError
{
    [self willChangeValueForKey:@"modelObject"];
    modelObject = [NSUnarchiver unarchiveObjectWithData:data];
    [self didChangeValueForKey:@"modelObject"];
    return YES;
}

updateChangeCount:の呼び出しにより書類の編集が検知されると、一定時間操作が無いときにRunLoopから書類の保存が起動されます。また、「保存」メニューが「バージョンを保存」に変わります。
readFromData:ofType:error:は、通常書類を開く時に呼ばれますが、書類を古いバージョンに戻す時にも呼ばれます。古いバージョンに戻すときは、開くときと違い、NSDocumentオブジェクトが新規に生成されないので、ここでdidChangeValueForKey:などを呼んでおかないと、表示が更新されません。

で、ここからが本題の非同期保存ですが、まず非同期保存を有効にするには上記のコードに加えて、canAsynchronouslyWriteToURL:ofType:forSaveOperation:でYESを返し、保存処理の中でunblockUserInteractionを呼び出す必要があります。

@implementation MyDocument

- (BOOL)canAsynchronouslyWriteToURL:(NSURL *)url ofType:(NSString *)typeName 
    forSaveOperation:(NSSaveOperationType)saveOperation
{
    return YES;
}

- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
{
    [self unblockUserInteraction];
    return [NSArchiver archivedDataWithRootObject:currentObject];
}

- (IBAction)editModelObject:(id)sender
{
    self.currentObject = [currentObject edit];
    [[self undoManager] setActionName:@"Edit"];
}

- (void)setCurrentObject:(Model*)object
{
    [[self undoManager] registerUndoWithTarget:self 
        selector:@selector(setCurrentObject:) object:currentObject];
    currentObject = object;
}

canAsynchronouslyWriteToURL:ofType:forSaveOperation:でYESを返すことによって、dataOfType:error:がメインスレッドとは別のスレッドで呼ばれるようになります。ただし、このときメインスレッドは、このスレッドにjoinするような形でブロックされているため、この時点ではまだ非同期ではありません。unblockUserInteractionを呼ぶことで、メインスレッドのブロックが解除されて、ここから非同期保存が始まります。

このように、非同期にするだけなら簡単なのですが、問題は「非同期保存中に、メインスレッドで書類が編集されたらどうするか？」です。これに対する基本戦略は、「非同期になる前に、書類のスナップショットを取る」です。unblockUserInteractionが呼ばれるまで非同期にならないのは、スナップショットを取る最後のチャンスを与えるためです。
しかし、スナップショットとは、ようするに書類全体のコピーを作る処理のことです。ここであまり処理に時間を掛けると、非同期のメリットが失われてしまいます。

今回はこれらの問題に対し、イミュータブルな戦略を試してみました。つまり、NSArrayにオブジェクトを追加する際に、-[NSMutableArray addObject:]を使わず、代わりに-[NSArray arrayByAddingObject:]を使うということです。書類を編集する全てのメソッドで、新規に生成された編集後の書類オブジェクトを返すようにしています。

@interface Model

- (Model*)addNewPerson;
- (Model*)removeAtIndex:(NSUInteger)index;
- (Model*)setNameValue:(NSString*)name atIndex:(NSUInteger)index;
- (Model*)setAgeValue:(NSInteger)age atIndex:(NSUInteger)index;
- (Model*)setCommentValue:(NSString*)comment atIndex:(NSUInteger)index;

この方法だと、実質的に常時スナップショットを取っている形になるので、保存処理でいきなり非同期にしても問題ありません。これは、平行処理に強いと言われている関数型言語で標準的に行われている方法です。

さらに、このイミュータブルな戦略を使った際の二次的な効果として、Undo処理が簡素で信頼性の高いものになるというのがあります。
CocoaのUndoは、基本的には「書類の操作履歴」です。ある操作をしたとき、それとは逆の操作をすれば元に戻るという話です。しかし、この方法には少し問題もあります。まず、Undoのために必ず対となる操作を作らなければならないこと、それから、操作を操作で打ち消す場合、書類が確実に元の状態に戻る保証がないことです。例えば、「値を３で割る」という操作を「値を３倍する」という操作で打ち消そうとしても、端数処理の関係で元の値に戻らないかもしれません。
今回のUndoは「書類の状態履歴」という形で実装しています。書類を操作したときに捨てられるはずの古いスナップショットを、Undoとして登録するだけの簡単な実装です。これだと、Undoのために対になる操作を作る必要もないし、Undoすれば確実に元の状態に戻ります。

最後に、今回スナップショットにイミュータブルな戦略を採用した結果、バインドが使いにくくなることが分かりました。そもそもCocoaではミュータブルな戦略が採用されているので、イミュータブルな戦略とはやや相性が悪いのです。しかし、「非同期」や「平行処理」をキーワードにプログラムを書くなら、イミュータブルな戦略を採用した方が有利に展開するのは、今回のサンプルコードからも明らかです。
Cocoaは最初にリリースされてからもう10年以上立ちました。そろそろ時代遅れなものになりつつあるのかもしれませんね。

MIDIWind2.1.1をリリースしました。
単純にMacOSX10.7に対応させただけで、特に追加機能はありません。また、このバージョンから動作環境が10.6以降となりました。

10.7で動作上問題となったのが内蔵のソフトシンセで、Deprecatedな古いAPIを使用するとアプリごとクラッシュしてしまいます。また、なぜかコントロールチェンジ#93（コーラスエフェクト）を送るとフリーズします。

今回のアップグレードで、Deprecatedな古いAPIを10.6の新しいAPIに書き替え、余計なコントロールチェンジを送信しないようにフィルターを施しています。

OSをMacOSX10.7(Lion)にアップグレードしました。
そして、またしてもMIDIWind2.1の一部の機能が動かなくなりました。

ソフトシンセで再生しようとすると、アプリケーションが予期せず落ちてしまいます。
幸い外部音源の再生は問題なくできるようです。

MIDIWind2.1はMacOSX10.4がターゲットで、ソフトシンセ周りでDeprecatedなAPIを使っていて、このAPIがLionで使用不能にならないことを祈っていたのですが、残念ながらその祈りはAppleには届かなかったようです。
これから、10.7対応に修正する予定です。

MacOSX10.7でも新しいAPIがいろいろ追加されていますが、ジェスチャー・フルスクリーン・自動保存＆バージョンなんかが大きなところかな。まだ詳しく見ていないが、自動保存に伴う「非同期保存」の実装が少し気になるところだ。保存中にデータを書き換えたらどうなるんだろうか？　あと、CoreDataの自動保存ってどうなるんだろ？　自動保存関連の機能追加が無いように見える。
その他にも、TableViewでCellの代わりにViewが使えるようになった。今まではMatrixを使った実装だったので同じcellを並べることしかできませんでしたが、Viewだと行ごとに違うものを使ったりとか出来るっぽい。単純にデータをリスト表示するのとは違うものが作れそうだ。
それから、新しいViewのレイアウト機能が追加された。でも、Xcodeが対応していないっぽく、コードを書いてレイアウトしなきゃならないっぽい。なんか不便だ。

テストにはテスト内容に応じていろいろな種類や方法がありますが、オブジェクト単位のシンプルな機能テストと言えばxUnitなどを使うユニットテストがあります。オブジェクトに何かを入力したときの出力を検査することで、オブジェクトの機能をテストするというものです。

MVCパターンに基づいてコードを書いている場合、Modelが最もテストし易いコンポーネントになります。Modelは他のコンポーネントに依存しない形になっているので、テストプログラムに組み込むことも簡単なのです。
逆に、ViewやControllerはテストしにくいコンポーネントです。まあ、ViewやControllerに限らず、I/O処理を含むコードのテストはModelであっても困難です。ただModelであればまだ手段がありますが、特にViewに関してはグラフィックの描画という部分がOSに結び付いているため、この部分のテストを行うのは非常に困難です。

でも、だからといってViewをテストしないわけにも行きません。
まず最初に考えたのは、グラフィックの描画そのものをテストすることはできないが、描画に使用するパラメータならテストできるのではないか、という事です。例えば、NSRectFill()で塗りつぶす時に矩形の座標情報がパラメータとして必要になります。塗りつぶした結果はテストできないかもしれませんが、矩形の座標情報ならテスト可能ですし、それをテストすれば塗りつぶした結果を間接的にテストしたことになるのでしょう。
しかしこの方法はうまく行きませんでした。なぜなら、Modelの場合は「テストに合格するコードが良いコード」だったのに対し、Viewの場合は「見栄えの良いグラフィックを描画するコードが良いコード」だからです。グラフィックは実際に画面に表示させて見ないと評価できません。座標情報を前もって決めておくことは困難なのです。

このように、グラフィックの描画がViewの主要機能であるにもかかわらず、それをテストすることが現実的ではないとすると、そもそもViewの何をテストすればいいのでしょうか。いろいろ考えた結果、おそらく以下のようなものがテストの対象になるのでしょう。

・ViewがModelオブジェクトにアクセスできるか？
・ViewがModelオブジェクトからの通知を受け取れるか？
・ViewがNSEventを受け取りTarget/Actionを発行できるか？

しかし、これはこれで難しいデストです。通常ユニットデストでは、あるものを入力したときの出力をテストしますが、上記のような場合は出力されるものがありません。そこで、これをテストするために、以下のような方法を考えました。

@interface TestView : MyView {
  NSMutableArray* log;
}
@property(retain) NSMutableArray* log;

@end

@implementation TestView

@synthesize log;

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object 
  change:(NSDictionary *)change context:(void *)context {
  [log addObject:@"observeValueForKeyPath"];
  [super observeValueForKeyPath:keyPath ofObject:object
    change:change context:context];
}

- (void)setNeedsDisplay:(BOOL)flag {
  [log addObject:@"setNeedsDisplay"];
}

@end

@implementation MyTestCase

- (void)testKeyValueObserv {
  MyModel* model = [[MyModel alloc] init];
  TestView* view = [[TestView alloc] initWithFrame:NSZeroRect];
  [view bind:@"content" toObject:model withKeyPath:@"self" options:nil];
  view.log = [[NSMutableArray alloc] init];
  [model setValue:@"hoge" forKey:@"boke"];
  STAssertEqualObjects(
    [view.log objectAtIndex:0], @"observeValueForKeyPath", nil);
  STAssertEqualObjects(
    [view.log objectAtIndex:1], @"setNeedsDisplay", nil);
}

@end

これは、テスト対象のViewオブジェクトに、メソッド呼び出しのログを取る機能を追加して、ユニットテストを行うという方法です。このテストにより、Modelオブジェクトのプロパティが変化したときに、Viewがその通知を受け取って再描画しようとしている動きをテストできます。

メソッドの呼び出しがログという形で出力されるので、通常のユニットテストでもテスト可能になります。また、上記の例ではsetNeedsDisplay:の呼び出しでsuperを呼んでいないので、実際にグラフィックの描画というI/O処理が発生しません。

これにより、Viewのテストができる見通しがたったものの、メソッドのログを取るためにいちいちサブクラスを書くのはちょっと面倒。でも、このようなことは、アスペクト指向を使えば簡単なのですが、残念ならがObjective-Cにはアスペクト指向の実装がありません。昔は、あったらしいですけどね、なんとなく復活してくれるとうれしいです。