テキストフィールドにフィルタをかけたるアニメーションを実装したいと思ったのですがなかなか思う通りにできません。みるくCocoaさんのサンプルにまさにコレ！というのがあったので早速試したのですが、デフォ0.25秒の動きが早すぎるのかどうしてもアニメーションしているようには見えませんでした。本家アップルの例のように、

CABasicAnimation *theAnimation =
  [CABasicAnimation animationWithKeyPath:@"filters.myGussian.inputRadius"];

theAnimation.duration            = 10;
theAnimation.fromValue           = [NSNumber numberWithFloat:5.0];
theAnimation.toValue             = [NSNumber numberWithFloat:0.0];
  
[[answerField layer] addAnimation:theAnimation forKey:@"filterAnimation"];

のように書き直しても動く気配なし。そもそもCore ImageとかCore Animationとか全然わかっていないのでコードの断片だけを拾い集めてきてもうまくいくはずもなく、アニメーションはあきらめて

if ([text wantsLayer])
{
  [text setWantsLayer:NO];
  [text setContentFilters:nil];
  return;
}
CIFilter *filter = [CIFilter filterWithName:@"CIGaussianBlur" keysAndValues:
                   kCIInputRadiusKey, [NSNumber numberWithFloat:2.5], nil];
[text setContentFilters:[NSArray arrayWithObject:filter]];
[text setWantsLayer:YES];

として、フィルタの適用をオン・オフだけするだけの実装にしてごまかして（実際これだけでも十分なんですが...）Core mage/Core Animation周りを勉強し直すことにしました。というわけで、これをポチ。

Core Animation for Max OS X and the iPhone: Creating Compelling Dynamic User Interfaces (Pragmatic Programmers) Bill Dudney Pragmatic Bookshelf 2008-10-15 売り上げランキング : 17174 Amazonで詳しく見る by G-Tools

このところまたOutlineView+TreeControllerやってます。それでひとつ気づいたことをメモ。

"ツリーコントローラーにストアしているデータをすべてinsertしてもツリー構造にはならない"ということ。読み込んだ子ノードのデータをTreeControllerにinsertすると（親ノードの配下にも表示されますが）親ノードと兄弟のように表示されちゃいますね。ググってみたら、Fetch Predicateに”parent == nil"を指定する（cocoadev:NSTreeController）のが慣例みたいなんですが知りませでした。データの読み込みを確認しながらようやくわかった次第。要するに親ノードが持っている子ノードの展開はTreeControllerが内部で実行することになっているようでプログラムからは親ノードさえadd/insertしてやれば良いようです。当然バインドの場合でも上記の例のようにPredicateを指定する必要があるようです。（Appleの公式ドキュメントとしてどこかに書かれているのかな？）

NSManagedObjectContext *moc = [self managedObjectContext];
NSFetchRequest *fetch = [[[NSFetchRequest alloc] init] autorelease];
NSArray* sortDesc = [NSArray arrayWithObject:
  [[[NSSortDescriptor alloc] initWithKey:@"orderNo" ascending:YES] autorelease]];

[fetch setEntity:
  [NSEntityDescription entityForName:@"ChildNodeEntity" inManagedObjectContext:moc]];
[fetch setPredicate:[NSPredicate predicateWithFormat:@"isLeaf == 0"]];
[fetch setSortDescriptors:[self sortDesc]];

NSError *err     = nil;
NSArray *results = [moc executeFetchRequest:fetch error:&err];
if ((err) || (results == nil))
{
  [NSApp presentError:err];
  return;
}

NSUInteger index = 0;

for (ChildNodeEntity *node in results)
{
  [treeController insertObject:node atArrangedObjectIndexPath:
    [NSIndexPath indexPathWithIndex:index]];
  index = index + 1;
}

まあ、実際にやりたかったのはノードの表示順を一定に保つことでCocoaDevのリンクnstreecontroller-and-core-data-sortedにもあったようにノードの中になんらかの方法で順序を示す数値を仕込んでおけばOK。子ノードの展開はTreeControllerお任せになるのでSortDescriptorをバインドする必要もあります。ロード時に特別の処理がなければ僕のコードのようにガリガリコードを書くのは不作法で、やっぱりバインドしたほうがスマートですね。

既存のマッピングで対応できないような場合、NSEntityMigrationPolicyを拡張してカスタマイズできることはわかったのですがドキュメントを読むだけではいまひとつピンとこなかったので実際にやってみました。トライしたのは下記のアドレス帳モデルの変換。とりあえず、v1のモデルで固定・携帯の２つの電話を持つ桃太郎、携帯電話のみを持つ浦島太郎、電話は持たない一寸法師のアドレス帳データを作成しこれをv2モデルに変換します。マイグレーションの骨子は、

1. 電話を持たない人はそのまま新しいAddressBookエンティティにマッピング
2. 電話を持つ人はPhone1/Phone2をPhoneBookエンティティにマッピング

の２点。１に関しては通常のマッピングで対応し、２に関してマイグレーションポリシーを拡張します。

