iPhone 関係のプロジェクトを2つとも8割方終わらせました。
ひとつの方は、「How to (almost) create your own iPhone OS framework」というページを見つけたことで、だいぶ効率が上がりました。
ところで iPhone のプロジェクト管理では、シミュレータ実行と実機実行のそれぞれに別個のターゲットを作っておくのがラクですね。「アクティブ SDK」を「プロジェクトの設定を使用」にしておくと、ターゲットを切り替えるだけで実行環境をぱちぱちと変更できて便利です。ちなみに、いま私がやっているプロジェクトでは、Mac OS X と iPhone (Simulator) と iPhone (Device) を同じプロジェクトで切り替えているので、こういった設定がものすごく重要だったりします。
そうそう、上記の（フレームワークもどきの）静的ライブラリですが、静的ライブラリとフレームワークの大きな違いとして、静的ライブラリではリンク時に使われていないシンボルが削除されてしまうという点が挙げられます。これ、静的ライブラリの中に実装があるクラスを、XIB (NIB) の中でしか実体化していない場合などに問題になります。実体化するクラス名を文字列で管理していたりする場合などもそう。XIB の中に記述されているクラスは実行時になってようやく必要なんだと気付くことになるので、プログラムのどこかに、絶対に呼び出されることのない適当なメソッドを作って、「 [MyView new]; 」などと書いておかないと、実行時に MyView が見つからないと言って怒られてしまいます。まあ、これでも理論的にはギリギリまで最適化されたらリンクされませんが、実際問題として、そこまで最適化されることはまずないと思います。
オブジェクト指向的な設計をしていると、結構こういう文字列からインスタンスを作るような需要が出て来るのですが、Objective-C 自体はC言語ベースのくせに異様にちゃんとオブジェクト指向していてリフレクティブなのですが、やはりベースはC言語。Java のクラスファイルのようには行かず、「オブジェクトファイル」のくせにオブジェクト指向的ではない問題が出てきます（ぉ。
とはいえ、静的ライブラリは、リンカフラグで「-lmywork-Debug」のように書くだけでリンクできるので、Debug 用のライブラリと Release 用のライブラリを使い分けやすい点が、フレームワークよりも魅力的です。
コメントを書く