～ ミネルヴァの梟は黄昏とともに飛び始める ～

Xcodeでの開発において、UIの構築で力を発揮するのがInerface Builderだ。Interface Builderを利用すると、ビューとコードを簡単に分離する事ができ、Xcodeでの開発でこれを利用しないのはバカだと断言できるレベルで非常にパワフルな機能を提供してくれる。しかも！デザインセンスが無い人でもそこそこの見た目に仕上げる事ができる。（もちろんInterface Builderはデザイナーとプログラマーの作業分離用に用意されていると思うが、Interface Builderを使ったからと言って、おそらくそんなに都合良くまわら無いと思う）

Interface Builderを利用すると何が便利かと、以下のようにUI上で線を結ぶだけでメンバー変数とテキストフィールドを関連づけたり、メソッドとボタンのクリックを関連づけたりできたりする。また、UIとコード間のデータのやり取りに関する処理はすべて内部で請け負ってくれ、コードを書く側はメンバー変数やメソッドの宣言時に識別子を書いておくだけで、UIの値やイベントが勝手に飛んでくるという手軽さ。

さて、今回のエントリーの本題に入りたいと思うが、このInterface Builderは非常にパワプルである一方、致命的に問題だと思う部分がある。（ちなみに、私は今日現在で１週間程度しかXcodeを触っていないので、勘違いしている可能性が十分にある事を前置きしておく）

その問題点は、この関連づけ（コネクション）の一覧を表示する仕組みが存在しない事である。ビュー単位では確認できるのだが、プログラム全体でコネクションの関係を閲覧する事ができない。

なぜこれが問題かと言うと、Controller（ソースコード側）の名前を変更したり削除した際には、Interface Builder側からコネクションを切断するか、コネクションを張り直してやらないとエラーを吐いて落ちるのである。コンパイラかプリプロセッサで弾けば良いと思うのだが、ご丁寧に実行時に落ちてくれる。

しかもXcode側で、名前の変更・削除をした際に、リファクタリングや警告の表示といった事が一切行われないのである。

[<UIViewController 0x55169b0> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key xxxxxx

プログラムが落ちる時には、上記のようなエラーを吐いて落ちる。もちろんkey xxxxxで示されるIBOutletの対応がおかしくなっている場合があるが、それは明らかなので、検索などでこのページにたどり着いた方は、おそらくエラーを吐くコードに対応した.xibファイルのコネクションはすべて確認されていると思うのでぜひ次の点を確認して欲しい。

これは、私もハマった点なのだが、Controllerの名前を変更してコネクションの不一致が発生した場合は、そのビューだけでなく、そのビューに遷移する前のビューのボタンなどのコネクションを確認して欲しい。遷移先で利用するControllerが指定されていると思うので、このコネクションを張り直すと動くようになると思う。

———-

Xcode/Interface Builderは全体的に使いにくい部分が結構ある。これは、Apple特有のデザインに偏った部分が問題になっているというよりは、競争が全くないというのが問題になっている気がする。

Appleが用意しているUI framework群が非常に優れているだけに、IDEの使いにくさでマイナスになっているのはもったいない。ぜひとも改善して欲しい。

その１で、改善しない人も多いようですので、その他の対処方法を見つけたので記載しておきます。

まず、この対処方法で改善するのは以下の環境の方です。

まず、以下のコマンドを実行して下さい。

$ rpm -qa|grep -e "^glibc-*" -e "nscd"

glibcのバージョンが2.5-42の場合は、この記事の方法で劇的に改善する可能性があります。というのも、glibc-2.5-42とnscd-2.5-42の相性が悪いらしく、VMwareの管理コンソールが頻繁にクラッシュし、最悪、仮想マシンが落ちてしまうようです。

続きを読む »

　Google I/Oのセッションの一つで、Faster apps faster: Optimizing apps with the GWT Compilerというセッションがあり、そこで公開されていたテクニックです。ここで紹介されたテクニックは、リリース用のバイナリ出力を高速化するテクニックではなく、テスト用のバイナリ出力を高速化するテクニックですので、リリース用のコンパイルは従来通り気長に待ちましょう。

　まず、コンパイルオプションに以下の２つを付けます。最初のオプションは、メタデータの出力を抑制し、２つめのオプションはいくつかの最適化をキャンセルする事でコンパイル速度を上げます。

• -XdisableClassMetadata
• -draftCompile

　次に、モジュール作成時に自動生成されるXxxxxx.gwt.xmlの<module>タグ内に以下の記述を追加します。この記述は、safariブラウザのみを利用することを指示します。

• <set-property name=”user.agent” value=”safari” />

　続いて、以下の記述を追加し、safari用に最適化されたDOMコントロールのみを利用するように指示します。

 <replace-with class="com.google.gwt.user.client.impl.DOMImplSafari">
   <when-type-is class="com.google.gwt.user.client.impl.DOMImpl" />
   <when-property-is name="user.agent" value="safari" />
 </replace-with>

　これでテストするブラウザが決まっている場合は、実行するJavaScriptはそこそこ速く、なおかつコンパイル速度を上げる事ができます。user.agentにはie6, ie8, gecko, gecko1_8, safari, operaが指定できるようです。

　最後に、Internationalization(I18N)を利用している場合には、以下の記述を追加する事で、テスト対象の言語以外は利用しない事を明記する事ができます。

• <extend-property name=”locale” values=”ja_JP” />

　これで、私の環境では従来3分かかっていたコンパイル速度が1分になりました。