2012年3月4日日曜日

Unity 3.5でバージョン管理をする


およそコンピュータを使った仕事に該当するものでしたら何でも、複数の人物が同時に作業するための何らかの仕組みが必要になるのは、コンピュータを使った仕事に関わっている人でしたら皆ご存知かと思います。特に開発業務といえばgitやhgといったバージョン管理システムの出番になります。そういうわけで今回は Unity プロジェクトでのバージョン管理について一ヶ月間ほどやってみた結果をご紹介したいと思います。


■Unity 3.4以前の場合

そんな暗黒時代のことは忘れましょう。


■Unity 3.5以降の場合

Unity 3.5から新しい仕組みが導入され、 Unity Asset Server というビルトインの ボッタクリ バージョン管理システムを使う以外に、好きなバージョン管理システムを使ってUnityのプロジェクトをバージョン管理することができるようになりました。これを使わない手はありません。まずは公式のガイドを見てみましょう。
http://unity3d.com/support/documentation/Manual/ExternalVersionControlSystemSupport.html

これによると、以下の手順を踏むのが良いようです。
  1. メニューの Edit -> Project Settings -> Editor から、 Version Control の Mode という項目を探し、 Metafiles を選択する。これで外部のバージョン管理システムが導入できるようになります。このチェックを入れると、
    • Libraryディレクトリが重要なメタデータを管理するディレクトリではなくただのキャッシュディレクトリになり、バージョン管理をしなくてよくなる。
    • 新たにAssetsディレクトリ以下のすべてのファイルとディレクトリについて.metaファイルが生成される。
    • 新たにProjectSettingsディレクトリが生成される。
  2. メニューの Edit -> Project Settings -> Editor から、 Asset Serialization の Mode という項目を探し、 Force Text を選択する。この手順はどちらかと言うとおまけです。これを実行すると、ほとんどのAssetファイルがバイナリではなくテキスト形式で保存されるようになり、diffやmergeが行えるだけではなく差分だけをコミットするようになるためバージョン管理システムが扱うデータ量が減ります。
  3. プロジェクト配下のAssetsディレクトリとProjectSettingsディレクトリをバージョン管理システム配下に追加する。それ以外のファイルは追加しなくて良い。
たったのこれだけです。なかなか簡単そうですね!ということで早速やってみました。

・・・ところがぎっちょん、実際にやってみると出るわ出るわ問題の山。


■.metaファイルがどこからともなく勝手に生成される

これが最大の問題です。外部バージョン管理をするためにUnityが.metaという名前のメタファイルをテキスト形式で生成するのですが、コイツがトラブルを起こしまくります。
  • ファイル削除時に.metaを消すのを忘れて、同じ名前のファイルをあとから作成しようとして.metaがぶつかりトラブルになる
  • ファイルも.metaもバージョン管理下から確かに消したはずなのに、なぜか.metaファイルだけが勝手に復活している
  • ブランチを移動すると急に.metaファイルが湧いてきて、ブランチのマージ時に衝突する
主要な原因はUnityが空のディレクトリから.metaファイルを生成しているためです。 以下のようなケースで、中身が空のディレクトリというのは容易に生成されてしまいます。
gitの場合
gitはディレクトリをバージョン管理対象に含めないため厄介なことになります。通常はgit pull時にmerge/rebaseが実行され、その際に空になったディレクトリは削除されるのですが、merge/rebaseの最中に衝突が発生したりすると問題が大きくなります。merge中に裏でUnityが動いていると空ディレクトリの.metaがその場で生成されて、考えるだけでも恐ろしいことになったりします。
通常はこれで問題ないのですが、merge/rebase時に衝突が発生していて、裏でUnityが動いていたりすると酷いことになるみたいです。
hgの場合
hgはgitと同様にディレクトリがバージョン管理対象外なのですが、hg update時に空になったディレクトリをきちんと削除してくれます。これはupdateがworking directoryの中身を指定されたリビジョンの状態にするから、という認識です。gitと違いpullやupdate時にmerge/rebaseを実行しないためトラブルになりづらいのか?などと考えてますが実際に苦労したわけではないのでよくわかりません。おそらくgitよりはトラブルになりづらいとは思います。
1および3にupdateすると、きちんとFolderやOtherFolderが削除されてくれます。いい感じ。
svnの場合
ディレクトリもバージョン管理の対象にするので問題ありません。以下の図を参照。
r2のような削除の仕方をするとFolderが残ってしまうためFolder.metaが生成されてしまうのですが、普通はディレクトリを消したときはr4のような削除の仕方になるので問題がないはずです。
また中身が事実上空なディレクトリ(すでに使われていない.metaしか入っていないディレクトリなど)が亡霊みたいにさまよっていて延々と自身の.metaを書き出し続けたり、善意で予め作っておいた空ディレクトリが.metaを吐き出していることを知らずコミットされては削除されを繰り返していたり、二人が同時にディレクトリを削除しようとして片方のコミットが衝突して結果が壊れてしまったりなど、枚挙に暇がありません。

元ファイルを移動したり削除した際に.metaを消さなくてはいけないというだけでも極めて面倒で、相当なトラブルになりました。そもそもがUnityを使っているプロジェクトのメンバーが全員バージョン管理システムに慣れていないため、とりあえずバージョン管理システムのGUIツールがいうがままに変更を全部コミットするだけという具合の運用に。.metaだけが延々と残って衝突が繰り返されるという悲惨な状況が発生してしまうこととなりました。これはUnityのせいではなくメンバーがバージョン管理の考え方を正しく理解していないのが問題なのでツールは何を使っても発生しうるのですが、.metaがなければここまで問題は拡大しなかったと思います。

いっそignoreしてしまいたいぐらいなのですが、この.metaにファイルごとのメタ情報が全て詰まっているため、当然ignoreするとプロジェクトがブッ壊れます。これはひどい><

本家のドキュメントで例にされているのがgitでもなくhgでもなくsvnであるあたりを見ると、なんだかsvnで動作させることしか考えてなさそうな印象です・・・


■.unityファイルがマージできない

.unityファイル自体はテキスト形式にできるのですが、中で使われているAssetのIDがちょっと触れただけでものすごい勢いで変化したり、他人の環境では別の値になったりするため、殆どの場合マージできません。iOSプロジェクトのxcodeprojファイルみたいな感じです。こればかりはマージを諦めるしかありません。


■まとめ

最初はgitを使って管理をしていたのですが、上記に挙げたような問題が多発しまくって回らなくなってしまいました。別のバージョン管理システムを使うことも検討したのですが、そもそもメンバーのバージョン管理に対する知識が足りていない上に.metaが存在する以上hgやsvnに変えても問題が根本的に解決しそうにないと判断し、結局社長に頼んでAsset Serverを購入して試してみることになりました。がっかしです>< ですがAsset Serverならば.metaを使わないでバージョン管理できるので問題を根本的に解決できそうです。

逆に言えば.metaに気をつければそれ以外の箇所ではgitでもあまり問題になりませんでした。バイナリを大量に扱うため重いのではないかと懸念されていましたが、github経由ででも問題なくpush/pull出来る程度の重さにしかならなかったです。ということで.metaとうまく付き合えるチームメンバーが揃っているのであれば、Asset Serverなしでも十分やっていけるのではないかと思いました。

個人的にUnityでバージョン管理をする際におすすめする外部バージョン管理システムはsvn、可能であればPerforceです。git/hgのようにブランチを主体とするバージョン管理システムはブランチを切り替えた瞬間に.metaに殺されるケースが多々あるため、ブランチの使用そのものが非推奨となり、力が発揮できません。mergeについてもバイナリファイルやmergeできないテキスト形式のファイルが多くて結局意味がない気がします。どうしても分散VCSを使いたい!というならhgをお勧めします。ブランチ切り替えは常にupdate -Cすることで対応できるかなと。bazaarはわからないのでノーコメント。gitはpull時の衝突の最中に裏でUnityが動いていて大爆発するケースがあったのでやめておいたほうが良いです。hgなら少なくともpull/update時に爆発することはないはずですからね。

次はAsset Serverを試してみて、使用感を書いてみようかと思います。果たしてお値段に見合った効果は得られるのか!?乞うご期待です!

スタイラスペンの先端を保護する画期的な方法を思いついた


iPadなどのタブレット端末向けにスタイラスペンを持ち歩いていると、先端が破損してしまったり書き味が悪くなってしまったということはありませんか?最近のスタイラスペンの先端は繊細なシリコンゴムでできているものが主流で、持ち運びの最中に強い力がかかったりしてしまうと書き味が悪くなってしまうのです。そこで今回ご紹介したいのが、 Bamboo Stylusにマジックラッションペン No.300のキャップがジャストフィットする ってことなんです。こうやって写真のようにラッションペンのキャップをBamboo Stylusにつけてしまえば、持ち運んでいる最中にペン先が痛むことがありません!

Bamboo Stylusはクリップが取り外せるので、書いている最中はこんなふうに後ろにキャップが付けられます。


これで随分とペン先の劣化に悩まされることがなくなりました。これから発売される高級スタイラスは先端保護のためにキャップを付けて欲しいなぁと思った次第です。



■以下完全に余談: こんなことを思いついた経緯

もともと私は以前からiPad向けのスタイラスマニアで、よさそうな新製品が出るたびに買っては買っては試し、気に入ったものはポケットに入れて常に持ち歩くようにしています。
参考: http://akisute.com/search?q=スタイラス

その中でも特に書き味が素晴らしく、気に入っているのがBamboo StylusとSu-Penです。

B004XF0FQWWacom iPad/IPad2/iPhone4対応 描画、ポインティングに最適なタッチペン Bamboo Stylus CS-100/K0
ワコム 2011-05-27

by G-Tools
B005VCL6AKiPad/iPhone用スタイラスペン Su-Pen P101M-AS
7knowledge

by G-Tools

しかしながらこの2本はどうも先端の耐久性が他の製品にくらべて今ひとつなのか、ポケットに入れて持ち歩いているとどんどんペン先が劣化してしまうのです。まず最初にSu-Penが一月程で書けなくなってしまいました。TwitterでぼやいていたらSu-Penの担当の方に迅速かつ丁寧な対応をいただき、初期不良交換までしていただいたのですが、新しいペン先もやっぱり一月でダメになってしまいました。ものすごく丁寧な対応をしていただいたのになんかすみません>< Bamboo Stylusも三ヶ月ほどでペン先が死んでしまうため、こちらは購入後ペン先を2回も交換しています。これは悲しい。

そんな具合でスタイラスのペン先の劣化に悩まされていたある日、会社に落ちていた鉛筆と鉛筆キャップを見てふと思いついたのです。 そうだキャップを被せれば良いじゃん と。よくよく考えたら市販のペンは全てペン先にキャップが付いているかノック式になっていてペン先が収納できるようになっているんですよね。どうしてスタイラスにペンキャップがないのかと。早速東急ハンズの文房具コーナーにダッシュしてそこら中のペンのキャップを引剥して Bamboo Stylusに付けてみました。その結果たったひとつだけBamboo Stylusにジャストフィットするペンキャップが見つかったのです。それがマジックラッションペン No.300!

B000W9FK5Y寺西化学工業 マジックラッションペン No.300 黒
寺西化学工業

by G-Tools

まさかこんな所で1960年代から続くロングセラー製品と最先端技術が融合するとは!

2012年2月9日木曜日

ゲーム作り始めました



というわけで BP辞めちゃった わけなんですが、じゃあお前今なにやってんのよというのがこちらです。
http://www.gamecast-blog.com/archives/65644888.html
http://d.hatena.ne.jp/hotmiyacchi/20120204/1328376479

はい。ゲーム作り始めました。

なんでやねん!!!

これにはまぁ深いワケがあるのですが、話は去年の11月ぐらいまでさかのぼります。この新会社の社長さんの 宮川さん という方と以前から個人的に交流があったのですが、ある日ちょっと話したいことがあるから来てくれと飲みに誘われまして。その席で、

「君のコードを見させてもらった。大変素晴らしい。実はこうこうこういう仕事をやることになって、君の力が必要だ!是非来てくれ!!」 (会話内容はだいぶ事実と異なります)

とラブコールをいただきまして。
で、実は宮川さんって
http://www13.atwiki.jp/game_staff/pages/125.html
聖剣伝説3とかFF11とかのメインプログラマやってるわけですよ。でまぁ私、聖剣3とか全キャラのエンディング見るまでやりこんだわけですよ。そんなゲームの作者の人に来てくれ!なんて直接呼ばれた日にはもう、そんなんホイホイついていくに決まってるじゃないですか。ってことで転職することになったわけです。あとは受託開発じゃなくて自社の製品を出していけるというのも決め手でした。iOS向けで自社の製品を出していける、それも冗談みたいなのじゃなくて普通に市場のトップを取れる可能性がある製品が出せるかもしれない、というのはものすごく魅力的に見えたのです。


■転職してからこれまでのあらすじ

ぶっちゃけると私はこの転職、最初ものすごく不安だったのです。というのも
  • ゲームとかマジ作ったことない
  • 3Dプログラミングとか一ミリもわからない、むしろ数学とかマジわからない
  • ビープラウドがあまりにも良い環境だったし、給料もたくさんいただけたし、仲間も面白かったし、毎日勉強になりまくってたしで、正直転職先がこんなに恵まれた環境になるとは到底思えない
  • 宮川さんのはてダ を見ていただければわかるのですが、基本的に彼はやたらとBlogに書く内容に誇張表現が多いので なんか嘘っぽい
まぁ、やると決めたし、これまで二年間ほどBPに甘えさせていただいて楽して成長できてたし、独り立ちして苦労するのも悪くないか、などと自分に言い聞かせて2/1の初出社を迎えたわけですよ。

そしたらたまげた。 新しい職場にはBPより頭がおかしい連中しかいなかったんですよ。

冗談じゃなくこんな感じ

