Spark Inspectorを一ヶ月ほど使ってみた感想

ちょっと仕事で複雑なiOSの画面を作りたいということになり、デバッグに難儀していた所、Spark InspectorというiOS向けのランタイムインスペクタツールが発売されていましたので、やや乗り遅れた感がありますが私も早速試してみました。

Spark Inspectorを使うと、

• リアルタイムにViewの構造を視覚的に確認し、直接プロパティの値を編集してアプリに反映させることができる
• Webエンジニアの人にわかりやすくたとえるならば、ChromeやFirefoxなどに付いているインスペクタをiOS上で使えるようなものです
• その他、アプリ内を飛び交っているNSNotificationの状態を監視することができる（らしい）

既に試された方のブログ記事で導入方法など詳しく公開されていますので、まずはそちらを見ていただくのが良いかと思います。

Spark Inspectorを導入してみた
http://inon29.hateblo.jp/entry/2013/12/06/002948
[Xcode][tool] ランタイムデバッガーSpark Inspectorが便利！
http://blog.natsuapps.com/2013/05/spark-inspector.html

ということで、私は一ヶ月ほど実際に仕事で使ってみて良かった点と悪かった点をまとめてみようかと思います。興味ある方の参考になればと思います。

■良かった点

導入が非常に楽です。ブログ記事で既に紹介されている方法は自分のプロジェクトに必要なフレームワークを組み込んで設定する方法ですが、最近のSpark Inspectorはこの方法を用いなくてもXcodeから一発で必要なフレームワークを動的に読み込んでインスペクタを起動してくれます。

Viewの階層構造をリアルタイムに監視できるのはやはり非常に有効です。これまではUIViewの- (void)recursiveDescriptionプライベートメソッドを呼び出したりして状態を確認したりしていたのですが、実行中の画面に対して動的に状態を見て、動的にプロパティの値を書き換えて見た目を調整することができるのは劇的に作業効率を改善してくれます。これってWebプログラミングだと実に当たり前のことなんですが、iOSプログラミングだと余りまだ普及してない考えだなと思います。

動作はやや重いですが、2012年モデルのMacBook Airでも問題なく動作させることが出来ました。もちろんiPadのアプリでもちゃんと動作します。

■イマイチだった点

楽に導入できる、自分のプロジェクトに必要なフレームワークを組み込まないやり方では、いくつか制限があります。

• 自分のプロジェクトに必要なフレームワークを組み込まないと、実機でSpark Inspectorを動作させることが出来ない。
• 動作が非常に安定しない。プロジェクトによってはかなりの確率で起動に失敗したりする。今回私が仕事で使っていたプロジェクトでは8割ぐらいの確率で起動に失敗していた。

それから地味に痛いのが、表示と編集が可能なのが現状CALayerとUIViewのプロパティのみに制限されているところです。Auto Layoutには対応していませんし、例えばUIScrollViewのcontentInsetを動的に調整してみたりですとかUIButtonの横幅とタイトルを動的に調整してみたりですとかそういう小技が出来ないため、なんというかかなり中途半端感を受けます。結局私の場合は表示されているはずなのに表示されていないViewの構造を調べる程度の用途にとどまりました。

Webページのサムネイル画像を生成して表示する AKWebRenderer を公開してみました

Social.frameworkのSLComposeViewControllerに貼り付けたURLのWebページのサムネイル画像を表示する機能があるのですが、それを真似する感じのライブラリです。TwitterのTLをダラダラ見ていて画像とURLをダラダラ流すだけのTwitterクライアントを作ってみたら面白くないかなと思ってやってみました。

リポジトリはこちらになります。
https://github.com/akisute/AKWebRenderer

使い方やライセンスなど全てREADMEに記載しておきましたのでそちらをご覧ください。

注意点として、遅い・重い・不安定の三重苦です＞＜ 実用で似たようなことをしたいのであればサーバを自前で用意して事前に画像をレンダリングさせるほうが良いと思いますが、SLComposeViewControllerと同じような動作がさせたいだけならばそこそこ使えるんじゃないのかと思っています。一応キャッシュとかもついてます。

Xcode 5 で、発生した NSException の詳細が表示されない時の対処法

原因がよくわからないのですが、iOSアプリをデバッグ中にNSExceptionが発生してアプリがクラッシュしてしまった時、その詳細がXcodeのコンソール上に表示されなくなってしまいました。普通はデフォルトのexception handlerがうまい具合にやってくれるのですが、何らかの理由でそれがうまくいかない場合があるようです。自分でスレッド立ててるとかでしょうか・・・

上図のように、例外が発生している箇所にブレークポイントをおいてどこで発生したのかを知ることはできるのですが、実際には発生箇所がわかっても発生原因がさっぱりわからないというケースもあります。例えばiOSのシステムが例外を発生させたときや、コードが公開されていないライブラリが例外を発生させたときなどです。

さて、このようなときは発生しているNSExceptionのdescriptionを直接読めれば便利そうです。というわけで調べてみました。

http://stackoverflow.com/questions/384775/how-do-i-find-out-what-exception-was-thrown-in-the-xcode-debugger-for-iphone

After you stop in the debugger, you can enter po $eax (simulator) or po $r0 (device) to see the exception. This is because the exception object is passed as the first argument to objc_exception_throw, which is kept in register r0 or EAX.

こちらの投稿のコメントにちょっとだけ書かれている方法がどうやら一番良さそうです。というわけで試してみました。

1. まずはプロジェクトのAll Exception Breakpointを有効にします。
2. アプリをデバッグして、例外が発生する箇所を実行します。
3. 例外発生箇所でブレークポイントが発動したら、左のスタックトレースナビゲーションから、スタックトレースの一番上（objc_exception_throw）を選択します。
4. コンソール上で以下のコマンドを実行します。
• シミュレータなら、po $eax
• 実機上なら、po $r0

うまくいきました！これで万一発生した例外の原因がよくわからない場合でも安心です。

余談ですが、eaxレジスタ/r0レジスタは関数の引数だかなんだかに相当するレジスタみたいなので、よくわからないコードで詰まっている場合はここを見れば他のケースでも解決できるかもしれません。