ページ

2010年1月10日日曜日

今週のCocoa情報(1/10) - 今週気になった Cocoaプログラミング情報の紹介

このエントリーをブックマークに追加 このエントリーを含むはてなブックマーク

 Detect CPU Architecture (32-bit / 64-bit) runtime in Objective C (Mac OS X) - Stack Overflow  

32bit/64bit アーキテクチャを実行時に検出するには?



 Pros and Cons of Listener/Observer approaches to notify Model changes - Stack Overflow 

Delegation, NSNotification, KVO の長所と短所が解説されている。

Delegation:
◯ 単一オブジェクトへの通知、プロトコルを使うと使い方が明確
× クラッシュとメモリーリークの原因となる

NSNotification:
◯ 複数オブジェクトへの通知、疎結合
× 通知は同期式、ドキュメントで詳しい説明が必要

KVO:
◯ (記述なし:コード量が減るなどか)
× 利用方法が不明瞭


Delegateのメモリリークと関連して iPhoneでのメモリ管理の記事が紹介されていた。
10 iPhone Memory Management Tips | akosma software
delegate は retainではなく assign にするのがいい、など。

スライドもある。
Open Kosmaczewski - iPhone Memory Management Tips (Slides, 2009)
iPhone 向けだが、ソースコードで説明されているのでわかりやすい。眺めているだけで参考になる。


このブログ内にはメモリ管理に関する情報がいろいろあって参考になる。
Clang Static Analyzer

Debugging memory based crashes on iPhone | iPhone | Lou Franco: personal site

デバッグオプションなどの紹介
NSAutoreleaseFreedObjectCheckEnabled
NSZombieEnabled
NSDebugEnabled

Xcode の Runメニューに "Enable Guard Malloc" があるのを初めて知った。


ちなみに "Pros and Cons" は日本語だと、「良い点、悪い点」の意。

(参考)"pros and cons"、"nature and nurture"とはどういう意味か?: 英語の時間 - へっぽこVersion



 Custom Mac Scrollbars With Cocoa - Stack Overflow 

スクロールバーのカスタマイズの仕方。



Google Objective-Cスタイルガイド 日本語訳 | textdrop

Google のコーディングスタイルガイド。参考になった。
気になった箇所を転載。


autorelease してから retain する

 オブジェクトの代入は、autorelease してから retain するというパターンに従うこと。
link新しいオブジェクトを変数に代入するときには、メモリリークを起こさないように最初に古いオブジェクトを解放する必要がある。これには「正しい」やり方がいくつかある。私たちは「autorelease してから retain する」という方法を選んだ。間違いにくいためだ。タイトなループでは、autorelease pool がいっぱいになり、効率が少し悪くなることに注意しよう。それでも私たちはこのトレードオフは許容できると考えた。

- (void)setFoo:(GMFoo *)aFoo {
  [foo_ autorelease];  // Won't dealloc if |foo_| == |aFoo|
  foo_ = [aFoo retain]; 
}

ほー。

セッタではNSStringをコピーする

 NSString を引数に持つセッタは、受け取った文字列を常に copy するべきだ。
link文字列を retain するだけでは不十分だ。文字列をコピーすれば、呼び出し元が知らないうちに文字列を変更してしまうことを避けることができる。実際には NSMutableString ではなく NSString を受け取っているから大丈夫だ、と考えてはいけない。

- (void)setFoo:(NSString *)aFoo {
  [foo_ autorelease];
  foo_ = [aFoo copy];
}

なるほど。
関連してプロパティでも:

文字列には copy 属性を使うこと
NSStringプロパティには常に copy 属性を宣言しておくべきだ。

プロパティアクセスについて:

ドット記法
以下の理由から、ドット記法を使ってプロパティにアクセスすることを禁止する。

  1. ドット記法は標準的なメソッド呼び出しに対する純粋なシンタックスシュガーであり、読みやすいかどうかには異論もある。単なるメソッド呼び出しの別の方法にすぎない。
  2. こうするとデリファレンスしている型がわかりにくくなる。[foo setBar:1] というのをみれば、Objective-Cのオブジェクトを操作しているとすぐにわかる。しかし、foo.bar = 1 というのをみても、fooがオブジェクトなのか、構造体や共用体なのか、C++のクラスなのかわからない。
  3. ゲッタであるかのようなメソッド呼び出しができてしまう。
    NSString *upperCase = @"foo".uppercaseString;
    これは混乱させるだけでなくコードレビューで問題を見つけにくくする。
  4. メソッド呼び出しを隠してしまう。
    bar.value += 10;
    実際には2つの異なるメソッド(setするメソッドとgetするメソッド)が呼び出されている。もしプロパティが単純なものでなければ、裏でたくさんの処理が行われることになる。


確かに(それは感じた)。

Delegateパターン

 Delegateオブジェクトを retain するべきではない。
linkDelegateパターンを実装するクラスは次のようにしておくべきだ。

  1. delegateを参照する delegate_ という名前のインスタンス変数を用意する。
  2. そして、アクセサメソッドは deletate と setDelegate: という名前にする。
  3. delegate_ オブジェクトを retain するべきではない。

ここでも retainの件が触れられてる。



Performing Method on background thread with NSNotification - Stack Overflow


Mac Dev Center: NSObject Class Reference - performSelectorInBackground:withObject:



MOONGIFT: » SQLite3を暗号化「SQLCipher」:オープンソースを毎日紹介

iPhoneアプリでも使われているとのこと。



What is the PastryKit Framework? - Stack Overflow

iPhone向け Webアプリ開発用 JavaScriptフレームワーク(Apple製?)

Safari4 の開発メニュー/ユーザエージェントで iPhone を選び次のページへアクセスすると iPhone用の画面が表示される。
Apple - Support - Manuals

こんな感じ。


この画面で PastryKit を使っているらしい。