その日集まった18人全員のスキルがどいつもこいつもXMENだったと。当日の様子をお伝えできないのが非常に残念なのですが、一体全体宮川さんはこんな連中を日本のどこから集めてきやがった!!と叫ばざるを得ない。そしてまた彼のマネジメントのやり方が驚嘆するほどに上手いのです。以下ハイライト。
  • いきなり初日からクライマックス状態の自己紹介タイム
  • いきなり初日から会社でふぐちり鍋(注: 水曜日です)
  • でも翌日朝9時出社は厳守させる、無断欠勤してきた奴にはものすごい勢いで怒る→全員超引き締まる
  • いきなり2日目から「1日に1本ゲームの企画を立てて作る、4日連続で、チームメンバーは毎日全員入れ替え」という頭おかしい研修内容
  • それを当たり前のようにクリアする全員、当然のようにiOS実機で動く
  • それどころか毎日完成するゲームの質が上がる
  • それどころか毎日完成したゲームのプレゼンの質が上がる
  • 4日終了した段階で、全員の打ち解け度合いが半端ない、よくある「チームごとの壁」みたいなのが全くない状態で実際の仕事に突入
  • 研修が終わった日にまた鍋(注: 一週間に二回鍋です、火曜日です、終電まで全員飲み食いしてます)
  • でも翌日朝9時出社に誰も遅刻しない
  • グラフィッカーさんに良いマウスがないか聞かれたのでSteelSeries XAISteelSeries 4HDの実物を持っていって触ってもらったら大絶賛され、翌日Xaiと4HDがそれぞれ8個ずつ届いた(注: 1セット1万2000円ぐらいします、たかがマウスです)
  • 無線LANアクセスポイントの調子がわるいのでCISCOの良い奴にしましょうと答えたら、二日後に本当にCISCOのAPが届いた
  • 開発用のMacツールおよび企画研究用のiOSゲームは全て買い放題
  • 昼休みに社員8人程度でHaro Reachのデスマッチをプレイしてる
  • 仕事上がりに同僚とCoDのcoopをプレイしてる
  • 同僚にシャドウゲイトの話が通じる
  • 同僚にPortal2やSkyrimやStarCraft2の話が普通に通じる
などなど、枚挙に暇がありません。いや、正直最初はFF11のメインプログラマやってたとかいうけどどうなのかなーなどとものすごいタカをくくっていたのですが、ほんとスミマセン。これは本気で強いです。バラ色天国な環境過ぎて、これはもう勝ったと言わざるを得ない。前職のBPも素晴らしい環境だったのですが、ここの環境は正直常識が通用しないレベルですごいです。日本で一番すごい環境じゃないかと言われたらイェスと答えてもいいかもしれないです。

そして環境も素晴らしいですが同僚も皆とんでもない連中ばかり。スキルは当然として、全員が向学心と負けず嫌いの塊みたいなものですから、研修がとんでもなく白熱しまして、正直ヤバい。私もBPのハッカー魂と業務改善の魂を是非新しい職場に吹きこんでいこうと日々頑張っております。当分の間は退屈しない、全力全開の日々が過ごせそうです。

2012年2月8日水曜日

ビープラウドを退職しました


やや旧聞になりますが、1月末付で 株式会社ビープラウド を退職いたしました。知ってた人はすでに知ってたと思うんですが、なんかすっごい唐突で色々とすみません>< 退職理由や次の仕事の話などは次の投稿に詳しく書く予定ですのでそちらに任せるとして、今回はこの場をお借りしましてビープラウドがどういう会社だったか、ちょっと過去の振り返りなどをしてみたいと思います。


■BPはどんな会社か

(良い意味で)頭おかしい連中ばっかりが集まって、本気で学び本気でコード書いている集団だと思います。

具体的には 右隣の奴 が常時こんな状態で仕事してます。

こんなことを書くと本当に変人しかいないんじゃないのか、お前ら大丈夫か、などと思われてしまうのですが、そうじゃないんです。ビープラウドはみんなが自分のすべてをぶつけて、さらけ出して仕事できる素晴らしい会社なんです。私は新卒で入社したSIerの会社をやめてBPに入社したのですが、入社した初日にパスワードが失われてログイン出来ないMacを渡されて何とかハックして使えという具合だったり、それまで同期の誰に喋っても通じない技術の話が当たり前のように通じたり、っていうかむしろ私が知らない事のほうがはるかに多かったりで、全力で自分の技術をぶつけることができた感動を今でも覚えています。世の中にはいろんなくだらない理由だとか社内政治だとかで、自分の全力、技術力のすべてを出し尽くせない、出してはならない、出す価値もないような仕事が散見される(それが最初の会社をやめた理由の一つでもある)のですが、ビープラウドでは全力全開超推奨。二年間で vの人 から「お前は随分良くなった」とお褒めいただけた程度には成長できたのも、間違いなくビープラウドで自分の全力を出して挑戦し続けさせていただいたおかげだと思っています。

私が見たビープラウドの感想なので、他の人から見たらちょいとズレているのかもしれませんが、私は技術を大事にする、エンジニアを大事にして全員にMacやらレッドブルやらを支給する、社内勉強会やBPStudyを開催する、などといったBPのハッカー文化が大好きで、退社した今でもその気持ちは変わりありません。むしろ退職して新しい仕事をしている今から振り返ると、BPの素晴らしかったところはあのハッカー文化だったんだなという思いを強くしています。


■謝辞

去年の12月にいきなり辞めると言い出したにも関わらず快く送り出していただいた社長のはるおさんとCTO、超ムチャぶりにも関わらず私の仕事を引き継いで立派に締めてくれたgkt、個人的に超いろいろ迷惑をかけまくった右隣の席の奴に、ありがとう!!むしろBP全員ありがとう!!!お陰様であきすては元気にやってますよ!

2012年1月29日日曜日

xxd を使って画像などのバイナリデータをソースコードに含める方法

iOS向けのライブラリやフレームワークを作成しているときに、どうしても画像などのバイナリデータをライブラリやフレームワークに含めたくなる時があります。たとえばUI系のフレームワークなどですね。このようなときに、たとえば静的ライブラリ(.aと.h)やフレームワーク(.framework)とセットで画像を一緒に同梱し、ユーザーのXcodeプロジェクトに一緒に含めてもらうという方法もあるのですが、この方法だと画像名がユーザーのプロジェクトに含まれている画像とかぶったりしてはいけませんし、管理が面倒になってしまいます。また、ライセンスがプロプライエタリなライブラリでは、画像などのリソースをあまり積極的にユーザーに公開したくないというニーズがあったりします。

そこでxxdツールのご紹介です。岸川先生に教えていただいたのですが、xxdというツールを使えばバイナリデータをC言語のヘッダファイルとして簡単に出力することができるらしいのです。これを使ってバイナリデータをライブラリ内部のソースコードの一部として配布してみましょう。

