Takebayashi.Asia

ビューベースのNSTableViewで行の高さを設定する

2012-01-27T00:10:00+09:00

ビューベースのNSTableViewでは、セルビューや行ビューとして複数の種類のビューを使い分けることができます。例えば、下のコードではデータソースに文字列と画像を混在させ、文字列であればNSTextFieldを、画像であればNSImageViewをセル内に表示させます。

@interface TableDataSource : NSObject <NSTableViewDataSource, NSTableViewDelegate>
@end

@implementation TableDataSource {
    NSArray *_items;
}

- (id)init {
    self = [super init];
    if (self) {
        _items = [NSArray arrayWithObjects:
                  @"Hello",
                  [NSImage imageNamed:@"NSApplicationIcon"],
                  @"World",
                  nil];
    }
    return self;
}

- (NSInteger)numberOfRowsInTableView:(NSTableView *)tableView {
    return [_items count];
}

- (NSView *)tableView:(NSTableView *)tableView viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row {
    id item = [_items objectAtIndex:row];
    NSTableCellView *view;
    if ([item isKindOfClass:[NSString class]]) {
        view = [tableView makeViewWithIdentifier:@"TextRow" owner:self];
        view.textField.stringValue = item;
    }
    else if ([item isKindOfClass:[NSImage class]]) {
        view = [tableView makeViewWithIdentifier:@"ImageRow" owner:self];
        view.imageView.image = item;
    }
    return view;
}

@end

XIBはこんな感じ。文字列用のセルビューは小さめ、画像用のセルビューは大きめにしました。

ところが、これを実行すると、文字列用と画像用のセルビューの高さが一緒になってしまいます。

どうやら、XIB上でのセルビューの高さは無視されて（というより-tableView:viewForTableColumn:で返したビューの高さを無視して）、全てのセルビューの中で最も大きい高さのものに勝手に揃えられてしまうようです。

これでは困るので、-tableView:heightOfRow:を実装して行ごとの高さを返すことにします。先ほどのコードを次のように書き換えました。

@implementation TableDataSource {
    NSArray *_items;
    NSMutableDictionary *_heights;
}

- (id)init {
    self = [super init];
    if (self) {
        _items = [NSArray arrayWithObjects:
                  @"Hello",
                  [NSImage imageNamed:@"NSApplicationIcon"],
                  @"World",
                  nil];
        _heights = [NSMutableDictionary dictionary];
    }
    return self;
}

- (NSInteger)numberOfRowsInTableView:(NSTableView *)tableView {
    return [_items count];
}

- (NSView *)tableView:(NSTableView *)tableView viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row {
    id item = [_items objectAtIndex:row];
    NSTableCellView *view;
    if ([item isKindOfClass:[NSString class]]) {
        view = [tableView makeViewWithIdentifier:@"TextRow" owner:self];
        view.textField.stringValue = item;
    }
    else if ([item isKindOfClass:[NSImage class]]) {
        view = [tableView makeViewWithIdentifier:@"ImageRow" owner:self];
        view.imageView.image = item;
    }
    return view;
}

- (CGFloat)tableView:(NSTableView *)tableView heightOfRow:(NSInteger)row {
    id item = [_items objectAtIndex:row];
    if (!_heights) {
        _heights = [NSMutableDictionary dictionary];
    }
    NSString *identifier = [item isKindOfClass:[NSString class]] ? @"TextRow" : @"ImageRow";
    NSNumber *height = [_heights objectForKey:identifier];
    if (!height) {
        NSView *view = [tableView makeViewWithIdentifier:identifier owner:self];
        height = [NSNumber numberWithDouble:view.bounds.size.height];
        [_heights setObject:height forKey:identifier];
    }
    return height.doubleValue;
}

@end

実行結果

少し強引ですが、一度ビューを実際に生成してみて、その高さを保持するようにしています。もう少しスマートな方法がありそうな気がしますが、今回はとりあえずこれで行くことにします。

Readabilityの非公開API

2011-12-25T00:46:00+09:00

気になるブログエントリとかを読みやすく整形してくれるみんな大好きReadability。自分のアプリに組み込めるようにAPIも公開されています。が、API Docsの冒頭に次のような一文が。

All requests to the Readability service require access tokens.

認証マストですって。OAuth。わざわざページを読みやすくするためだけにOAuth認証なんてやってられません。現にみんな大好きReederは認証しなくてもReadabilityによる整形が可能じゃないですか！

というわけで、認証せずに使えるReadabilityの非公式なAPIをご紹介します。認証せずにページを整形するには、次のような手順を踏めば良いみたいです。

CSRFトークンを取得
記事IDとセッションIDを取得
整形済みドキュメントを取得

こんな感じですね。ではもう少し詳しく書いていきます。

CSRFトークンを取得

こいつがないとリクエストを撥ねられます。http://www.readability.com/shortenにGETリクエストを投げると、csrftokenという名前のCookieを返してきます。