まず、v1のAddressBookエンティティにあるphone1とphone2をPhoneBookエンティティに移行するため新しいマッピングを適当な名前で作成します。ここではAddressBookToPhoneBookという名前のマッピングモデルを作成しました。ソースにはAddressBook、デスティネーションにはPhoneBookを指定します。また、電話を持たないAddressBookインスタンスはPhoneBookへのマッピングは不要なのでフィルタ述語に

NSTaskでスクリプトを実行する時、${HOME}/Libray/Apprication\ Supportでも実行できるか不安だったので念のため試してみたところちゃんと実行できました。いや、単にパス名にスペースが含まれているから実行できるか不安だっただけですが...（MacOSXには"Program\ Files"的なものはないかと思っていましたがあるんですね。)

- (void)setCurrentDirectoryPath:(NSString *)pathで移動してやればOK。Cocoaはやっぱり! - Perlスクリプトを実行するに詳しいです。これまでtemporaryディレクトリなんかを使ってやっていたんですが、ここを使えば競合なんかの心配が限定できるのでじゃかじゃかやれます。Core Dataのデフォルト保存パスがここになっていることでようやくこのテに気がつきました。日本語を含むディレクトリでも正しく起動できました。ま、カレントディレクトリを変えちゃうんだから当たり前なんだけど、Winじゃ"Program\ Files"とか"My\ Document"とか痛いことあるし...

Cocoaでリソース関連をローカライズするにはIBで日本語なら日本語のリソースを作ってやればいいのだけれどアプリケーションの名称はこれではローカライズできません。

clippyのエイリアスに日本語ファイル名を指定すると読み込めないというバグがありました。自分では滅多に日本語ファイル名などというのは使わないので全然ノーマーク。

NSString:stringWithContentsOfURL:encoding:errorを使って読み込みする際、読み込むファイルのNSURLを単純に生成してました。

NSString *contents = 
  [NSString stringWithContentsOfURL:[NSURL URLWithString:filename] 
  encoding:NSUTF8StringEncoding error:&err];

これだとNSURL:URLWithStringはnilを返しますが、なんのチェックもなしです。(^^ゞなんでもかでも一行に納めるとこういう場合がきつい。ちゃんと２ステップ踏んで、fileスキームもちゃんとエスケープしないとダメですね。

NSURL    *url = [NSURL URLWithString:
  [filename  stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]];
NSString *contents = 
  [NSString stringWithContentsOfURL:url encoding:NSUTF8StringEncoding error:&err];

便利なものがあって助かりました。しかし、どうせならエスケープするというのをデフォルトにすればいいのになぁ。などと少し思ったりもします。

以前作成したアプリをv10.6SDKベースでコンパイルしたら警告がでました。何でかなーと思って調べてみるとアプリケーションで使用しているNSRuleEditorのdelegateメソッドがNSRuleEditorDelegateプロトコルに昇格（？）していました。なので、delegateメソッドを実装するクラスは<NSRuleEditorDelegate>しなければいけませんでした。ドキュメント10.6 Symbole Changesを見てみるとNSWindowはじめ多くのdelegateがプロトコル化されていることがわかります。

Objective-C 2.0でプロトコルでもオプション指定ができるようになったので、カテゴリ（非形式プロトコル）定義されていたデリゲートが形式プロトコル化されるのは自然な流れかもしれません。これまではよほど大量のデリゲートメソッドを実装するのでなければ、コントローラクラスの片隅にチョコっとデリゲートメソッド実装していましたが、オブジェクトの独立性や保守性を考えれば、今後はきちんとデリゲート用のクラスを作成するという方向になっていくのでしょう。

デリゲートといえば、前エントリでは嬉々としてデリゲート便利！などと騒いだ手前恥ずかしいのですが、冷静になってみるとInvoke(delegate)はやっぱり単なる「関数ポインタ」と言ったほうがいいのじゃないかと思ったりしてます。設計上の理由によりメソッドの実装を”他オブジェクトに譲（ってもいい｜るべきだ）”とすることをデリゲートと呼ぶのであって、たとえばコールバックでの関数ポインタの代替として（文法上）のデリゲートとは意識的に分けて考えたほうが正しいあり方のように思います。

前回のエントリで書いたようにNSRurleEditorではルールを作成に際してDelegateメソッドを通じて細かい制御をおこなうことができます。必須のDelegeteメソッドは３つ、

1. ruleEditor:numberOfChildrenForCriterion:withRowType:
2. ruleEditor:child:forCriterion:withRowType:
3. ruleEditor:displayValueForCriterion:inRow:

NSRuleEditorのaddRowメソッド呼び出しのタイミングで左辺・述部・右辺についてそれぞれ呼び出されます。今回のサンプルで言えば初回時（ルート）では price/color/sizeの３つの選択肢があるので返す数は３。NSRuleEditorではこの数に基づいて、ruleEditor:child:forCriterion:withRowType:メソッドが３回呼び出します。このメソッドでは左辺３つの情報をNSDictionary形式にパックして返します。パラメータchild:(NSInteger)indexで表示位置を指定してきますのでindex(0)でpriceの情報を、index(1)でcolorの情報・index(2)でsizeの情報を返します。