xxdはvimに同梱されているので、最初からMac OS Xについてきます。使い方も非常に簡単です。
xxd -i Sample.png
とすると、
unsigned char Sample_png[] = {
  0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a, 0x00, 0x00, 0x00, 0x0d,
  0x49, 0x48, 0x44, 0x52, 0x00, 0x00, 0x07, 0xfd, 0x00, 0x00, 0x04, 0x73,
//中略
unsigned int Sample_png_len = 589903;
このような感じでバイナリデータがC言語のヘッダファイルになって出力されます。あとはこれをNSDataにして、UIImageを生成することができます。NSDataを作る際には余計なデータコピーが発生しないdataWithBytesNoCopy:length:freeWhenDone:を使うことをお勧めします。
NSData *data_Sample_png = [NSData dataWithBytesNoCopy:Sample_png length:Sample_png_len freeWhenDone:NO];
UIImage *image = [UIImage imageWithData:data_Sample_png];

2012年1月24日火曜日

Jenkins を iOS アプリ開発に導入してみた (gcov編)


前回 はSenTestKitに続いてGHUnitを導入して、Jenkins上でGHUnitによるテストの自動実行を行いました。今回はさらにステップアップして、gcovを使用してコードカバレッジを取るようにしてみようかと思います。


■gcovを使ったコードカバレッジの取得(Xcode 4.3版)

Xcode 4.3の場合は以下の参考ページで紹介されている方法がオススメです。実機ででもシミュレータでも動作してお得です。
http://www.cocoabuilder.com/archive/xcode/314794-xcode-4-3-moved-libprofile-rt-how-to-reference-it-now.html
http://www.infinite-loop.dk/blog/2012/02/code-coverage-and-fopen-unix2003-problems/
https://github.com/InfiniteLoopDK/ILTesting
  1. Generate Test Coverrage FilesとInstrument Program FlowにYESを指定する
  2. http://www.infinite-loop.dk/blog/2012/02/code-coverage-and-fopen-unix2003-problems/で紹介されているILProfilerCompat.cを組み込む(これによってfopen$UNIX2003によるエラーを防ぐ)
これだけで大丈夫です。


■gcovを使ったコードカバレッジの取得(Xcode 4.2版)

【2012/03/15追記】こちらの方法はXcode 4.2が前提となっており、Xcode 4.3以降は動作しません!

gcovとはgccに付属されているC言語用のカバレッジ測定ツールです。これを使うことで、C言語と、その拡張であるObjective-Cのコードカバレッジをバッチリ取得することができます。ということで早速プロジェクトに組み込んでみましょう。幸いにしてすでに先駆者の方がいらっしゃいました。
http://tech.naver.jp/blog/?p=706
基本的に上記に記載されている通りの手順で導入すれば簡単にgcovによるコードカバレッジの取得ができますが、実際にやってみたところ幾つか補足があるので追記します。

先ほど紹介した記事では/Developer/usr/lib/libprofile_rt.dylibの追加と-lgcovの指定両方を行なっているのですが、私が試したところどちらか片方だけで成功するということがわかりました。具体的には以下のとおりになります。

1. /Developer/usr/lib/libprofile_rt.dylibを使うパターン
2. -lgcovを使うパターン

それぞれ見ていきます。

1. /Developer/usr/lib/libprofile_rt.dylibを使うパターン

/Developer/usr/lib/libprofile_rt.dylibをプロジェクトに追加し、Other C Flagsの-fprofile-arcs -ftest-coverageを設定すればOKです。それ以外の手順は必要ありません。
このパターンですとスムーズにgcovの結果を出力することができましたが、残念ながらこの方法はSimulator上でしか使用できません。というのも、/Developer/usr/lib/libprofile_rt.dylibがそもそもarmv6, armv7用のバイナリを含んでいないという問題があるのと、ライブラリ探索パス"/Developer"以下がDeviceビルド時に勝手にiphoneos.sdk以下の/Developerに置換されてしまうため、ビルド時にlibprofile_rt.dylibをリンカが発見できずエラーになる問題があるためです。基本的にSenTestingKitのようなSimulatorでしか実行しないビルドターゲットでやるのが良いと思われます。

2. -lgcovを使うパターン

参考: http://stackoverflow.com/questions/5101014/code-coverage-not-showing-results-using-xcode-gcov/5140459#5140459
-lgcovをOther Linker Flagsに追加し、Generate Test Coverrage FilesとInstrument Program FlowにYESを指定すればOKです。それ以外の手順は必要ありません。
このパターンですとlibgcovはarmv6, armv7でも動作するので実機でのカバレッジ取得ができるのですが、問題はそのままの設定でビルドして実行すると実行時にクラッシュします。これはlibgcovが実行時にカバレッジデータを書きだす際に、デフォルトの設定ではiOSのサンドボックスの外にアクセスしようとするため書き出しに失敗してしまうのが原因です。したがって上記参考URLに従ってGCOV_PREFIX環境変数を使いサンドボックス内部にカバレッジデータを書きだすように指定してやる必要があります。
この方法は環境変数を実行時に設定する必要があって面倒なのと、カバレッジデータが書き出される箇所がJenkinsのビルドディレクトリの中ではなくiOSシミュレータまたは実機のサンドボックスの中になってしまうため、Jenkinsからカバレッジの取得を行うのが困難になってしまう問題があります。

今回は1. のパターンを採用し、SenTestingKit上でSimulatorビルド時のカバレッジ取得だけを行うことにしました。GHUnitでも実機上での動作を諦めれば問題ないのですが・・・まだ課題が多い感じですね。

ビルド設定ができたらビルドして、きちんとgcovコマンド経由でカバレッジが取得できていることを確認しましょう。


■gcovrを使ってCoberturaのXML形式に変換する

gcovのカバレッジデータの取得ができるようになったら、今度はJenkinsと連携させるために、gcovの出力をCoberturaというJava環境のカバレッジ計測ツールの出力するXML形式に変換する必要があります。これはJenkinsがgcovのカバレッジデータ出力の集計に対応していない為です。っていうかgcovの出力は単なるタブで区切られた文字列で人間以外にはとても優しくないので集計ができないのです。
ここで、Python製のgcovrというツールをJenkinsサーバマシンに導入します。 gcovrをgcovの代わりに使うことで、CoberturaのXML形式で結果を出力できるようになるほか、カバレッジ計測対象となるファイルを簡単にフィルタリングできる(たとえばテストケースクラスのカバレッジなんか集計してもしょうがないので除外するなどできる)のが大きな魅力です。
http://wiki.hudson-ci.org/pages/viewpage.action?pageId=45482230
https://software.sandia.gov/trac/fast/wiki/gcovr

インストールはMacマシンであれば非常に簡単で、以下のコマンドを打つだけです。
sudo easy_install gcovr
インストールが完了したら、あとは
gcovr --xml --output=cobertura-report.xml build/
とかやれば一発でbuildディレクトリ配下のすべてのカバレッジを計測結果を集計してXML形式で書きだしてくれます。
ここでもし、テストケースのカバレッジは除外したいなどという要件がある場合は、
gcovr --xml --exclude=".*/.*Test(s)?\.[(c)(cpp)(m)(mm)]" --output="cobertura-report.xml" build/
などとすればOKです。


■JenkinsのCoberturaプラグインを使って結果を集約する

CoberturaのXML形式で結果が取れるようになってしまえばあとは楽勝です。JenkinsにCoberturaプラグインをサクっとインストールして、
https://wiki.jenkins-ci.org/display/JENKINS/Cobertura+Plugin
あとは以下のようにJenkinsのジョブ設定を書いてしまうだけです。先述の通り、SenTestingKit上でSimulatorビルド時のカバレッジ取得だけを行いたいので、既存のSenTestingKit用単体テストジョブのXcodeビルドの後でgcovrを実行するシェルスクリプトを実行してやれば一発です。


カバレッジが取れるようになると断然見栄えがしますね。

2012年1月23日月曜日

Jenkins を iOS アプリ開発に導入してみた (GHUnit編)


前回 はSenTestKitを用いてJenkins上で単体テストの自動実行を行いました。今回はGHUnitを使った単体テストの自動実行にチャレンジしてみたいと思います。またついでといっては何ですが、単体テスト時に必要になってくるモックを作成するためのライブラリOCMockも同時に導入してみようと思います。


■なぜGHUnitを使うのか

GHUnitを使うことで、SenTestingKitと比べて以下のようなメリットが得られます。
  • 非同期処理のテストを行うための仕組みが用意されている(GHAsyncTestCase)これをSenTestingKitないし他のテスティングフレームワークでやろうとすると大変骨が折れます。
  • .app形式(要するに実際のiOSアプリケーション)でテストを実行するため、UIApplicationやUIWindowといったUIコンポーネントを使うクラスのテストが可能になる。UIテストの支援をするための仕組みも最近のGHUnitには追加されている。
    • SenTestingKitの"Logic Test"では想定通りに動作しないUIKitやFoundationのクラスが幾つかあり、中には純粋なロジックで使いそうなクラスも含まれている。そのためSenTestingKitではテストできないロジッククラスが発生する場合があるので、そういう時はGHUnitを使うと良い。
    • 参考: https://gist.github.com/1662887
  • 実機上でテストを実行できる。そのため実機でのみ発生するバグをつかまえることが可能。
  • SenTestingKitのテストケースをそのまま実行できるため上位互換として使用できる。
逆にGHUnitにはSenTestingKitと比べて以下のようなデメリットがあります。
  • Xcode 4で統合されたUnitTestingの恩恵に預かれない。すなわちCmd+U一発でテストケースを実行することができない。Xcode経由だとCmd+Rでアプリケーションとして起動して、その後起動したアプリのテスト実行ボタンを押す手間が必要になるため、開発のテンポが乱されてしまう。特にTDDを採用している場合には深刻。
  • 上記問題を回避するためCUI経由でテストを実行することもできるのだが、Xcodeのエディタと連携しないため、どこがエラーになっているのかが一目でわかりづらい。
  • カバレッジの取得が楽。SenTestingKitをシミュレータ上で実行している時が一番やりやすい。これについては別の記事で解説します。
これを踏まえると、以下のように使い分けができるようになります。
  • SenTestingKitは純粋なロジックの単体テストを実行したいときに良い。Xcodeからすぐに実行できて一瞬で結果がコード上に出るので、開発のテンポを乱さない。TDDに向いている。
  • GHUnitは非同期なAPIを持ったクラスの単体テストを実行したいときに良い。またUIApplication, UIWindowといったUIコンポーネントと結合したり、通信やファイルアクセスなどの外部リソースとの結合をおこなった状態でのテストを作る際にも向いている(純粋な単体テストともユーザー受け入れテストとも異なるため、仮に結合テストと呼ぶことにする)ので、そういったものが必要な場合には最高の選択肢となる。
プロジェクトの開発方針や開発対象によってどのようなテストが必要になるのかが異なってくると思いますが、どれか1つだけ必要であればGHUnitを選択し、きちんとしたXPでやりたいプロジェクトはSenTestingKitに単体テストをやらせ、ユーザー受け入れテストに KIF などを採用し、その中間を埋める必要があればGHUnitも導入する、というのが良いのではないかと考えています。ちょっと面倒ですけど。


■GHUnitを導入する

以下のリポジトリからコードを取得して、XcodeからビルドすればOKです。
https://github.com/gabriel/gh-unit
注意点として、GHUnitは.framework版がそのままgithubからダウンロードできるのですが、
https://github.com/gabriel/gh-unit/issues/69
このような問題が報告されており使えないので、githubからソースコードをクローンしてきて、
cd Project-iOS
make
でビルドしてできたGHUnitIOS.frameworkを使うようにしてください。

frameworkをビルドしたら自分のプロジェクトに追加して、GHUnit用のビルドターゲットを作ります。
http://gabriel.github.com/gh-unit/docs/appledoc_include/guide_install_ios_4.html

ビルドターゲットができたら、次は試しにテストケースを追加してみて、問題なくテストが走るか確認。
http://gabriel.github.com/gh-unit/docs/appledoc_include/guide_testing.html

最後にCUI(要するにxcodebuildコマンド経由)でビルドができるようにします。これをやらないとJenkinsと連携できません。
http://gabriel.github.com/gh-unit/docs/appledoc_include/guide_command_line.html


■OCMockを導入する

以下のリポジトリからコードを取得して、XcodeからビルドすればOKです。
https://github.com/erikdoe/ocmock
iOS向けビルドはスタティックライブラリ用のビルドしか用意されていませんので、どうしてもフレームワークが良いとこだわる人は頑張ってください>< そうでなければ非常に簡単です。ビルドしたら成果物をそのままプロジェクトに突っ込めばすぐ使えるようになります。
OCMock自体の使い方にはここでは触れませんが、例えば以下のようなテストケースが作れたりします。

- (void)testOCMock
{
    // Creating a new stub object from class
    {
        id mockedObject = [OCMockObject mockForClass:[NSString class]];
        STAssertThrows([mockedObject length], @"Mocked object raises exception because the fake method is not ready yet.");
        STAssertThrows([mockedObject isKindOfClass:[NSString class]] , @"Mocked object can't even call isKindOfClass: because it's not ready.");
        STAssertFalse([mockedObject class] == [NSString class], @"Mocked object is not a kind of the target class.");

        [[[mockedObject stub] andCall:@selector(mockedLength) onObject:self] length];
        STAssertEquals([mockedObject length], (NSUInteger)100, @"Mocked object returns the fake value.");

        [[[mockedObject stub] andReturn:@"AllYourBaseAreBelongToUs"] lowercaseString];
        STAssertEqualObjects([mockedObject lowercaseString], @"AllYourBaseAreBelongToUs", @"Returns mocked value.");
        STAssertEquals([mockedObject length], (NSUInteger)100, @"Previously mocked methods are still valid.");
    }

    // Method Stubbing for existing object
    {
        NSString *stubTargetObject = @"I am a stub target.";
        STAssertEquals([stubTargetObject length], (NSUInteger)19, @"The original implementation of the length method.");

        id mockedObject = [OCMockObject partialMockForObject:stubTargetObject];
        STAssertTrue([mockedObject isKindOfClass:[NSString class]] , @"Mocked object is a kind of the target class.");
        STAssertEquals([mockedObject length], (NSUInteger)19, @"Mocked object returns the original value.");

        [[[mockedObject stub] andCall:@selector(mockedLength) onObject:self] length];
        STAssertEquals([mockedObject length], (NSUInteger)100, @"Mocked object returns the fake value.");
        STAssertEquals([stubTargetObject length], (NSUInteger)100, @"Stubbed target object also returns the fake value.");
    }
}
- (NSUInteger)mockedLength
{
    return 100;
}


■Jenkinsと連携させる

最後にJenkins側でビルドターゲットを作りましょう。
http://gabriel.github.com/gh-unit/docs/appledoc_include/guide_ci.html

こんな感じの設定になると思います。

あとはいつもどおりジョブを回してみて問題がないか確認すれば完了です。前回ご紹介したようなSenTestKitの単体テストジョブがうまく回っていれば、それをコピーしてきてちょっと設定を変えれば簡単にできるとおもいます。

2012年1月21日土曜日

Objective-C がこの四年間でどれぐらい進化したのか一目でわかるテストケース

Twitterに流したら思ったよりも好評でしたので、ブログにも上げておきます。

こちらがiOS 2地点でのNSURLConnectionクラスを使った非同期通信のテストケース。

こちらがiOS 5でのNSURLConnectionクラスを使った非同期通信のテストケース。

Blocksはやっぱり偉大です。一つしかテストケースがないうちはまだマシなのですが、これが10個とかになると楽さが全く違ってきます。ぜひためしにURLだけ変えて同じテストケースを10個作ってみてください。iOS 5のBlocksを使ったコードはほとんどコピペだけで終わりますが、iOS 2でのdelegateを使ったコードは他にも変更しなければならない点が多数出てくるはずです。

また実際にこのコードを走らせてみると、理由はよくわからないのですがiOS 5で追加されたAPIを使ったコード(Blocks)のほうがそうでないコードよりも毎回2倍程度(0.1秒程度)高速に動作しているみたいです。ちょっと謎ですが、新しいAPIにはパフォーマンス面でのメリットもありそうです。GCDのおかげかな?

2012年1月20日金曜日

Jenkins を iOS アプリ開発に導入してみた (SenTestKit編)


最近、iOSアプリの開発でも継続的インテグレーション(CI)を取り入れていくプロジェクトが増加傾向にあるようで、各種ツールやライブラリ、ノウハウが出回ってきているように感じられます。そこで私も早速iOSアプリ開発でのCI導入を試してみることにしました。今回の導入試験では、以下のような環境を想定して行いました。
  • iOSアプリの開発を、Xcode 4.X系のプロジェクトとして行う。
  • VCSにはgitを採用し、githubの公開リポジトリをリポジトリサーバーとして使用する。
  • CIサーバにはMacを採用し、プロジェクトをビルドするためにXcode 4.Xをインストールしておく。


■必要なツールを準備する

CIといったら、まずは何はなくともJenkinsです。
http://jenkins-ci.org/
ここでは導入について詳しくは挙げませんが、私は以下の本を参考にしました。
https://gihyo.jp/dp/ebook/2011/978-4-7741-4952-3

続いてJenkinsのプラグインを導入します。
これでJenkinsの準備はだいたい完了です。
あとはVCSのgitですが、こちらは準備が出来ているという想定で進めます。


■余談:xcodebuildの使い方

JenkinsのXcodeプラグインを使えば、自分で面倒なantのbuild.xmlを書いたり、ビルドスクリプトを用意しなくても、JenkinsのGUI上でビルド設定を行うことが出来ますが、念のため基本を理解しておくべく、xcodebuildというツールを使ってみます。xcodebuildはXcodeプロジェクトをCUIからビルドするためのツールで、Xcodeに付属しています。JenkinsのXcodeプラグインも内部的にはこいつを使用しています。

基本的な使い方の例は以下の通り。
xcodebuild -project MyApp.xcodeproj -configuration Release -target MyApp clean build
xcodebuild -project MyApp.xcodeproj -configuration Debug -target MyAppTests -sdk iphonesimulator5.0 clean build
xcodebuild -project MyApp.xcodeproj -configuration Debug -target MyAppTests -sdk iphonesimulator clean build
上の例ではデフォルト設定のiOS SDKを用いてビルドターゲットMyAppがReleaseビルドされます。次の例ではiPhone Simulator 5.0 SDKを用いてビルドターゲットMyAppTestsがDebugビルドされます。一番下の例では、手元にある最新のiPhone Simulator SDKが使用されるようです。また -target の代わりに -scheme を使うことも出来ます。ビルドに使うことができるSDKの一覧を得るためには、
xcodebuild -showsdks
を使えばよいです。

ビルドアクションにはclean, build以外にもarchiveとかあるのですが試していないので詳細は不明です。しかし残念ながら、少なくともtestアクションがないことは確認しました。そのため、Xcode上で Cmd+U を押して実行できる単体テストが、xcodebuild経由では実行できません。これについては後ほどまた触れます。


■Xcodeプロジェクト側の準備

Jenkinsによる自動化を行うためには、まずはXcodeプロジェクト側を修正して、xcodebuildツールにより単体テストが実行できるような状態にして置かなければなりません。そのため先にXcodeプロジェクト側の設定を修正します。Xcode 4でテストケース付きの新規プロジェクトを作るとテストケース実行用のターゲットが自動的に用意されると思いますが、先述の通りこのターゲットはxcodebuild経由では実行できないため、以下の画像の様にUnit Testing -> Test Hostを削除して対応します。


このように設定を変更することで、UIWindowやUIApplicationを使わなければならないテストが実行できなくなりますが、それ以外のテストはXcodeからもxcodebuildからも実行できるようになります。試しにxcodebuildを使ってテストターゲットを実行し、テストが走っていることを確認してください。


■Jenkins側の準備(ジョブの設計)

続いていよいよJenkinsの設定に移ります。プラグインは導入してあるので、あとはジョブを作るだけです。Xcode連携のプラグインが入っていれば楽勝です。今回はシミュレータビルドで単体テストを行うので、ビルド後の処理でテスト結果の集約を行い、test-reports/*.xmlを指定しましょう。


デバイスビルドでリリース用のビルドを作る場合には、ビルド後の処理でビルド成果物の保存を行い、build/Debug-iphoneos/*.ipa(必要ならdSYMも)などを指定しておけば良いかと思います。デバイスビルドをするにはビルドをするマシンのKeychainにcodesign用の証明書と鍵が格納されている必要があるので注意してください。Technical VersionやMarketing Versionの値を指定すれば、自動的にInfo.plistに指定されているCFBundleVersionやCFBundleVersionShortStringを置換してくれるので非常に便利です。


ジョブを作ったら早速実行してみましょう。おそらくビルドだけならあまり苦労せずに通ると思います。私は10回目のビルドで完全に問題なくビルドが回りだすようになりました。

2012年1月15日日曜日

gdb で void* 型の変数をデバッグする

C言語で実装されたライブラリやアプリケーションでは、汎用的な型として随所で void* が使用されますが、これをgdbからデバッグすると、そのままでは型情報が無いためタダのポインタとして扱われてしまいます。これではデバッグ時の都合がよろしくないです。
(gdb) print 0xfee65c0
$1 = 267281856
(gdb) print (void *)0xfee65c0
$2 = (void *) 0xfee65c0
こんなとき、この void* が指し示している先の型がわかりきっている場合は、その型でキャストしてやって:
(gdb) print (struct imap_session_state_data *)0xfee65c0
$4 = (struct imap_session_state_data *) 0xfee65c0
(gdb) print $4
$5 = (struct imap_session_state_data *) 0xfee65c0
参照先にアクセスすればきちんと中身が見えます:
(gdb) print * $4
$6 = {
  imap_session = 0xfee6560,
  imap_mailbox = 0xfee6230 "INBOX",
  imap_flags_store = 0xfee6490,
  imap_ssl_callback = 0,
  imap_ssl_cb_data = 0x0
}
(gdb) print $6->imap_session
$7 = (mailimap *) 0xfee6560
(gdb) print * $7
$8 = {
  imap_response = 0xfee6090 "FETCH completed",
  imap_stream = 0xfeecc90,
  imap_progr_rate = 0,
  imap_progr_fun = 0,
  imap_stream_buffer = 0xfee6a00,
  imap_response_buffer = 0xfee6a20,
  imap_state = 3,
  imap_tag = 4,
  imap_connection_info = 0xfee64d0,
  imap_selection_info = 0xfee6030,
  imap_response_info = 0xfee60e0,
  imap_sasl = {
    sasl_conn = 0x0,
    sasl_server_fqdn = 0x0,
    sasl_login = 0x0,
    sasl_auth_name = 0x0,
    sasl_password = 0x0,
    sasl_realm = 0x0,
    sasl_secret = 0x0
  },
  imap_idle_timestamp = 0,
  imap_idle_maxdelay = 1740,
  imap_body_progress_fun = 0,
  imap_items_progress_fun = 0,
  imap_progress_context = 0x0
}
これでデバッグがはかどりました。

2012年1月2日月曜日

2011年のふりかえりなど

あけましておめでとうございます。年も開けましたので、2011年のふりかえりをやってみて、2012年の抱負を考えてみたいと思います。

■やってみたこと
2010年の途中からiOSアプリの開発担当になったのですが、2011年は始めて一年中iOSアプリの開発に携わることができました。ということでダイジェスト。
  • 1月は前年度から引き続きアプリの修正案件を行なってました。ずいぶんひどく炎上した一年のスタートになったのですが、炎上したプロジェクトでしか学べないものというのはたくさんあるものだと痛感させられました。主に案件がどうして燃えるのかとか、何が死亡フラグか、など。自分一人ではどうにもならないので、急遽助っ人に助けてもらいましてなんとか収拾。助っ人の方々、あの時は本当にありがとうございました><
  • 2月ぐらいからBPRという自社開発のフレームワークとそれを使ったアプリの開発などをしていました。外部に公開するライブラリを組むのは初めてということで、実に勉強になりました。中身の実装もなかなかうまくいったと思ってます。
  • その後ちょっとした案件をこなしてましたが、ここでは複数案件の並行進行を余儀なくされたため、またも自分一人ではどうしようもならない事態に。うまい具合にアルバイトの人に仕事をお願いしたりする必要に迫られるなどしました。
  • 5月〜6月が今年一番の正念場でした。それぐらい難しい案件と他の案件を並行で進めていたのですが、ずいぶん自分の設計からミスをしてしまい、自分の限界を知ることになった気がします。主にCore DataまわりとAPI通信実装まわりの限界がこの案件ではっきりと分かりました。それだけではなく、グループで仕事するときの死亡フラグとか、炎上案件の燃え方とか、これまた大いに学ばされました。
  • 7月からはずっと一本のアプリに集中して新規実装および修正を行なっていました。これまでの案件と打って変わってあまりにもサクサク進んだもので、受託開発での「お客さんの力量」の大事さを実感。むしろ自分のほうがお世話になりっぱなしで申し訳ない気持ちでした。この案件では試しにこれまでの社内ライブラリや設計の基本をすべて捨てて新しい方式でやってみたのですが、大いに成功したところもあればひどく失敗したところもあり、結果としてこの挑戦は正解だったと思っています。またとある理由でopensslのコードを読んだりしたなど、より低レイヤーな部分の知識が限定的ながら得られてきました。
まとめると、これまでにない難易度のアプリの開発に携われて成長できたのと、自分一人ではどうにもならない場面を何度も経験し、仲間の力の偉大さに気付かされたのが今年の収穫だったと思います。

■Keep
去年良かったので続けたかったことはこんなところ。
  • いろんな技術に手を出す。一年以上積み重ねてきたおかげで、ずいぶんと「一番いいやり方」と思われるiOSアプリの開発手法がわかってきたのですが、その方法に固執するとよりよい方法を見落としたり、時代についていけなくなると思ったのであえて別の方法を試し、結果としてよりよいライブラリやプラクティスを学ぶことができたのが実に良かったので、今年もチャレンジしていきたいところです。またClojureをvの人に薦められてやってみて、これまたずいぶんと刺激を受けたので、良いとされる言語やフレームワークに手を出してみてその設計思想を学び取るのは今年もやっていきたいですね。
  • 積極的に仲間に頼る。去年はずいぶんと仲間のみんなに助けて頂きました>< お陰様でずいぶんとスタンドプレーで無理やり解決しようとしてソウルジェムが濁るようなことがなくなったかと思います。今年も自分以外の周りに視野を広げつつ、困ったときに助けていただけるようにもっと人間的に良い人になりたいなーと思ってます><

■Problem
去年よくなかった、またはまだまだ改善の余地があるのはこんなところですかね。
  • 基礎力が足りない。低レイヤーな部分の知識が絶望的に足りない。これはPython温泉の際に指摘されたことで、実に悔しいのですがたしかに通信はHTTPより下のレイヤが殆どわかっておらず、言語はObjective-CがわかってもC/C++がわかってない。アルゴリズムの知識も足りなければ、基本的な数学知識も甘い。
  • さらなる設計力の向上が必要。ずいぶんとよくはなりましたが、それでもまだライブラリやSDKの実装のために必要なレベルの設計力がまだ不足しているように感じられます。
  • グループでの開発手法。自分一人の案件というのがほとんどだったので、たまにチーム戦をやるとひどくミスを連発して、見積もりを間違えたりレビュー不足からひどい炎上を招いたりと失敗が続いているため、グループでの開発のやり方を本気で考えなければならないと痛感させられています。
  • テストの仕方。単体テストと、結合テスト。テストの自動化事態はGHUnitのおかげでずいぶんと進んできたのですが、通信を含んだりファイル操作をするテストが単体テストに紛れ込んでいたりして、自動化の妨げとなっています。SenTestKitとモックを使ったほんとうの意味での単体テストと、それ以外のテストをきちんと分ける開発手法を編み出していきたいです。

■Try
ということでそれを踏まえて、今年はこんな感じのことに挑戦したいです。
  • より低レイヤーな知識の学習。TCP/IPとUDPは必修、できればTCP上でmsgpackあたりのRPCプロトコルを自分で実装できる程度にはなりたいと考えています。CとC++の知識も増やしていきたいです。
  • グループでの開発手法を学びたいです。あとはコミュ力向上。私は自分勝手で人の話を聞かず一度良いと感じたらその手法を信じこんでやまない(人に押し付ける傾向がある)ので、たとえその手法が実際に良かったとしても、チーム全体になじまずマイナスの影響を及ぼしている可能性があります。そういったことをなくすにはどうするか?ということで複数の開発手法を学ぶというのと、人の話を聞いてそれを採用する、これに尽きるでしょう。
  • テストの仕方の改善とCIの導入。まずは単体テストの完全自動化と、リリースビルドの日次生成からはじめ、徐々に取得する集計データの量を増やしていく、例えばカバレッジの計測は簡単に思いつきますし、GoogleやMSはバグが発生しやすい箇所を予め計算する方程式を持っているそうで、そういうのを日次で集計できれば全体の品質に寄与できる可能性があります。

2011年12月7日水曜日

CocoaPods に対応していないライブラリを集めた自分用リポジトリを作る方法

この記事はiOS Advent Calendar 2011の7日目の記事になります。ということでもうすぐクリスマスですね。クリスマスプレゼントの準備はお済みですか?まだの方はちょっとオシャレに、今年のプレゼントをCocoaPodsでご用意してみてはいかがでしょうか?


■ご存じ、ないのですか!?

さて念のためCocoaPodsについておさらい。要するにiOS/OS X用のmavenです。以上。細かい点については以下の記事が詳しいのでそちらをご参照ください。っていうかMac Dev JP Advent CalendarとネタがもろかぶりこのCocoaPodsを使うと今まで大変面倒くさかったライブラリの管理が嘘のように簡単になります。たとえば、新しいプロジェクトを始めるときに、
  • 通信したいからASIHTTPRequestを使おう
  • APIのレスポンスがJSONだからJSONKitも必要だな
  • DBにはCore Dataを採用したいから、MagicalRecordも欲しいな
  • Blocksバリバリ使うからBlocksKitは常識だよね
と思ったら、さくっと以下のような設定ファイル(Podfile, mavenで言うところのpom.xml)を書いてやれば、あとはCocoaPodsが指定されたライブラリを取ってきてビルド設定までやってくれるわけです。
platform :ios

dependency 'ASIHTTPRequest' ,'~> 1.8'
dependency 'JSONKit'        ,'~> 1.4'
dependency 'BlocksKit'
dependency 'MagicalRecord'
ARCあり・なしのライブラリを混ぜても全く問題ありません。素晴らしい!!


■公開なんて、あるわけない

とまぁ実に素晴らしいツールなのですが、問題もあります。
  • つい最近できたばかりのツールなので、対応しているライブラリが少ない
  • 対応しているライブラリでも、もともと依存関係処理をするという文化があまりなかったせいか、一部のライブラリ(Reachabilityとか)が内包された状態で出回っていたり、バージョンタグが一つや二つしか付いていないので上手くバージョン管理が出来ない(しかも極端に古かったりバグがあったり、さんざん)
  • CocoaPods自体が開発途中ということもあり、機能がどんどん追加されているようなのだがドキュメントが追いついていない
例を挙げると以下の画像のような感じで、バージョンが一つしかなかったり、あるんだけれど飛んでいたりなどなど。要するに自分の使いたいコードがCocoaPodsの中央リポジトリで管理されていないということがままあります。



■俺達は、自分たちでpodspecを用意することを......強いられているんだ!

ありがたいことに、CocoaPodsには中央リポジトリ以外の任意のリポジトリをライブラリ管理用のリポジトリとして追加する機能があります。この機能を使って、自分で対応していないライブラリのpodspecファイルを書いて、CocoaPodsで使えるようにすることができます。またCocoaPods 0.3.0以降であれば、設定ファイルに直接自分の好きなライブラリのpodspecを書くこともできるみたいです。

まず最初のステップはpodspecを書くことです。今回は例としてMKNetworkKitというライブラリのバージョンv0.8a用のpodspecを書いてみることにします。

# まずは対象のリポジトリをcloneしてくる
# ここでは相手のリポジトリを直接使ってますが、github上でforkして、そっちを使うようにしてもいいです。forkしたほうが自分で自由にコードに改変を加えたりtagを打ったりできますのでよいかも。
git clone https://github.com/MugunthKumar/MKNetworkKit.git
# 移動
cd MKNetworkKit
# 対象のバージョンにHEADを移動します
git reset --hard v0.8a
# podspecファイルのひな形を出力します
pod spec create MKNetworkKit
これでMKNetworkKit.podspecファイルが出力されますので、今度はこのファイルを書き換えます。先ほどcloneしてきたライブラリのソースコードとプロジェクト設定を見ながら、必要なソースコード、必要なリソース、不要なファイル、ライブラリやフレームワークなどのビルド設定を考えて、適切な設定を用意しなければなりません。
今回はこんな感じで書きました:
Pod::Spec.new do |s|
  s.name     = 'MKNetworkKit'
  s.version  = '0.8a'
  s.license  = 'MIT'
  s.summary  = 'Full ARC based Networking Kit for iOS 4+ devices'
  s.homepage = 'https://github.com/MugunthKumar/MKNetworkKit'
  s.author   = { 'MugunthKumar' => 'mknetworkkit@mk.sg' }
  s.source   = { :git => 'https://github.com/MugunthKumar/MKNetworkKit.git', :tag => 'v0.8a' }

  s.source_files = 'MKNetworkKit/*.{h,m}', 'MKNetworkKit/Categories/*.{h,m}'
  s.clean_paths  = 'MKNetworkKitDemo', '*.xcodeproj', 'sample.JPG'
  s.frameworks   = 'CFNetwork'
  s.requires_arc = true

  s.dependency 'Reachability', '~> 2.0'
end
大事なのはsource, source_files, frameworks, requires_arc, dependencyぐらいです。あとは自分しか使わないならでたらめでかまいません。
sourceは:tagの指定の代わりに:commitでコミットのハッシュ値を指定することもできるみたいです。
このpodspecファイルの記法、やたらとたくさんある上にドキュメントがあまりないので、私は結局公式リポジトリのpodspecを探して見よう見まねで書きました。以下、参考にした物を列挙します。
https://github.com/CocoaPods/Specs
https://github.com/CocoaPods/Specs/blob/master/ASIHTTPRequest/1.8.1/ASIHTTPRequest.podspec
https://github.com/CocoaPods/Specs/blob/master/ASIWebPageRequest/1.8.1/ASIWebPageRequest.podspec
https://github.com/CocoaPods/Specs/blob/master/BlocksKit/0.5.0/BlocksKit.podspec
https://github.com/CocoaPods/Specs/blob/master/BlocksKit/0.9.0/BlocksKit.podspec
https://github.com/CocoaPods/Specs/blob/master/SSToolkit/0.1.2/SSToolkit.podspec
https://github.com/CocoaPods/Specs/blob/master/Kiwi/1.0.0/Kiwi.podspec
https://github.com/CocoaPods/Specs/blob/master/MGSplitViewController/1.0.0/MGSplitViewController.podspec
使用するリソースファイルも指定出来るみたいです。
https://github.com/CocoaPods/Specs/blob/master/SVProgressHUD/0.5/SVProgressHUD.podspec
巨大なのになるとこんなのも書けるみたいです。
https://github.com/CocoaPods/Specs/blob/master/RestKit/0.9.3/RestKit.podspec
https://github.com/CocoaPods/Specs/blob/master/Nimbus/0.9.0/Nimbus.podspec

書き終わったら、書いたpodspecファイルに問題がないかをチェックします。
pod spec lint MKNetowrkKit.podspec
何か問題があれば何かエラーが出ます。修正しましょう。何も無ければ何も出ません。
問題が無くなったらひとまずpodspecファイルについては完成です。次はこのpodspecファイルを置くリポジトリをgithubを使って用意します。github上に適当な名前でリポジトリを作りましょう。私は今回 https://github.com/akisute/Specs というリポジトリを作りました。
リポジトリを作ったら、先ほど作ったpodspecファイルを、以下の命名規則に従ってリポジトリの中に配置します:
/podspecのs.name/podspecのs.version/先ほど作ったpodspecファイル
たとえば今回の例では:
/MKNetworkKit/0.8a/MKNetworkKit.podspec
という名前で配置する必要があります。私が試した際は、間違ってると正しくpodspecファイルを認識してくれませんでした。ファイルを配置したらこのリポジトリをgithubにpushします。

さてこれでpodspec用のリポジトリが出来ましたので、今度はCocoaPods側の設定を行います。以下のコマンドを実行します:

pod repo add myrepo リポジトリのURL
これでmyrepoという名前でリポジトリが登録されます。 ~/.cocoapods/ 以下を覗いてみると、確かに myrepo という名前のリポジトリが追加されているはずです。

あとは普通にCocoaPodsを使うのと同じ要領で、Podfileを書いて、pod installすればうまくいくはずです。・・・といいたいところなのですが、一発でうまくいくことはまれで、たいていpodspecファイルの書き方に問題があったりとか、pod化したい対象のライブラリのコードに問題があってビルドが通らないのが普通です。そこで以下のようなワークフローになります。
  1. コードに問題があるなら、コードをforkして自分の思うように書き換えてpush
  2. podspecファイルを修正して自分のpodspec用リポジトリにpush
  3. 組み込みたいプロジェクトのPodsディレクトリ、Podfile.lockファイル、生成されたxcworkspaceを削除。
  4. 再度 pod install MyProject.xcodeproj を実行。
  5. ビルド。
  6. 問題があれば1. に戻る。
うん、これは素人にはお勧めできない。

しかしながらこのCocoaPodに対応するライブラリが増えていけば、iOSの開発はずいぶんと楽になるはずです。ということで積極的に使っていきたいと思います!

2011年11月27日日曜日

Cocoa Framework に用意されていないロックを Objective-C で実装する


Cocoaフレームワークは非同期処理時のロックを取るために、NSLockingというプロトコルと、NSLock, NSRecurrsiveLock, そしてNSConditionalLockという3種類のロックの実装を提供しています。が、残念ながらちょっとまともな非同期コードを書こうと思うとこれでは全然足りません。っていうか、NSConditionalLockがロック抜けるときにしか条件値を書き換えられない実装なのが正直いけてないと思います。これじゃCounting Lock(最初に決めた数だけ同時にロックできるロック。Counting Semaphoreともいう)にもRead/Write Lock(書き込みロックと読み込みロックの二種類が用意され、書き込みロックが取られていない限りは、何個でも同時に読み込みロックが取れる、効率のいいロック)にも使えません。というわけで、Objective-Cで書かれたCounting LockとRead/Write Lockを見つけましたのでご紹介いたします。

http://cocoaheads.byu.edu/wiki/locks

中身はpthread.hのpthread_mutexを使って実装しているようです。一見危なそうですが、Cocoaフレームワークが使用するスレッドは全て内部実装がpthreadなので全く問題ありません。

2011年11月23日水曜日

静的ライブラリ中のシグネチャが衝突してビルドできないときに再ビルドしないでシグネチャを書き換える

皆さんも以下のようなビルドエラーを見たことが一度はあると思います。

これはビルド時に同一プロジェクト内に同じ名前のシグネチャの関数やクラスが存在するためリンクができなくて失敗しているというエラーです。特に以下のようなケースでよく発生します。
  • 自分が作ったクラスや関数の名前と、外部から持ってきたライブラリが使っているクラスや関数の名前が衝突している
  • 外部から持ってきたライブラリ同士でクラスや関数の名前が衝突している
  • 外部ライブラリをインストールする際に、-all_loadしたり-ObjCしたりている
そういうわけで、外部からライブラリをたくさん導入すると、base64やMD5など、プログラム上でよく使われるのに標準で用意されていないライブラリがよく衝突してしまうわけです。大抵の場合はぶつかっているシグネチャの名前をソースコード上でちょっと書き換えて再度ビルドすることで回避ができるのですが、極稀にソースコードを書き換えることができないケースが存在します。以下にそんな場合の対処方法をまとめます。


■具体例
AdMobのSDK(libGoogleAdMob.a)とopenssl(libcrypto.a)を同時に一つのプロジェクトにインストールした時、冒頭の画像のようにMD5というシグネチャがビルド時に衝突してしまうのです。AdMobのはプロプロエタリなので当然書き換えられませんし、opensslのように巨大で複雑なコードに手を入れて再ビルドするのも非常に危険です。そもそもopensslはビルド自体が難しいのです。

このような場合は、ソースコード自体を書き換えるのではなくビルド済みの静的ライブラリ側のオブジェクトファイルを書き換えることで対処を行うことが可能です。
コンパイル時のリンカの設定を変更すれば対処できそうな気もするんですが、GNU ldにはそのようなオプションが見当たりませんでした。なんかSun Solarisのldだと対処できるみたいです。
参考: http://stackoverflow.com/questions/6940384/how-to-deal-with-symbol-collisions-between-statically-linked-libraries
参考: http://stackoverflow.com/questions/393980/restricting-symbols-in-a-linux-static-library

注意: 以下の手順は失敗すると静的ライブラリ自体が完全に破損したり、実行時に深刻な問題が発生する可能性があります!! 以下の解説を見てもちんぷんかんぷんな人は適用しないことを強くおすすめいたします。この手順を適用したことによって発生したいかなる損害についても私は責任をとりかねます。


■静的ライブラリ内部のシグネチャを書き換える方法
静的ライブラリ内部のシグネチャを書き換えるには、以下のようなツールを使用します。

lipo
以前にもご紹介した、Apple純正のユニバーサルバイナリ/ユニバーサルライブラリ(fat binaryともいいます)を作ったりバラしたりするツールです。iOSのライブラリはほぼすべてがi386, armv6, armv7の三種類に対応するfat binaryになっており、基本的にApple純正でないツールはそういったfat binaryに対して歯が立たないので、まずこのツールを使って普通のライブラリに戻した上で、以下のツールを使うわけです。

nm
こいつもApple純正です。バイナリの中に入っているシグネチャの名前を一覧表示することができます。Apple純正なのでfat binaryに対しても使えて超便利です。

objdump
GNU objdumpというツールがありまして、こいつを使うとバイナリの詳細な中身を覗き見ることができます。nmよりも表示される情報が詳細です。Apple純正ではないので、以下で紹介されているようにしてMacPorts経由でインストールするのをお勧めします。
http://d.hatena.ne.jp/amachang/20080401/1207027290

objcopy
GNU objcopyです。ライブラリ内部のシグネチャを書き換える事ができるツールで、objdumpとセットでついてくるのですが、残念ながらiOS向けのバイナリに対しては全く使えません。話すと長くなるのですがバージョンを変えようがarm向けのセットをインストールしようがarでライブラリからオブジェクトファイルを取り出して試みてみようが何やっても一切無駄です。使えませんので諦めてください。
参考: http://www.mail-archive.com/bug-binutils@gnu.org/msg02829.html
参考: http://stackoverflow.com/questions/2231698/how-can-i-easily-install-arm-elf-gcc-on-os-x

objconv
で、使えないobjcopyに代わって、今回の英雄です。こいつを使って実際にライブラリ内部のシグネチャを自由自在に書き換えることができます。メンテもしっかり行われているようで動作も安定しています。以下のサイトからダウンロードできます。
サイト: http://www.agner.org/optimize/#objconv
マニュアル: http://www.agner.org/optimize/objconv-instructions.pdf
残念ながらsource配布のみしか無いため、自分でビルドしてやる必要があります。と言ってもそこそこ簡単で、以下のようにするだけです。
  • ソースコードをダウンロードする
  • zipを解凍する
  • source.zipを解凍する
  • build.shを実行する。ただしこのシェルスクリプトは1行目だけがひどくバグってるので、自分で中を見てビルドコマンドを叩いてやるようにしてください。ね?簡単でしょう?
さて、これで実際にシグネチャの書き換えを行う準備が整いました。


■実践:全く同一のライブラリのシグネチャだった場合
base64なんかでよく発生します。この場合は片方をweakシンボルにします。
weakシンボルとは: http://d.hatena.ne.jp/syohex/20100610/1276180481 がわかりやすいです。

早速やってみましょう。以下の例ではlibTest.a中のbase64_encodeシグネチャを書き換えます。
まずは以下のコマンドで対象のライブラリのfat binaryを通常のバイナリに戻して:
lipo -thin armv6 libTest.a -output libTest_armv6.a
lipo -thin armv7 libTest.a -output libTest_armv7.a
lipo -thin i386 libTest.a -output libTest_i386.a
objconvを実行:
objconv -fmacho -nw:base64_encode libTest_armv6.a
objconv -fmacho -nw:base64_encode libTest_armv7.a
objconv -fmacho -nw:base64_encode libTest_i386.a
lipoで元通りに戻します:
lipo -create libTest_i386.a libTest_armv6.a libTest_armv7.a -output libTest.a
これでビルドが通るはずです。


■実践:同じ名前の違うライブラリのシグネチャだった場合
冒頭のMD5のケースがこれです。名前が同じなのに実装がまるで違うので、weakシンボルにすると深刻なバグが発生します。こういう時は慎重に見定めた上で、使われていないと思われる方のシグネチャをhiddenシンボル(ローカルシンボル)にして、外部ファイルからリンクできないようにしてしまいます。これなら実装は存在しますがリンクされないようになるだけなので、対象のシンボルが外部から使われていないのであればこれだけでいけます。

今度はlibcrypto.a中の_MD5シグネチャを書き換えてみましょう。
こちらもまずはlipoを使って通常のバイナリに戻して:
lipo -thin armv6 libcrypto.a -output libcrypto_armv6.a
lipo -thin armv7 libcrypto.a -output libcrypto_armv7.a
lipo -thin i386 libcrypto.a -output libcrypto_i386.a
objconvを実行:
objconv -fmacho -nl:_MD5 libcrypto_armv6.a
objconv -fmacho -nl:_MD5 libcrypto_armv7.a
objconv -fmacho -nl:_MD5 libcrypto_i386.a
lipoで元通りにして完成:
lipo -create libcrypto_i386.a libcrypto_armv6.a libcrypto_armv7.a -output libcrypto.a
これで無事ビルドが通りました。


■実践:同じ名前の違うライブラリのシグネチャで、かつ外からバリバリ呼ばれていた場合

2011年11月19日土曜日

UIWebView.scrollView に対して KVO を使うと色々面白い

iOS 5より、UIWebViewにscrollViewプロパティが追加され、たとえばスクロールを無効にしたりステータスバーをタップしても一番上に戻らないようにしたりなど、UIWebViewのスクロール周りの処理を外から自由に触れるようになりました。ですが便利なのはこれだけではありません。KVOの仕組みを使うことで、さらにUIWebViewを便利に使うことができます。ここでは私が使っている中で一番のおすすめをご紹介します。

■UIWebViewの描画しているHTMLのcontentSizeを非同期的に、リアルタイムで取得する
UIWebview.scrollViewのcontentSizeプロパティは、UIWebViewの描画しているHTMLの大きさ(contentSize)と同じ値になります。この性質を利用して、contentSizeプロパティにKVOを貼ると、UIWebViewの描画しているHTMLの大きさ(contentSize)が変わったタイミングで通知を受け取ることができます。こんなコードになります。
- (void)viewWillAppear:(BOOL)animated
{
  [self.webView.scrollView addObserver:self forKeyPath:@"contentSize" options:0 context:NULL];
  [self.webView loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://akisute.com"]]];
}
- (void)viewWillDisappear:(BOOL)animated
{
  [self.webView.scrollView removeObserver:self forKeyPath:@"contentSize"];
}
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context
{
  NSLog(@"%s", __func__);
  NSLog(@"  * contentSize = %@", NSStringFromCGRect(self.webView.scrollView.contentSize));
}
このテクを使うことで、例えばUIWebView自体をスクロールさせないようにした上で通知を受け取ってUIWebViewのframeをどんどん更新するようにし、UIScrollViewの中に埋め込んでしまってUIImageViewやUILabelのようにして使うみたいなUIを作ることが簡単にできます。HTMLの高さに依存するコードも作れますし、なかなか面白いですよ。iOS 5はもちろん、iOS 4でも動作します。(余談で解説)

■余談
UIWebViewのscrollViewプロパティは実はiOS 4のころからPrivate APIとして存在します。ですがiOS 5よりパブリック扱いになったおかげか、iOS 4向けのアプリでscrollViewプロパティを触っていてもリジェクトされたりクラッシュすることなく普通に使えるので非常に嬉しいです。iOS 3では使えませんのであしからず。

iOS 5でのSSL/TLS通信時にエラーが発生した場合のエラーコードの調べ方

iOS 5より新たにSecurity.frameworkというフレームワークが追加されました。このフレームワークはAppleが実装したSSL/TLS用のライブラリで、iOS 5よりCFNetwork系のクラス(NSURLConnectionなどの内部実装にも使われています)のSSL/TLS通信時に使われるようになったみたいです。

http://developer.apple.com/library/ios/#releasenotes/General/WhatsNewIniPhoneOS/Articles/iOS5.html の一番下にちょこっとだけ説明があるので、見てみると、
Security
The Security framework (Security.framework) now includes the Secure Transport interfaces, which are Apple’s implementation of the SSL/TLS protocols. You can use these interfaces to configure and manage SSL sessions, manage ciphers, and manage certificates.

For information about the Secure Transport interfaces, see the SecureTransport.h header file of the Security framework.
うむ、ドキュメント無いからヘッダ読めとはなかなか適当ですね。

普通にアプリを作っている最中にこのSecurity.frameworkを直接触る必要は全くないのですが、問題はこのSecurity.frameworkを使っているAppleのframeworkが通信時にSSL/TLS絡みのエラーを吐いたときに発生します。このとき、それらのフレームワークは以下のようなNSErrorを返してきます。
Error Domain=NSOSStatusErrorDomain Code=-9830 "The operation couldn’t be completed. (OSStatus error -9830.)
NSErrorの読み方はErrorDomainに指定されている文字列に応じてエラー番号が定義されているドキュメント/ヘッダファイルを見るというものなのですが、このNSErrorはNSOSStatusErrorDomainのErrorDomainを指定しているにも関わらず<CarbonCore/MacErrors.h>にエラー番号の定義が全く書いていないのです!

色々原因を調べた結果、以下のQ&Aが見当たりました。
http://developer.apple.com/library/mac/#qa/qa1499/_index.html
どうやらSecurity.framework絡みのエラーはNSOSStatusErrorDomainを使っているがMacErrors.hではなく<Security/SecureTransport.h>などに定義が書いてあるみたいなのです。見てみると・・・
/*************************************************
 *** OSStatus values unique to SecureTransport ***
 *************************************************/

/*
    Note: the comments that appear after these errors are used to create SecErrorMessages.strings.
    The comments must not be multi-line, and should be in a form meaningful to an end user. If
    a different or additional comment is needed, it can be put in the header doc format, or on a
    line that does not start with errZZZ.
*/

enum {
 errSSLProtocol    = -9800, /* SSL protocol error */
 errSSLNegotiation   = -9801, /* Cipher Suite negotiation failure */
 errSSLFatalAlert   = -9802, /* Fatal alert */
 errSSLWouldBlock   = -9803, /* I/O would block (not fatal) */
    errSSLSessionNotFound   = -9804, /* attempt to restore an unknown session */
    errSSLClosedGraceful   = -9805, /* connection closed gracefully */
    errSSLClosedAbort    = -9806, /* connection closed via error */
    errSSLXCertChainInvalid  = -9807, /* invalid certificate chain */
    errSSLBadCert    = -9808, /* bad certificate format */
 errSSLCrypto    = -9809, /* underlying cryptographic error */
 errSSLInternal    = -9810, /* Internal error */
 errSSLModuleAttach   = -9811, /* module attach failure */
    errSSLUnknownRootCert  = -9812, /* valid cert chain, untrusted root */
    errSSLNoRootCert   = -9813, /* cert chain not verified by root */
 errSSLCertExpired   = -9814, /* chain had an expired cert */
 errSSLCertNotYetValid  = -9815, /* chain had a cert not yet valid */
 errSSLClosedNoNotify  = -9816, /* server closed session with no notification */
 errSSLBufferOverflow  = -9817, /* insufficient buffer provided */
 errSSLBadCipherSuite  = -9818, /* bad SSLCipherSuite */
 
 /* fatal errors detected by peer */
 errSSLPeerUnexpectedMsg  = -9819, /* unexpected message received */
 errSSLPeerBadRecordMac  = -9820, /* bad MAC */
 errSSLPeerDecryptionFail = -9821, /* decryption failed */
 errSSLPeerRecordOverflow = -9822, /* record overflow */
 errSSLPeerDecompressFail = -9823, /* decompression failure */
 errSSLPeerHandshakeFail  = -9824, /* handshake failure */
 errSSLPeerBadCert   = -9825, /* misc. bad certificate */
 errSSLPeerUnsupportedCert = -9826, /* bad unsupported cert format */
 errSSLPeerCertRevoked  = -9827, /* certificate revoked */
 errSSLPeerCertExpired  = -9828, /* certificate expired */
 errSSLPeerCertUnknown  = -9829, /* unknown certificate */
 errSSLIllegalParam   = -9830, /* illegal parameter */
 errSSLPeerUnknownCA   = -9831, /* unknown Cert Authority */
 errSSLPeerAccessDenied  = -9832, /* access denied */
 errSSLPeerDecodeError  = -9833, /* decoding error */
 errSSLPeerDecryptError  = -9834, /* decryption error */
 errSSLPeerExportRestriction = -9835, /* export restriction */
 errSSLPeerProtocolVersion = -9836, /* bad protocol version */
 errSSLPeerInsufficientSecurity = -9837, /* insufficient security */
 errSSLPeerInternalError  = -9838, /* internal error */
 errSSLPeerUserCancelled  = -9839, /* user canceled */
 errSSLPeerNoRenegotiation = -9840, /* no renegotiation allowed */

 /* non-fatal result codes */
 errSSLPeerAuthCompleted     = -9841,    /* peer cert is valid, or was ignored if verification disabled*/
 errSSLClientCertRequested = -9842, /* server has requested a client cert */

 /* more errors detected by us */
 errSSLHostNameMismatch  = -9843, /* peer host name mismatch */
 errSSLConnectionRefused  = -9844, /* peer dropped connection before responding */
 errSSLDecryptionFail  = -9845, /* decryption failure */
 errSSLBadRecordMac   = -9846, /* bad MAC */
 errSSLRecordOverflow  = -9847, /* record overflow */
 errSSLBadConfiguration  = -9848, /* configuration error */
 errSSLLast     = -9849, /* end of range, to be deleted */

    /* DEPRECATED aliases for errSSLPeerAuthCompleted */
    errSSLServerAuthCompleted   = -9841, /* server cert is valid, or was ignored if verification disabled DEPRECATED */
 errSSLClientAuthCompleted   = -9841,    /* client cert is valid, or was ignored if verification disabled; reusing error as you can only be client or server - DEPRECATED */

};
ばっちり書いてますね。これでエラーの原因も特定できます。今回のケースはerrSSLIllegalParamだったみたいですね。

2011年11月18日金曜日

iOS 5の日本語キーボードの高さに対応する (iOS 3, 4, 5全対応)

iOS 5より日本語キーボードの高さが変わっているので、今まで決め打ちで高さ216pxとかやってレイアウトしていたビューが軒並み使えなくなってしまいました。今後はキーボードが出たり引っ込んだり種類が切り替わったりのタイミングできちんとキーボードの大きさを調べて適切にビューをレイアウトしてやる必要があります。ということでその対応をしたのでメモ。

前提条件として、以下の要件を満たすように作りました。
  • iOS 3, 4, 5全てで正常に動作すること。iOS 3.0でも動作しなければならない。
  • キーボードのframeを適切に取得できること
  • キーボードが出てくるタイミング、消えるタイミング、キーボードの種類が変わるタイミング、全て取れること

■まずはログを見てみる
キーボードの動作のタイミング、およびキーボードのframeは、NSNotificationを使って取得することができます。使用するNotification名はUIWindowのドキュメントに以下のように定義されています。
http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIWindow_Class/UIWindowClassReference/UIWindowClassReference.html
// Available from iOS 2
UIKeyboardWillShowNotification
UIKeyboardDidShowNotification
UIKeyboardWillHideNotification
UIKeyboardDidHideNotification
// Available from iOS 5
UIKeyboardWillChangeFrameNotification
UIKeyboardDidChangeFrameNotification
で、これらのNotification名でNSNotificationCenterにobserverを追加すると、通知が飛んできます。飛んできたNSNotificationオブジェクトのuserInfoプロパティに特定のキーでキーボードのframeが格納されているというしくみです。使えるキーは以下のとおり。
// Available from iOS 3.2
UIKeyboardFrameBeginUserInfoKey
UIKeyboardFrameEndUserInfoKey
// Available from iOS 3.0
UIKeyboardAnimationCurveUserInfoKey
UIKeyboardAnimationDurationUserInfoKey
// Available from iOS 2.0 ~ 3.2 (Deprecated in newer versions)
UIKeyboardCenterBeginUserInfoKey
UIKeyboardCenterEndUserInfoKey
UIKeyboardBoundsUserInfoKey
iOS 3, 4, 5すべてできちんと動作しなければならないので、これらをふまえて、以下のように実装します。
  • Notification名にはUIKeyboardWillShowNotification, UIKeyboardDidShowNotification, UIKeyboardWillHideNotification, UIKeyboardDidHideNotificationを使う。
  • userInfoのキーには、iOS 3.0/3.1のみUIKeyboardBoundsUserInfoKeyを使い、それ以外のバージョンではUIKeyboardFrameEndUserInfoKeyを使う。

■実装してみる
ということでまずはサンプルアプリを作って動かしてみて、実際に動作を見てみることにしました。大体こんな感じのコードです。
- (void)viewWillAppear:(BOOL)animated
{
  // Notification observerを追加する
  [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(onUIKeyboardWillShowNotification:) name:UIKeyboardWillShowNotification object:nil];
  [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(onUIKeyboardDidShowNotification:) name:UIKeyboardDidShowNotification object:nil];
  [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(onUIKeyboardWillHideNotification:) name:UIKeyboardWillHideNotification object:nil];
  [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(onUIKeyboardDidHideNotification:) name:UIKeyboardDidHideNotification object:nil];
}
- (void)viewWillDisappear:(BOOL)animated
{
  // Notification observerを削除する
  [[NSNotificationCenter defaultCenter] removeObserver:self];
}
- (void)onUIKeyboardWillShowNotification:(NSNotification *)notification
{
  NSLog(@"%s", __func__);
  NSLog(@"  * userInfo = %@", notification.userInfo);
  // UIKeyboardFrameEndUserInfoKeyが使える時と使えない時で処理を分ける
  CGRect bounds;
  if (&UIKeyboardFrameEndUserInfoKey == NULL) {
    // iOS 3.0 or 3.1
    // bounds
    bounds = [[notification.userInfo objectForKey:UIKeyboardBoundsUserInfoKey] CGRectValue];
  } else {
    // それ以外
    // frameだがoriginを使わないのでbounds扱いで良い
    bounds = [[notification.userInfo objectForKey:UIKeyboardFrameEndUserInfoKey] CGRectValue];
  }
  // boundsを使った処理をここに書く
}

ログはこんな感じに。

iOS 5.0, iPhone 4S
2011-10-19 10:35:15.007 SampleApp[5675:707] -[SampleViewController viewWillAppear:]
// 前の画面の英字キーボードが一旦引っ込んで出てきている
2011-10-19 10:35:15.502 SampleApp[5675:707] -[SampleViewController onUIKeyboardDidHideNotification:]
2011-10-19 10:35:15.506 SampleApp[5675:707]   * userInfo = {
    UIKeyboardAnimationCurveUserInfoKey = 0;
    UIKeyboardAnimationDurationUserInfoKey = "0.25";
    UIKeyboardBoundsUserInfoKey = "NSRect: {{0, 0}, {320, 216}}";
    UIKeyboardCenterBeginUserInfoKey = "NSPoint: {160, 372}";
    UIKeyboardCenterEndUserInfoKey = "NSPoint: {160, 588}";
    UIKeyboardFrameBeginUserInfoKey = "NSRect: {{0, 264}, {320, 216}}";
    UIKeyboardFrameChangedByUserInteraction = 0;
    UIKeyboardFrameEndUserInfoKey = "NSRect: {{0, 480}, {320, 216}}";
}
2011-10-19 10:35:15.509 SampleApp[5675:707] -[SampleViewController onUIKeyboardWillShowNotification:]
2011-10-19 10:35:15.510 SampleApp[5675:707]   * userInfo = {
    UIKeyboardAnimationCurveUserInfoKey = 0;
    UIKeyboardAnimationDurationUserInfoKey = "0.35";
    UIKeyboardBoundsUserInfoKey = "NSRect: {{0, 0}, {320, 216}}";
    UIKeyboardCenterBeginUserInfoKey = "NSPoint: {160, 372}";
    UIKeyboardCenterEndUserInfoKey = "NSPoint: {160, 372}";
    UIKeyboardFrameBeginUserInfoKey = "NSRect: {{0, 264}, {320, 216}}";
    UIKeyboardFrameChangedByUserInteraction = 0;
    UIKeyboardFrameEndUserInfoKey = "NSRect: {{0, 264}, {320, 216}}";
}
2011-10-19 10:35:15.513 SampleApp[5675:707] -[SampleViewController onUIKeyboardDidShowNotification:]
2011-10-19 10:35:15.514 SampleApp[5675:707]   * userInfo = {
    UIKeyboardAnimationCurveUserInfoKey = 0;
    UIKeyboardAnimationDurationUserInfoKey = "0.35";
    UIKeyboardBoundsUserInfoKey = "NSRect: {{0, 0}, {320, 216}}";
    UIKeyboardCenterBeginUserInfoKey = "NSPoint: {160, 372}";
    UIKeyboardCenterEndUserInfoKey = "NSPoint: {160, 372}";
    UIKeyboardFrameBeginUserInfoKey = "NSRect: {{0, 264}, {320, 216}}";
    UIKeyboardFrameChangedByUserInteraction = 0;
    UIKeyboardFrameEndUserInfoKey = "NSRect: {{0, 264}, {320, 216}}";
}
2011-10-19 10:35:16.162 SampleApp[5675:707] -[SampleViewController viewDidAppear:]
// キーボード引っ込める
2011-10-19 10:35:44.246 SampleApp[5675:707] -[SampleViewController onUIKeyboardWillHideNotification:]
2011-10-19 10:35:44.247 SampleApp[5675:707]   * userInfo = {
    UIKeyboardAnimationCurveUserInfoKey = 0;
    UIKeyboardAnimationDurationUserInfoKey = "0.25";
    UIKeyboardBoundsUserInfoKey = "NSRect: {{0, 0}, {320, 216}}";
    UIKeyboardCenterBeginUserInfoKey = "NSPoint: {160, 372}";
    UIKeyboardCenterEndUserInfoKey = "NSPoint: {160, 588}";
    UIKeyboardFrameBeginUserInfoKey = "NSRect: {{0, 264}, {320, 216}}";
    UIKeyboardFrameChangedByUserInteraction = 0;
    UIKeyboardFrameEndUserInfoKey = "NSRect: {{0, 480}, {320, 216}}";
}
2011-10-19 10:35:44.509 SampleApp[5675:707] -[SampleViewController onUIKeyboardDidHideNotification:]
2011-10-19 10:35:44.511 SampleApp[5675:707]   * userInfo = {
    UIKeyboardAnimationCurveUserInfoKey = 0;
    UIKeyboardAnimationDurationUserInfoKey = "0.25";
    UIKeyboardBoundsUserInfoKey = "NSRect: {{0, 0}, {320, 216}}";
    UIKeyboardCenterBeginUserInfoKey = "NSPoint: {160, 372}";
    UIKeyboardCenterEndUserInfoKey = "NSPoint: {160, 588}";
    UIKeyboardFrameBeginUserInfoKey = "NSRect: {{0, 264}, {320, 216}}";
    UIKeyboardFrameChangedByUserInteraction = 0;
    UIKeyboardFrameEndUserInfoKey = "NSRect: {{0, 480}, {320, 216}}";
}
// キーボード出す
2011-10-19 10:35:55.135 SampleApp[5675:707] -[SampleViewController onUIKeyboardWillShowNotification:]
2011-10-19 10:35:55.136 SampleApp[5675:707]   * userInfo = {
    UIKeyboardAnimationCurveUserInfoKey = 0;
    UIKeyboardAnimationDurationUserInfoKey = "0.25";
    UIKeyboardBoundsUserInfoKey = "NSRect: {{0, 0}, {320, 216}}";
    UIKeyboardCenterBeginUserInfoKey = "NSPoint: {160, 588}";
    UIKeyboardCenterEndUserInfoKey = "NSPoint: {160, 372}";
    UIKeyboardFrameBeginUserInfoKey = "NSRect: {{0, 480}, {320, 216}}";
    UIKeyboardFrameChangedByUserInteraction = 0;
    UIKeyboardFrameEndUserInfoKey = "NSRect: {{0, 264}, {320, 216}}";
}
2011-10-19 10:35:55.397 SampleApp[5675:707] -[SampleViewController onUIKeyboardDidShowNotification:]
2011-10-19 10:35:55.398 SampleApp[5675:707]   * userInfo = {
    UIKeyboardAnimationCurveUserInfoKey = 0;
    UIKeyboardAnimationDurationUserInfoKey = "0.25";
    UIKeyboardBoundsUserInfoKey = "NSRect: {{0, 0}, {320, 216}}";
    UIKeyboardCenterBeginUserInfoKey = "NSPoint: {160, 588}";
    UIKeyboardCenterEndUserInfoKey = "NSPoint: {160, 372}";
    UIKeyboardFrameBeginUserInfoKey = "NSRect: {{0, 480}, {320, 216}}";
    UIKeyboardFrameChangedByUserInteraction = 0;
    UIKeyboardFrameEndUserInfoKey = "NSRect: {{0, 264}, {320, 216}}";
}
// 日本語キーボードに変更
2011-10-19 10:35:58.167 SampleApp[5675:707] -[SampleViewController onUIKeyboardWillShowNotification:]
2011-10-19 10:35:58.168 SampleApp[5675:707]   * userInfo = {
    UIKeyboardAnimationCurveUserInfoKey = 0;
    UIKeyboardAnimationDurationUserInfoKey = 0;
    UIKeyboardBoundsUserInfoKey = "NSRect: {{0, 0}, {320, 252}}";
    UIKeyboardCenterBeginUserInfoKey = "NSPoint: {160, 390}";
    UIKeyboardCenterEndUserInfoKey = "NSPoint: {160, 354}";
    UIKeyboardFrameBeginUserInfoKey = "NSRect: {{0, 264}, {320, 216}}";
    UIKeyboardFrameChangedByUserInteraction = 0;
    UIKeyboardFrameEndUserInfoKey = "NSRect: {{0, 228}, {320, 252}}";
}
2011-10-19 10:35:58.170 SampleApp[5675:707] -[SampleViewController onUIKeyboardDidShowNotification:]
2011-10-19 10:35:58.171 SampleApp[5675:707]   * userInfo = {
    UIKeyboardBoundsUserInfoKey = "NSRect: {{0, 0}, {320, 252}}";
    UIKeyboardCenterBeginUserInfoKey = "NSPoint: {160, 390}";
    UIKeyboardCenterEndUserInfoKey = "NSPoint: {160, 354}";
    UIKeyboardFrameBeginUserInfoKey = "NSRect: {{0, 264}, {320, 216}}";
    UIKeyboardFrameChangedByUserInteraction = 0;
    UIKeyboardFrameEndUserInfoKey = "NSRect: {{0, 228}, {320, 252}}";
}
// 英語キーボードに変更
2011-10-19 10:36:00.483 SampleApp[5675:707] -[SampleViewController onUIKeyboardWillShowNotification:]
2011-10-19 10:36:00.484 SampleApp[5675:707]   * userInfo = {
    UIKeyboardAnimationCurveUserInfoKey = 0;
    UIKeyboardAnimationDurationUserInfoKey = 0;
    UIKeyboardBoundsUserInfoKey = "NSRect: {{0, 0}, {320, 216}}";
    UIKeyboardCenterBeginUserInfoKey = "NSPoint: {160, 336}";
    UIKeyboardCenterEndUserInfoKey = "NSPoint: {160, 372}";
    UIKeyboardFrameBeginUserInfoKey = "NSRect: {{0, 228}, {320, 252}}";
    UIKeyboardFrameChangedByUserInteraction = 0;
    UIKeyboardFrameEndUserInfoKey = "NSRect: {{0, 264}, {320, 216}}";
}
2011-10-19 10:36:00.485 SampleApp[5675:707] -[SampleViewController onUIKeyboardDidShowNotification:]
2011-10-19 10:36:00.486 SampleApp[5675:707]   * userInfo = {
    UIKeyboardBoundsUserInfoKey = "NSRect: {{0, 0}, {320, 216}}";
    UIKeyboardCenterBeginUserInfoKey = "NSPoint: {160, 336}";
    UIKeyboardCenterEndUserInfoKey = "NSPoint: {160, 372}";
    UIKeyboardFrameBeginUserInfoKey = "NSRect: {{0, 228}, {320, 252}}";
    UIKeyboardFrameChangedByUserInteraction = 0;
    UIKeyboardFrameEndUserInfoKey = "NSRect: {{0, 264}, {320, 216}}";
}
// 画面を抜ける、キーボードが隠れる通知より先にviewWillDissappearされるので通知が来ない
2011-10-19 10:36:03.570 SampleApp[5675:707] -[SampleViewController viewWillDisappear:]
2011-10-19 10:36:03.986 SampleApp[5675:707] -[SampleViewController viewDidDisappear:]
iOS 3.1.3, iPhone 3G
2011-10-19 10:43:46.548 SampleApp[352:207] -[SampleViewController viewWillAppear:]
// 前の画面の英字キーボードが一旦引っ込んで出てきているのだが、iOS 3.1.3では引っ込む側の挙動が見られない。出てくるだけになっているようだ。
// さらにDidShowの通知がキーボードがviewDidAppearの呼び出しのあとに行われるようになっている。
// どうやらキーボードがどこに属しているのかが違うみたいだな。
2011-10-19 10:43:47.202 SampleApp[352:207] -[SampleViewController onUIKeyboardWillShowNotification:]
2011-10-19 10:43:47.210 SampleApp[352:207]   * userInfo = {
    UIKeyboardAnimationCurveUserInfoKey = 0;
    UIKeyboardAnimationDurationUserInfoKey = 0.35;
    UIKeyboardBoundsUserInfoKey = NSRect: {{0, 0}, {320, 216}};
    UIKeyboardCenterBeginUserInfoKey = NSPoint: {480, 372};
    UIKeyboardCenterEndUserInfoKey = NSPoint: {160, 372};
}
2011-10-19 10:43:48.253 SampleApp[352:207] -[SampleViewController viewDidAppear:]
2011-10-19 10:43:48.315 SampleApp[352:207] -[SampleViewController onUIKeyboardDidShowNotification:]
2011-10-19 10:43:48.336 SampleApp[352:207]   * userInfo = {
    UIKeyboardBoundsUserInfoKey = NSRect: {{0, 0}, {320, 216}};
    UIKeyboardCenterBeginUserInfoKey = NSPoint: {160, 588};
    UIKeyboardCenterEndUserInfoKey = NSPoint: {160, 372};
}
// キーボード隠す
2011-10-19 10:43:52.854 SampleApp[352:207] -[SampleViewController onUIKeyboardWillHideNotification:]
2011-10-19 10:43:52.862 SampleApp[352:207]   * userInfo = {
    UIKeyboardAnimationCurveUserInfoKey = 0;
    UIKeyboardAnimationDurationUserInfoKey = 0.300000011920929;
    UIKeyboardBoundsUserInfoKey = NSRect: {{0, 0}, {320, 216}};
    UIKeyboardCenterBeginUserInfoKey = NSPoint: {160, 372};
    UIKeyboardCenterEndUserInfoKey = NSPoint: {160, 588};
}
2011-10-19 10:43:53.183 SampleApp[352:207] -[SampleViewController onUIKeyboardDidHideNotification:]
2011-10-19 10:43:53.188 SampleApp[352:207]   * userInfo = {
    UIKeyboardBoundsUserInfoKey = NSRect: {{0, 0}, {320, 216}};
    UIKeyboardCenterBeginUserInfoKey = NSPoint: {160, 372};
    UIKeyboardCenterEndUserInfoKey = NSPoint: {160, 588};
}
// キーボード出す
2011-10-19 10:43:54.621 SampleApp[352:207] -[SampleViewController onUIKeyboardWillShowNotification:]
2011-10-19 10:43:54.629 SampleApp[352:207]   * userInfo = {
    UIKeyboardAnimationCurveUserInfoKey = 0;
    UIKeyboardAnimationDurationUserInfoKey = 0.300000011920929;
    UIKeyboardBoundsUserInfoKey = NSRect: {{0, 0}, {320, 216}};
    UIKeyboardCenterBeginUserInfoKey = NSPoint: {160, 588};
    UIKeyboardCenterEndUserInfoKey = NSPoint: {160, 372};
}
2011-10-19 10:43:54.972 SampleApp[352:207] -[SampleViewController onUIKeyboardDidShowNotification:]
2011-10-19 10:43:54.977 SampleApp[352:207]   * userInfo = {
    UIKeyboardBoundsUserInfoKey = NSRect: {{0, 0}, {320, 216}};
    UIKeyboardCenterBeginUserInfoKey = NSPoint: {160, 588};
    UIKeyboardCenterEndUserInfoKey = NSPoint: {160, 372};
}
// キーボードの種類をここで英語→日本語、日本語→英語に変えているのだが、通知が来ない
// だがiOS 3ではキーボードの種類によって高さが違うということが(基本)ないので気にしなくて良い
[Switching to process 11779 thread 0x2e03]
warning: No copy of  found locally, reading from memory on remote device.  This may slow down the debug session.
// 画面抜ける、viewWillDisappearより先にKeyboardが隠れる通知が来る
2011-10-19 10:44:07.442 SampleApp[352:207] -[SampleViewController onUIKeyboardWillHideNotification:]
2011-10-19 10:44:07.454 SampleApp[352:207]   * userInfo = {
    UIKeyboardAnimationCurveUserInfoKey = 0;
    UIKeyboardAnimationDurationUserInfoKey = 0.35;
    UIKeyboardBoundsUserInfoKey = NSRect: {{0, 0}, {320, 216}};
    UIKeyboardCenterBeginUserInfoKey = NSPoint: {160, 372};
    UIKeyboardCenterEndUserInfoKey = NSPoint: {480, 372};
}
2011-10-19 10:44:07.472 SampleApp[352:207] -[SampleViewController viewWillDisappear:]
2011-10-19 10:44:08.374 SampleApp[352:207] -[SampleViewController viewDidDisappear:]
問題なさそうですね。キーボードの種類が切り替わったタイミングにもUIKeyboardWillShowNotificationとUIKeyboardWillHideNotificationがきちんと呼ばれているようです。これならUIKeyboardWillChangeFrameNotificationを使う必要はあんまり無いように思えます。実際、UIKeyboardWillChangeFrameNotificationを使わないでUIKeyboardWillShowNotificationとUIKeyboardWillHideNotificationだけを使ったアプリをリリースしていますが、特に問題なさそうです。

2011年10月10日月曜日

iOS で Private API を使って Bluetooth Keyboard の状態を取ったりしたいメモ

iOS で Private API を使って Bluetooth Keyboard の状態を取ったりしたいメモです。言うまでもありませんが以下の参考資料に使われているコードとかを使ったアプリが App Store の審査に通ることは絶対にありません。真似しないでね!
あと以下のコードを使って実機で試したコードがまだないので、Jailbrake していない iOS 4.3.5 で動くかどうかすらわかりません。すみません><

GSEventを使ってKeyboardの修飾キーの状態を得る
https://gist.github.com/1242475

iPhoneのイヤフォンマイクやBluetoothキーボードでシャッターを切れるようにするiRemoteShutter
http://hitoriblog.com/?p=1747

iSSHのBluetoothキーボード対応を強化するiSSHPatcher
http://hitoriblog.com/?p=1798

BluetoothキーボードからiPhone/iPadのタスクスイッチを可能にするAltTab
http://hitoriblog.com/?p=3958

BluetoothManager
http://stackoverflow.com/questions/1743610/programmatically-turn-on-bluetooth-in-the-iphone-sdk
BluetoothDeviceを使えばデバイスの電池残量とかも見られそう

2011年9月18日日曜日

iOS, Android, Windows Phoneのメモリ管理とかメッセージングの仕方を調べてみた

ぼちぼちTwitterにつぶやいていたらTogetterにまとめてくださった方がいらっしゃるので、せっかくなのでこちらでも紹介したいと思います。

http://togetter.com/li/189550 (githubみたいにembedできればいいのになーなんて><)

結構気合い入れて調べたのでおすすめです。

2011年9月12日月曜日

UIWebView の Private API を使って BASIC認証のあるページにアクセスする

元ネタはこちら: http://d.hatena.ne.jp/KishikawaKatsumi/20090603/1243968707

仕事でどうしても以下の要件を満たすUIWebViewが必要になったので作りました。
  • 開発環境にBASIC認証がかかっており、そこにUIWebViewでアクセスしたい。
  • アクセス先のHTMLにリンクが埋め込まれているため、URLをhttp://username:password@example.comのように変換することができない。webView:shouldStartLoadWithRequest:navigationType:で頑張ればいける気がしなくともないのですが結局断念しました。
  • 諸事情によりNSURLConnectionが使えない(当然ASIもダメ。あくまでUIWebViewでアクセスする必要がある)。
普通につくるとどうにもうまくいかなかったので、結局UIWebViewをオーバーライドしてPrivate APIを叩く作戦を取ることにしました。

というわけで出来上がったソースコードはこちら。MITライセンスです。
https://gist.github.com/1210372
iOS 4.3.5で動作確認しています。iOS 5でも多分動作します。 iOS 3以下はわかりません><

注意: このコードにはPrivate APIが多分に含まれています。このコードが含まれたアプリをApp Storeに提出しても十中八九審査に通りません。あくまで開発環境での検証用または自分のiPhoneに入れてニヤニヤするコードにのみお使いください。


■しくみ

UIKitをclass-dumpしてたら使えそうなシグネチャを見つけたので、継承してオーバーライドしてゴニョゴニョしてたらできちゃった!って感じです。それにしてもWebKitはPrivate APIにしておくにはもったいない出来の良さですね。このAPIへのフルアクセスがあればAndroidのWebViewと同等かそれ以上に自由に使えるのですが。

2011年8月22日月曜日

UDIDが使えなくなりそうなので、UIIDを使えるようにしました

■2012/11/11追記
iOS 6より[[UIDevice currentDevice] identifierForVendor]というAPIがAppleより提供され、よりプライバシーに配慮した上により安全な方法で自分の開発したアプリケーションを利用するユーザーを個別に認証することが可能になりました。それに伴い拙作のライブラリもidentifierForVendorが利用可能であればこちらを利用するように修正いたしました。今後はこのidentifierForVendor(または広告APIなどを作る場合であれば[[UIDevice sharedManager] advertisingIdentifier])が個体認識の主流になっていくと思われます。identifierForVendorとadvertisingIdentifierの仕様まとめは http://stackoverflow.com/questions/11836225/ios6-udid-what-advantages-does-identifierforvendor-have-over-identifierforadve が一番詳細かなと思います。
追記終


つい先日TechCrunchがiOS5よりUDIDの使用が非推奨になると報道し、巷はiOSでのUDIDの使用についての話題で俄然盛り上がっています。セキュリティ的によろしくないから良い変更だという声もあれば、すでに認証用として使っていてシステム改修が必要という悲観の声もあります。しかし私はどちらかというとUDIDをバリバリ使っちゃってる方陣営の人なので、セキュリティの問題については知っていても、やはりUDID相当の物が無いと不便だなぁと思ってしまうのです。そこでプログラマらしくコードで解決することにしました。

UDIDにはセキュリティの懸念があるし、もう使えなくなる。だったらもっといいIDを超簡単に生成して使えるようにすればいいじゃない。ということでUnique Installation Identifier (インストール毎ID、UIID) を生成するライブラリを早速書いてみました。
ソースコードはこちら。MITライセンスです。
https://github.com/akisute/UIApplication-UIID
昔のgistはこちら

使い方は超簡単で、
  1. アプリが一度削除されたとしても同一のUIIDを返すようにしたいのであれば、#define UIID_PERSISTENT=1して、Security.frameworkをプロジェクトに追加する
  2. UIApplication+UIID.hをimport
  3. [[UIApplication sharedApplication] uniqueInstallationIdentifier]で取れます
はいこれだけです。


■そもそもどうしてUDIDを使うのか

たいていの場合は以下のような理由です。
  • ログイン機構なしに簡易にユーザーの識別をしたいときに、毎回同じ値を返し、かつユーザー事に異なる値が取得出来る何かが必要になるので、UDIDを使う
  • UDID値の取得がいつでもどこでも可能、さらに超簡単で外部ライブラリのインストールなど面倒なことが一切無い
  • しかもAppleのドキュメントにそう使えって書いてある。・・・補足すると使ってもいいよ、ぐらいのニュアンスで、使えという風に推奨はしてないみたいです>< またUDIDのみをキーとしてユーザー情報を保存するな、とも書いてますね。


■UDIDは何がまずいの

主にまずい理由はセキュリティです。特にガラケーのかんたんログインの問題が参考になるのですが、iOSの場合は以下のようなセキュリティ問題が発生します。
  • 相手のUDIDがわかってしまえば、簡単になりすましが可能
  • UDIDの値を返すメソッドの実装を差し替えて、任意の値を返すように出来る。JailBreakしているユーザーであれば誰でも簡単に実行可能、そのためのアプリもCydiaで検索すれば転がっている
  • UDID自体、様々な方法で取得可能。アプリをインストールさせてそこ経由で集めてみたりはもちろん(その際値を取得することに対する警告すら出ない)、iTunesからでも値を確認できる
  • 上記三つの理由のため、その気になればたやすく任意のユーザーになりすませる
  • さらに恐ろしいことにUDIDは端末事に一意になるため、一度値が特定されてしまうと端末を買い換えない限りずっとなりすまされてしまう、リセットできない


■UIIDだとどうなる

Unique Installation Identifier, UIIDはUDIDと異なり「アプリのインストール基盤毎」に一意な値を返すような実装になっています。簡単にまとめると、あるアプリAが、デバイス1, 2, 3にインストールされた場合、UIIDは1, 2, 3の全てで異なる値になります。ここまではUDIDと同じですが、UDIDと違うのはデバイス1に別々のアプリA, B, Cがインストールされた場合、それぞれ異なる値になります。中身は単にCFUUIDというiOSに元からある良くできたID生成ルーチンなんですが、これにより以下のようなメリットが得られます。
  • 外部からIDの値を取得するのが困難。推測も十分に長い上に独立な値なため困難、取得も(UIID_PERSISTENT=1でビルドすればKeychainを使うので)困難です。
  • 万が一何かの間違いで流出したとしても、アプリごとに異なる値になるため他のアプリのセキュリティが犯されたりはしない。また同様の理由で他の悪意のあるアプリからUIIDを取得して攻撃することもできない。
  • プログラム的にUIIDをリセット可能。UUID_PERSISTENT=0であればアプリを消せばユーザーが任意にリセット可能。
  • Keychainを使ったメリットとして、ユーザーがデバイスを乗り換えてもiTunesのバックアップに値が保持されるため、それから復元を行った場合UIIDの値が引き継がれる。
  • 通常のアプリであればUDIDを使っていたケースのほとんどはこのUIIDでそのまま代用可能、あとは過去のUDIDとUIIDのヒモ付だけサーバー側でやってしまえば完全に乗り換えられる
  • それでもどうしてもデバイスごとに一意な値が欲しいならhttps://github.com/gekitz/UIDevice-with-UniqueIdentifier-for-iOS-5/blob/master/Classes/UIDevice+IdentifierAddition.mなど使えばよいのかなと。ただしこの実装はMACアドレスの値を使っているため、MACアドレスの値がわかってしまえばIDをたやすく生成可能で、UDIDの持つセキュリティ上の問題は残ります。


■使用上の注意

UDIDよりは問題が少ないですが、それでもこのUIIDだけで認証を行うような作りのアプリには間違ってもしないように!以下のような問題があります。
  • そもそもこの値は完全にユーザーと一意にヒモ付いた値ではありません。UIIDはあくまでアプリのインストール単位とヒモ付いているだけです。複数のデバイスを一人のユーザーが所有していたりすると完全にアウトですし、インストールされた端末が譲与された場合も対応できません。
  • プログラム的にUIIDはリセット可能なので最悪の場合でもずっとなりすまされるのは回避できるのですが、その際にヒモ付けられていたユーザー固有の情報が消えてしまいます。ログインIDとパスワードで認証をしているのであれば、ログインIDはそのままにしてパスワードだけをリセットすることで、なりすましの問題を解決しつつ、ユーザーの一意性は保ったままにできるため、万が一の際はログインIDとパスワードを使っている方が圧倒的に利便性が高まります。
  • 以上の理由により、UIIDはあくまで簡易的・一時的にユーザー認証をする時に使用し(たとえばユーザーが購入したアプリ内課金の商品をアプリが消されるまでの間だけ履歴として持っておいたり、ゲームのランキング等で匿名だけれど点数ランキングに参加できるようにしたり)、正式で完全なサービスはログインIDとパスワードによって提供するべきです。そうすることで一人のユーザーが複数のデバイスでサービスを使えるようになります。さらにはAndroidとも連携できたりしますしお得です。


■っていうか

全部高木先生が一年前に言っている通りになっちゃってるじゃないすか!っていうか私が作った物もこの高木先生がおっしゃってる「アプリ専用の(セキュアな)独自IDを生成してそれを保存して使う」というものの実装にすぎません。しかしまったく、せっかく警告してもらっても、人間実際に問題に直面しなければなかなか手をつけないものですね><

しかし、しかしですね、あえてここで一言、エンジニアとして申させていただきたい。

私、エンジニアが欲しいのはセキュリティ上正しい実装の方法だとか、概念だとか、ましてやどこそこのログイン方法はいけてないから直せや、などという文章でもないのです。我々が欲しいのは、「すでに実装されている、セキュリティ上正しくて、猿でも理解できて、1分で組み込めて、どのような環境でも動き、ユーザーが会員登録なんて面倒極まりないことをしなくても済むユーザー認証の手段」なんです。要するに、
// 何か良くわからんけどこのトークンをHTTPS経由でPOSTして認証しておけば超スーパー確実かつセキュアで猿でも実装できてハッピーになる
[[NSAuthentication sharedUser] authenticationToken]
↑コレが今すぐ欲しいんですよ、我々エンジニアというのは。そうすれば誰だってUDIDを使って認証するみたいな面倒くさいことするわけ無いじゃないですか。頼まれたってやりませんよ。

私はユーザー認証をしたいだけなんです、それも可能な限り楽に。口で何と批判しようが、正しい方法を教えようが、世の中は決して変わらないと思います。みんな楽をしたいから。なのでAppleには是非UDIDを廃止するこの機会にぜひ上記のような何かをUIKitなりFoundationなりに組み込んで欲しいですね。こういうところも、良いプラットフォーマーの責務の一部じゃないかなと。

2011年8月12日金曜日

iOS で ImageIO を使ってアニメーションGIFファイルを生成してみる

参考にしたのはこちら。
http://pojos-devlog.blogspot.com/2005/08/saving-animated-gif-using-coregraphics.html

iOS 4以降でよければImageIOフレームワークが使えるためむちゃくちゃ簡単です。任意のUIImage / CGImageRefから好きなようにアニメーションGIFを生成できます。



iOS 3以前の場合は・・・頑張れとしか・・・

メモ: CoreDataで更新処理をするときは、lockをわすれずに

単なるメモ書きです><

http://twitter.com/#!/akisutesama/status/83521489382555650
http://twitter.com/#!/akisutesama/status/83521729380626433
ある一つのCore Dataのモデルを非同期的に複数箇所から更新するときは、たとえどんなに軽微な、プロパティ一つだけの、他からは触られない様な変更ですら、きちんとlockを取らないと危険ということがわかった。API実行クラスだけでは不十分であった。非同期であればロック必須。
変更を行うコードブロックを渡して、内部で安全にロックして実行、必要に応じてロールバックや失敗通知も行える様にする仕組みを作ろうと思った。
CoreDataのモデルオブジェクトの更新はただのsetterプロパティの使用だけで発生してしまうのでついつい忘れがちになるのですが、これが原因で実際にクラッシュしたアプリもあるので油断禁物。

UIPanGestureRecognizerはiOS4.0ではtranslationプロパティを正しく返さない

UIPanGestureRecognizerのtranslationプロパティは、iOS 4.0でかつUIScrollViewの配下になっているviewに対して取り付けた場合、常にCGPointZeroを返してしまうようです。iOS 4.1のシミュレータで確認したら直ってましたので、iOS 4.0限定だと思われます。というわけでvelocityプロパティをかわりに使っておくことをお進めします。

検証結果はこちら

[NSObject load] と [NSObject initialize] の違い

クラスがObjective-Cのランタイムにロードされ利用可能になったタイミングで、そのクラス全体の初期化を行いたいということはよくあると思います。Objective-CではNSObjectクラスの以下のメソッドを用いてクラス全体の初期化を行うことができます。
  • + load
  • + initialize
この2つですが、結構挙動が異なります。詳細については以下のとおり。
http://cocoawithlove.com/2008/03/cocoa-application-startup.html
  • loadメソッドはクラスがロードされて利用可能になったら即座に呼び出される。
    • このとき、自分以外の他のクラスはまだロードされていない可能性があるので、自分以外のクラスを利用するような初期化はできない。
    • main関数の内部のNSAutoReleasePoolが用意されるよりも先に呼び出されるので、autoreleaseを使うような初期化を行う場合には自分でNSAutoReleasePoolを生成して管理する必要がある
  • initializeメソッドはそのクラスに実際のアクセスが最初に発生したタイミングで呼び出される。
    • 要するに一度も使われないクラスでは呼び出されない。
    • 自分以外のクラスもロードが完了しているので、自由に他のクラスを利用できる。
    • autoreleaseについても特に気にしなくて良い。
基本はinitializeメソッドを使うほうがより安全で確実なうえに、使われないなら初期化されないので経済的でいい感じです。こちらを使うことをお勧めします。

またloadメソッドについては、iOS実機で自家製frameworkを使っているを使っているとき、framework内部にビルドされているクラスのloadメソッドが呼び出されないという問題があります(静的ライブラリ.aについては未検証)iOSシミュレータおよびMacではきちんとframeworkに含まれているクラスについてもloadメソッドが呼び出されるのですが・・・ともかく地雷が大きいので避けたほうが懸命です。

[UIView willMoveToSuperview:] が便利です

UIKitやFoundationには、iOS 2.0のころから存在するのに、意外と知られていない便利なメソッドやプロパティがたくさんあります。今回はUIViewのメソッドをご紹介します。

UIViewはUIViewControllerと違ってライフサイクルが単純で、どのタイミングで自分自身が画面上に追加されたのか、どのタイミングで自分自身が画面から外されたのか、などを把握しづらいとお嘆きの方がいらっしゃると思います。事実その用途のためだけにUIViewControllerを使ってプログラミングをしている人も見かけます。そこで以下のメソッドをご紹介です。
  • willMoveToSuperview:
    • 自分自身が新しいSuperview以下に移動しようとしたとき(新しいSuperviewに対してaddSubview:されようとしたとき)に呼び出されます。
  • didMoveToSuperview
    • 自分自身が新しいSuperview以下に移動したとき(新しいSuperviewにaddSubview:されたとき)に呼び出されます。
  • willMoveToWindow:
    • 自分自身が新しいWindow以下に移動しようとしたとき(新しいWindowに対してaddSubview:されようとしたとき)に呼び出されます。
  • didMoveToWindow
    • 自分自身が新しいWindow以下に移動したとき(新しいWindowに対してaddSubview:されたとき)に呼び出されます。
  • didAddSubview:
    • 自分自身に他のviewがsubviewとして追加されたときに呼び出されます。
  • willRemoveSubview:
    • 自分自身のsubviewsから他のviewが取り除かれようとしているときに呼び出されます。
これらのメソッドをUIViewのサブクラスでオーバーライドすることにより、かなりの自由度でviewの動きをコントロールすることができます。
たとえば自作のUIViewで、画面にviewが追加されたタイミングで何かしたい・・・というときなどは以下のようにできます:
- (void)willMoveToSuperview:(UIView *)newSuperview

{
NSLog(@" * superview = %@", newSuperview);
NSLog(@" * superview's window = %@", newSuperview.window);
// UIViewControllerでいうところの loadView 兼 viewDidLoad 兼 viewWillAppear 兼 viewWillDisappearみたいなタイミング
}

- (void)didMoveToSuperview
{
// UIViewControllerでいうところの viewDidAppear 兼 viewDidDisappear みたいなタイミング
// ここで、もしsuperviewがあり(画面に表示される可能性があり)、まだ自分自身のデータが初期化されていない場合には
// reloadDataして初期表示データを読み込む
// superviewがない場合には画面から外されたのですべてのビューまわりをリセットして、次の表示に備えるようにしておく
if (self.superview) {
if (!self.someData) {
[self reloadData];
}
} else {
self.someData = nil;
[self __resetOutlets];
}
}

- (void)willMoveToWindow:(UIWindow *)newWindow
{
NSLog(@" * window = %@", newWindow);
// いまいち使いづらいのでwillMoveToSuperviewとかを使うようにしてます
}

- (void)didMoveToWindow
{
// いまいち使いづらいのでdidMoveToSuperviewを使うようにしてます
}
これでUIViewの使い勝手もアップ!ですね。