記事IDとセッションIDを取得

http://www.readability.com/~/にPOSTリクエストを送ります。このとき、さきほど取得したcsrftokenをCookieフィールドにセットします。加えて、X-CSRFTokenというヘッダも用意して、ここにもcsrftokenの値をセットします。リクエストボディはurl={記事URL}といった感じです。

するとレスポンスにsessionidというCookieを返してきます。レスポンスボディは次のようなJSONです。

{
  "article": {
      "url": "/articles/srfhrcfs",
      "domain": "ja.wikipedia.org",
      "excerpt": "Cocoa&#65288;&#12467;&#12467;&#12450;&#65289;&#12399;&#12289;Mac OS&hellip;",
      "title": "Cocoa"
  },
  "shortened_id": "srfhrcfs",
  "success": true,
  "original_url": "http://ja.wikipedia.org/wiki/Cocoa"
}

ここで、shortened_idが記事IDです。

整形済みドキュメントを取得

あとはhttp://www.readability.com/articles/{shortened_id}にsessionid CookieをつけてGETリクエストを送れば整形されたドキュメントとして返ってきます。

まとめ

微妙に面倒くさいし、そもそも公式に用意されたものではないので、at your own riskで。いつ使えなくなってもおかしくないですよね。

一応、サンプルコード（Cocoa）をGitHubにおいておきました。

ARCでweak参照が使えないクラスについて：NSWindowとか

2011-12-23T23:57:00+09:00

ARC便利ですよね。オブジェクトの確保や解放に関するコードがなくなるので全体の見通しが良くなってスッキリしますよね。え、GC？知らん。

で、ARCを有効にするとweak参照な変数が使えます。旧来のassignプロパティと同じような弱い参照なわけですが、参照先のオブジェクトが解放されると自動的にnilになってくれるイカしたやつです。便利ですね。

このweak参照、実はすべてのオブジェクトに使えるわけではありません。例えば、以下のようなプロパティを用意したとします。

@property (weak) IBOutlet NSWindow *window;

ウインドウへの参照をアウトレットとして持とうとしているわけですね。しかしこのプロパティを含むコードを実行すると、以下のようなメッセージが出力されます。

objc[2242]: cannot form weak reference to instance (0x100410770) of class NSKVONotifying_NSWindow

NSKVONotifying_NSWindowってのはCocoaのKVOシステムが勝手に作ったNSWindowのサブクラスなので、ここでは要するにNSWindowはweak参照できねーよって言われています。

実は、ARCでは-allowsWeakReferenceというメソッドを定義してNOを返すようにするとweak参照ができなくなります。NSWindowのオブジェクトもNOを返してくるのでさっきのようなエラーが出たわけですね。

weak参照を禁止する場面としては、MRCなライブラリで独自のメモリ管理をしていて、それをARCなアプリから使われるときなんかがあるでしょうか。AppleのTransitioning to ARC Release Notesでも、retain/releaseを改変している場合はweak参照を禁止すべきであると示されています。ちなみにこのドキュメントでは-supportsWeakPointersでNOを返せと書かれていますが、これはドキュメントの誤りです。

というわけで、weak参照を禁止されたオブジェクトに対しては、かわりにunsafe_unretained参照を用いましょう。冒頭のプロパティは次のように修正します。

@property (unsafe_unretained) IBOutlet NSWindow *window;

もちろん、この場合は自動nil化が行われないのでMRC同様の注意が必要となります。

もう1つのCocoaライブラリ管理ツール：VendorKit (2) ライブラリの登録

2011-12-09T11:13:00+09:00

前回のポストでVendorKitの使い方について軽く紹介しました。今回は自作のライブラリをVendorKitに登録する方法を紹介します。

VendorKitにライブラリを登録するには、.vendorファイルをvendorkit.comに送信する必要がありますが、それにはまず.vendorspecファイルを作成します。

# .vendorspecのひな形を生成
$ cd path/to/project
$ vendor library init

次に、生成された.vendorspecファイルを編集します。ここでは、STCollectionを例にします。

STCollection.vendorspec

Vendor::Spec.new do |s|
  # ライブラリの名前とバージョン
  s.name         "STCollection"
  s.version      "1.0.0"

  # ライブラリの作者名と説明
  s.authors      "takebayashi"
  s.description  "Useful categories for Cocoa collection classes"

  # ソースの公開場所
  s.source         "https://github.com/takebayashi/STCollection"

  # ライブラリに含まれるファイル
  # （ここでは全ファイルを含めていますが、そうでない場合もあるでしょう）
  s.files        `git ls-files`.split("\n")

end

どこかで見たことのあるような書き方ですね。さて、次は.vendorファイルを作成しましょう。

$ vendor library build STCollection.vendorspec

