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
属性を宣言しておくべきだ。
ドット記法以下の理由から、ドット記法を使ってプロパティにアクセスすることを禁止する。
- ドット記法は標準的なメソッド呼び出しに対する純粋なシンタックスシュガーであり、読みやすいかどうかには異論もある。単なるメソッド呼び出しの別の方法にすぎない。
- こうするとデリファレンスしている型がわかりにくくなる。
[foo setBar:1]
というのをみれば、Objective-Cのオブジェクトを操作しているとすぐにわかる。しかし、foo.bar = 1
というのをみても、fooがオブジェクトなのか、構造体や共用体なのか、C++のクラスなのかわからない。- ゲッタであるかのようなメソッド呼び出しができてしまう。
NSString *upperCase = @"foo".uppercaseString;これは混乱させるだけでなくコードレビューで問題を見つけにくくする。
- メソッド呼び出しを隠してしまう。
bar.value += 10;実際には2つの異なるメソッド(setするメソッドとgetするメソッド)が呼び出されている。もしプロパティが単純なものでなければ、裏でたくさんの処理が行われることになる。
確かに(それは感じた)。
ここでも retainの件が触れられてる。
Delegateパターン
Delegateオブジェクトを retain するべきではない。
linkDelegateパターンを実装するクラスは次のようにしておくべきだ。
- delegateを参照する delegate_ という名前のインスタンス変数を用意する。
- そして、アクセサメソッドは
deletate
とsetDelegate:
という名前にする。- delegate_ オブジェクトを 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 を使っているらしい。