するとSTCollection-1.0.0.vendorというファイルが作成されるので、これを次の方法で送信すれば登録が完了します。

$ vendor library push STCollection.vendor

登録したライブラリはVendorKitのサイトに公開されます。

もう1つのCocoaライブラリ管理ツール：VendorKit

2011-12-06T09:08:00+09:00

Cocoaでのライブラリ管理といえばCocoaPodsが有名（？）ですが、もうひとつVendorKitというものがあります。Vendorfileというファイルに依存するライブラリを記述しておくことで、あとはVendorKitが自動的にプロジェクトに追加してくれます。ちょうどRubyのBundlerとGemfileのような関係ですね。

といわけで、そのVendorKitの使い方をご紹介します。

インストール

$ gem install vendor

使い方

# プロジェクトのあるディレクトリに移動
$ cd path/to/xcode_project

# Vendorfileを作成
$ echo 'lib "Reachability"' > Vendorfile

# 依存性を解決
$ vendor install

これだけです。簡単ですね。試しにXcodeでプロジェクトを開いてみると、ちゃんとReachabilityが追加されていました。こんな感じで、Vendorfileに依存するライブラリ（vendorって言うらしいですよ）を書いておけば、vendor installするだけでOKです。

ちなみに、vendor initとするとVendorfileのひな形を自動生成してくれるんですが、あろうことか存在しないvendorを指定してくれているのでインストールに失敗します。なんじゃそりゃ。

ちなみにVendorfileの書式はドキュメントにあります。基本的にはlib "vendor-name"とするだけですが、Gemfileライクな記法によるバージョン指定などもできます。

問題があるとすれば、今のところやや不安定なところがあるところと、登録されているvendorsが少ないことでしょうかね。今後に期待したいところです。

OCUnitで非同期ブロックをテストしたい

2011-12-06T00:55:00+09:00

Snow Leopardあたりから登場したObjective-C Blocks（ブロック）、非同期処理に大活躍してますよね。ネットワーク周りの処理なんかはこれなしではやってられないと言っても過言ではないと思います。

しかしこのブロック（ていうか非同期処理全般だけど）、OCUnit（SenTesting）でなかなかテストしづらいんですよね。たとえば次のテストを実行したとします。

- (void)testAsyncBlock {
  [foo processSomeTasksWithCompletionHandler:^(id result) {
    STAssertNotNil(@"（アカン）");
  }];
}

このテスト、非同期処理の結果を受け取るブロックのなかでその結果がnilかどうかをテストしたいわけですが、残念ながらうまくいきません。非同期処理が終了する前にテストが終了してしまうので、resultの内容によらずにテスト全パスです。これじゃ困るので、非同期処理が終わるまでテストを終わらせないようにします。

- (void)testAsyncBlock {
  __block isFinished = NO;
  [foo processSomeTasksWithCompletionHandler:^(id result) {
    STAssertNotNil(@"（アカン）");
    isFinished = YES;
  }];
  while (!isFinished) {
    [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:0.5]];
  }
}

終了したかどうかを判定するためにフラグを用意するという非常に原始的な方法ですが、これで一応ちゃんとテストできるようになりました。ただ、これを毎回書くのは面倒なので、ちょっとだけ楽にするマクロを書きました。

#define STAsynchronousTestStart(identifier) __block NSUInteger STAsynchronousTest_ ## identifier = 1 #define STAsynchronousTestDone(identifier) STAsynchronousTest_ ## identifier -= 1 #define STAsynchronousTestWait(identifier, interval) while (STAsynchronousTest_ ## identifier > 0)\ [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:(interval)]] #define STAsynchronousTestSetCount(identifier, count) STAsynchronousTest_ ## identifier = count

- (void)testAsyncBlock {
  STAsynchronousTestStart(test1);
  [foo processSomeTasksWithCompletionHandler:^(id result) {
    STAssertNotNil(@"（アカン）");
    STAsynchronousTestDone(test1);
  }];
  STAsynchronousTestWait(test1, 0.5);
}

// ネストしたブロック
- (void)testAnotherAsyncBlock {
  STAsynchronousTestStart(test2);
  [foo processOtherTasksWithCompletionHandler:^(NSArray *array) {
    STAsynchronousTestSetCount(test2, [array count]);
    for (id obj in array) {
      [bar processObj:obj completionHandler:^(id result) {
        STAssertNotNil(@"いかんのか？");
        STAsynchronousTestDone(test2);
      }];
    }
  }];
  STAsynchronousTestWait(test2, 0.5);
}

あまり変わらない？ほんのちょっとだけコードが見やすくなったような気がしますよ。

ブログを新しくしました

2011-12-06T00:26:00+09:00

ブログを新しく作りました。

今までBloggerで書いたり書かなかったりしてきたんですが、すこし気分転換もかねてこっちのドメインでブログを運用していくことにしました。

ちなみにOctopress + Herokuという構成だったりします。