2013年5月2日木曜日

Parse.com の Cloud Code ハマりどころ

Parse.comのCloud Codeを触っていてハマった点や気づきにくい仕様を列挙させて頂きます。

■Parse.Cloud.useMasterKeyを呼び出すことで特権ユーザー権限になれる

Cloud Code上でACLによるアクセス制限を無視して現在のrequest.userとは関係なしにデータを操作したいということが多々あるかと思います。そのような場合は以下のようにリクエスト処理の先頭でParse.Cloud.useMasterKeyメソッドを呼び出してください。

useMasterKeyの効果は呼び出された瞬間からリクエストが終了するまで有効です。

■Parse.Cloud.beforeSaveやParse.Cloud.afterSaveはData Browserから直接Rowを追加した場合にも呼び出される

これは意外とハマりどころです。例えばData BrowserからUserを追加した時などにUserに対してつけておいたParse.Cloud.beforeSaveが発動するなどしてよく発生します。Data Browserから直接Rowを追加した場合、request.userはnullになりますので注意してください。また追加元がData Browserなのか普通のクライアントなのかを判定する手段が用意されていないため、処理を分岐させたくなるととたんに話が面倒なことになります。
投稿時間：
タグ：

Parse.com使ってみた

いまさらですがBaaS (Backend as a Service) が来てるらしいですので、とりあえずParse.comに手を出してみました。

■良かった所

  • クライアント側の実装が楽で安定しています。デバッグログも充実しており、Parseが原因でクラッシュするということもなく、特に悩まされるところはありませんでした。
  • 料金がとにかく安いです。個人で使うぶんには全く問題ないかなと思います。

■イマイチだった所

  • サーバーがUSなせいもあってそれほどレスポンスはよくありません。
  • セキュリティモデルをまじめに構築しようとするとかなり面倒くさいです。
  • Cloud Codeに山ほどハマりどころがあります。詳しくは別記事で。
  • バッチ（定期実行）に相当するものがありません。自宅のPCをから毎晩のタスクを定期実行するとかそういう悲しい方法で回避するしかありません。
  • Dev版と製品版で同じバックエンドを使うことになるので、公開したアプリの継続開発が面倒そうです。これは違う名前で開発版アプリを作ることで回避することができます。
  • 料金。エンタープライズで使うときの料金体系が不明瞭で、「連絡してね」の一言で済まされているため不安が残ります。
  • データの可搬性。一応Exportオプションは用意されていますが形式が独自形式のJSONなので自前で手元のDBなどへのImportツールを作る必要があり結構面倒だと思います。手軽にExcelやCSVでExportするオプションがほしいです。

■まとめ

プロトタイピングや小規模なアプリには良いと思います。ただしデータ可搬性をまじめに考えるのであればRESTful APIを使う必要があり、そうなってくるとせっかくよくできているクライアント側実装のほとんどが無駄になるため微妙に感じられます。Cloud Codeはハマリどころが多いのがまず問題ですが、わかってしまえば問題ないと思います。
投稿時間：
タグ：

2013年3月24日日曜日

Unity でソースコードに書いたリテラル文字列の文字コードを調べてみた

Unity3.5.6においてソースコード上にリテラル文字列として日本語を置いた時、時々ログ出力が上手くいかないことがあるということがわかり、ちょっと調べてみました。するとリテラル文字列を置いたソースコードの種類に応じて文字コードが違うということがわかりました。
  • C# (.cs) はUTF-16
  • JS (.js) はUTF-8
  • Boo (.boo) は不明
  • ネイティブのiOSはUTF-8
また出力する側、要するにDebug.Logメソッドは基本的にUTF-8のみを受け付けられるようになっているということがわかりました。まとめると以下の図のようになります。



最終的にJSファイルに全ての日本語リテラルをまとめて回避しましたが、そもそも日本語リテラルは使わず国際化文言ファイルみたいなものを別途用意しておいたほうが筋が良いと思います。iOSならLocalizable.stringsがありますしね。
投稿時間：
タグ： , ,

2013年1月20日日曜日

SLComposeViewControllerでFacebook投稿する際に投稿が失敗してしまう問題

iOS 6.0より追加されたSocial.frameworkは大変お手軽に使用できて、ユーザーさんも毎回毎回素性の知れないアプリに対してTwitter/Facebookログインをし直すという手間と危険性から開放される便利な代物ですが、ちょっとした落とし穴を見つけたのでご紹介します。

SLComposeViewControllerを使っている時に、同じ文面でもTwitterには正常に投稿できるがFacebookには投稿に失敗してしまうというケースが発生することがあります。画面にはただ「Facebookに投稿できません」とアラートが表示されるだけですし、SLComposeViewControllerは投稿失敗時のerrorに対してコールバックblockもdelegateも存在しないので原因を調べることもできません。

実機のコンソールログを見てみると以下の様なエラーになっています。
Jan  8 11:01:25 akisute-no-iPhone sociald[6444] : 2013-01-08 11:01:25.665|sociald|0x1fd65e70: Request status was 400
Jan  8 11:01:25 akisute-no-iPhone sociald[6444] : 2013-01-08 11:01:25.668|sociald|0x1fd65e70: SLDFacebookPostUpload: The response indicates an error
 Parameters:{type = immutable dict, count = 1,
 entries =>
  2 : {contents = "error"} = {type = immutable dict, count = 3,
 entries =>
  0 : {contents = "message"} = {contents = "(#100) The parameter link is required"}
  1 : {contents = "type"} = {contents = "OAuthException"}
  2 : {contents = "code"} = {value = +100, type = kCFNumberSInt64Type}
 }
 
 }
 . 
 
 HTTP status 0
SLComposeViewControllerが裏で使用しているsocialdのSLDFacebookPostUploadクラスがエラーを吐いています。一見しただけだとOAuthExceptionとか書いてあって認証系のエラーかと勘違いしてしまいそうですが、実はこれSLComposeViewControllerのaddURL:メソッドに「空の」NSURLインスタンスを渡した時に発生するエラーです。以下のコードで簡単に実験することができます。

対策としてaddURL:しようとしているURLのschemeがnilまたは空文字列だったらaddURL:しないとすればOKです。しかしTwitterでは通るのにFacebookだけ通らないのはなんだか納得いかない・・・＞＜
投稿時間：
タグ： ,

エンジニアサポートCROSS 2013で発表してきました

先日ニフティさんが主催されたエンジニアサポートCROSS 2013におじゃまさせていただきました。このエンジニアサポートCROSSは年に１回、去年から開催されているらしいのですが、なんといっても大手企業さんが主催ということで
  • 参加者がとにかく豪華
  • プレモル飲み放題ケンタッキー食べ放題という夢の様な環境
  • それでいてきちんとWeb系/Make系コミュニティのギークっぽい雰囲気のカンファレンスになっている、スーツではない
という独自の魅力があるカンファレンスになっていました。

で、このエンジニアサポートCROSSにはアンカンファレンス枠があって、参加者が自由気軽にその場でプレゼンを行う事ができる場がありましたので、せっかくだからということで私も発表させて頂きました。


内容については先日リリースしましたダンゴルのサーバサイド側の裏話です。といってもスライド見れば分かる程度のものです。

来年は正規のスピーカー枠で参加したいです＞＜
投稿時間：
タグ：

2012年12月3日月曜日

Unity Asset Server でブランチ切ったりタグつけたりする方法

弊社のUnityプロジェクトではUnity Asset Serverを使ってソースコードやアセットの管理を行なっているのですが、以前ブログに書いた通りこのUnity Asset Serverさんは標準でブランチもなければタグもサポートしていないというCVS以下の素敵なシロモノです。しかしながらやはり開発のニーズ上、継続的に開発するためにはブランチやタグが必要になってきます。そこでUnity Asset Serverを使っていかにしてブランチやタグを運用するかという方法を考えてやってみましたので共有いたします。


■基本方針

基本方針は要するにSVNのやり方をパクります。すなわち、
  • タグやブランチはリポジトリのコピーとして表現する
  • リベースやマージは気合でなんとかする
以上二点です。

さてリポジトリのコピーですが、一応Unity Asset Serverではリポジトリのコピーの作成が可能になっています。



こちらをクリックしてリポジトリをコピーしてください。注意点としてはこのリポジトリコピーは他のユーザーが一人でもAsset Serverに接続しているとコピーが出来ないので、社内に呼びかけて全員のUnityをシャットダウンするなり何なりしてください。誰が接続しているか特定したい場合はUnity Asset Serverが動いているサーバで
ps aux | grep unity
とか叩けばなんとなくわかります。


■タグを付けたい

これは簡単です。Asset Serverに接続して、タグが付けたいバージョンがヒストリの先頭にある状態で、先述したリポジトリのコピーを行います。あとはコピーしたリポジトリに触らないようにすればタグの完成です。

注意点として、タグが付けたいバージョンがヒストリの奥のほうにあると基本的には綺麗にタグが切れません。そのようなコミットをする前にタグを切ってください。


■ブランチを切りたい

これもまだ簡単です。Asset Serverに接続して、ブランチの根っこにしたいバージョンがヒストリの先頭にある状態で、先述したリポジトリのコピーを行います。あとはこちらのリポジトリに作業者全員が接続先を切り替えて、新しいコミットを重ねていけば良いです。

注意点として、タグと同様に例によってバージョンがヒストリの奥のほうにあると綺麗にブランチが切れず苦労することになりますので、コミットの重ね方には最新の注意を払う必要があります。

それから各作業者がブランチを切り替える際の手順にも注意する必要があります。
  1. Asset Serverに接続してdisplayを選択。
  2. 新しいブランチとなるリポジトリを選択してconnect。
  3. リポジトリの切り替えが終わったらupdateを行う。
  4. マージするかどうか聞かれたら、ブランチの切り替えなので、すべてDiscard my changesを選択すること。

■ブランチをリベースしたい

ここからがちょっとした地獄の始まりです。まずはリベースから。例として1.0.1ブランチのブランチ元である1.0.0をリベースする手順を示します。
  1. Asset Serverに接続して、リベース元となるブランチ (1.0.0) にconnect。
  2. リポジトリの切り替えが終わったらupdateを行う。
  3. マージするかどうか聞かれたら、ブランチの切り替えなので、すべてDiscard my changesを選択すること。
  4. Asset Serverに接続して、リベース先となるブランチ (1.0.1) にconnect。
  5. リポジトリの切り替えが終わったらupdateを行う。
  6. マージするかどうか聞かれたら、リベース元のコードをすべて新しい接続先のブランチに上書きしたいという処理になるので、ソースコードとシェーダーコードについてはMergeを、その他のシーン、プレファブ、テクスチャ、モデル、音などはすべてIgnore server changesを選択する。
  7. このままだとなぜかコードは変更されているのに変更差分をUnityが認識しない悲しい状態になるので、メニューからAssets > Reimport allを選択して変更差分をUnityに認識させる。
  8. マージに失敗したコードおよびシーン、プレファブ、テクスチャ、モデル、音などを手でマージする。
  9. コミットして完了。
これで何とかリベースっぽいことができるようになります。


■ブランチをマージしたい

ブランチのマージは単にリベースの逆をやるだけです。例として1.0.1ブランチをmasterにマージする手順を示します。
  1. Asset Serverに接続して、マージ元となるブランチ (1.0.1) にconnect。
  2. リポジトリの切り替えが終わったらupdateを行う。
  3. マージするかどうか聞かれたら、ブランチの切り替えなので、すべてDiscard my changesを選択すること。
  4. Asset Serverに接続して、マージ先となるブランチ (master) にconnect。
  5. リポジトリの切り替えが終わったらupdateを行う。
  6. マージするかどうか聞かれたら、マージ元のコードをすべて新しい接続先のブランチに上書きしたいという処理になるので、ソースコードとシェーダーコードについてはMergeを、その他のシーン、プレファブ、テクスチャやモデルや音などはすべてIgnore server changesを選択する。
  7. このままだとなぜかコードは変更されているのに変更差分をUnityが認識しない悲しい状態になるので、メニューからAssets > Reimport allを選択して変更差分をUnityに認識させる。
  8. マージに失敗したコードおよびシーン、プレファブ、テクスチャ、モデル、音などを手でマージする。
  9. コミットして完了。
見ての通り、リベースとほとんど同じですね。

投稿時間：
タグ： ,

2012年12月1日土曜日

PySpa アドベントカレンダー 1日目 〜バカとPythonと芳泉閣〜

PySpaアドベントカレンダーというイベントに参加してみたところ、僭越ながら初日を努めさせていただくことになりました＞＜ ということで本日は技術ネタではなくてPySpaというイベントとともに自分の職歴でも振り返ってみようと思います。


■そもそもPySpaってなんぞや

vの人という主犯格が定期開催している温泉旅館に泊まるイベントです。名前に反して実はPythonは全然関係ないです。詳細は以下のページとか見てみてください。
https://github.com/pyspa/pyspa
http://voluntas.hatenablog.com/entry/20081024/1218125470

基本的にvの人の知り合いばかりで固定PySpaメンバーと言えるメンバーがいるのですが、昔からいた人が仕事の都合とかで疎遠になると新しい人が定期的にやってきて全体が保たれているという感じの不思議な輪が形成されているのが特徴ではないかと思っています。後、全員やたら技術力があります。


■SIer時代（2008~2009年）

最初に参加したのが2008年に開催された第4回です。記憶が曖昧なのですが、確かTwitterだか何だかで参加者を探していたところに無理やり飛び込んだのがきっかけです。よくやった当時の自分。当時は新卒入社したSIerの会社でJavaを書いていて、Pythonって面白そうだなーとか考えて手を出していたころだったのでPythonの勉強会のノリで参加してました。あとそういえばiPhone 3Gを発売日当日に買い、Apple信者生活を開始しました。

第4回の記録
http://akisute.com/2008/10/4python-1.html

うん、今見たら恥ずかしくて死にたい。といっても年中後から振り返ったら恥ずかしくて死にたいようなことしかしてない気がするので今更気にしたら負けです。次行きます。次。
第5回からは完全にiPhone開発ばっかです。あとこの一年で随分PySpaのノリを理解した感じを文体から感じ取れます。

第5回の記録
http://akisute.com/2009/06/5-python.html

この期間は自分の基礎となる技術や興味を見つけることができた貴重な時期でした。最も向上心がありバックグラウンドもない新人時代を非常に有意義に過ごすことができたのではないかとおもいます。あと、今現在わずかに残っているのみとなった社会人として必要な常識などは全てこの時期に身につけさせていただきました＞＜ 本当にありがとうございました＞＜


■Web屋時代（2010年~2011年）

2009年末に新卒入社したSIerの会社を退職してビープラウドに転職しました。転職理由はもはや覚えていないのですが、確かこのままこの会社にいてはスキルアップにならない！よりよい環境へ移るべきだ！などという意識の高い社二病精神か何かが原因だった気がします。

このへんから面倒になったせいかPySpaメンバーの内輪みたいな感じになったせいもあるのかブログへの参加記録が途絶えてしまっていますが、PySpa自体には二年間毎回かかすことなく参加しておりました。というのもPySpa自体がビープラウドの非公式社外リクルートイベントみたいな感じになっていた関係上、半数近くの社員がPySpaに参加する時があったりしたからです。

例えば今回のアドベントカレンダー参加メンバーだと

12/1 akisutesama
12/3 tokibito
12/4 torufurukawa
12/8 shimizukawa

あたりがPySpa経由で雇用されたビープラウド社員だったりします。

第6, 7, 8, 9, 10と参加してきたPySpaですが、10回でいったん定期開催を締めようというvの人の考えで第10回を最後にしばらく開催が途絶えてしまいました。そのかわり定期開催する文化はPyFesへと引き継がれていきました。

この期間は良い意味でも悪い意味でも自分のアイデンティティが確立された期間でした。何か捨ててはいけないたぐいの常識を投げ捨ててしまった変わりに職業iOSプログラマとしてのキャリアが確立された感じでしょうか。あとは仕事でひどく失敗した時期でもありました。前職SIer時代では失敗ができるような機会はなかったのですが、ビープラウドでは数回ひどく失敗してご迷惑をお掛けしたことがありました。ほんとスミマセン＞＜ お陰様で人類としての社会常識はなくなりましたがプロとして仕事を進める常識は多少身につきました＞＜


■ゲーム屋時代（2012年~）

2012年の2月にビープラウドを退職して変なゲーム会社に転職して以来、しばらくご無沙汰していたPySpaですが、今年の10/26に開催されたのでふらっと参加してきました。

感想、みんな年食い過ぎ。

高齢化の並はPySpaにも押し寄せているのかいないのかわからんのですが、第4回第5回の頃の大学生のきゃっきゃうふふ的ノリはかなり鳴りを潜め、仕事の話をしたりだとかが増えたり徹夜組が全滅して朝早起きになってたりお菓子の減りが悪くなってたりと随所におっさん臭がしてきております。ピンチです＞＜ まぁ時間の流れというのはそういうものなのかなぁと私自身おっさん的に思っております。

この期間は自分のこれまでの集大成であるような気がしています。子供の頃にハマりまくっていたゲームへの愛情と、SIer/Web屋時代に培ったサーバ側技術と、iPhoneリリースからやってきたiOS開発の集大成という感じです。そして随分と責任ある立場をまかされるようになってしまった気がします。うーん年だ。このあとどうしよう。とりあえず今しばらくはゲームが最高に面白いのでゲームをやろうと思ってます。

余談ですがうちらのゲームもうすぐリリースらしいです。一応宣伝。
http://www.donpy.net/appinfo/18791.html




■まとめ

こうして振り返ると私の仕事人生はiPhoneとPySpaとともに歩んできたんだなぁと思います。iPhoneは私に夢中になって開発できる何かをくれましたし、PySpaは私にスキルと人脈と情熱をくれました。この２つがあったからこそここまでやってこれたんだなぁと思っています。これからもまぁそんな感じで適当にやっていきます。

最後になりましたけれども、PySpaを毎年開催してくださっているvの人と、今回のアドベントカレンダーを企画していただいたとんぷーさん、どうもありがとうございます！

それでは明日はshkumagaiさんよろしくおねがいしまーす！
投稿時間：

2012年11月12日月曜日

Unity 3.5 以下でプリプロセッサ定義を上手く使う方法

C/C++/Objective-Cベースのプロダクトのビルドシステムを構築するときに大変便利なのがプリプロセッサのdefineマクロです。defineマクロを使って環境を切り替えたり不要なログコードを削除したりなどは皆さんよくやってるかと思います。C#にも同様のプリプロセッサ定義が用意されているみたいですので、こちらを使ってUnityプロジェクトのビルドシステムを構築できないかと思ってやってみました。


■プリプロセッサ定義の使い方 (Unity 4以降)

Unity 4.0よりプリプロセッサ定義がUnity本体によってサポートされるようになりました！ビルドスクリプトからも自由にアクセスが可能になっており、非常に簡単に扱うことが可能です。
詳しくはけいごさんのブログに完璧にまとめられていますのでそちらをご覧ください。
http://anchan828.tumblr.com/post/32669868103/define


■プリプロセッサ定義の使い方 (Unity 3.5以降)

ここからが本題になります。Unity 3.5以前はプリプロセッサ定義を公式にサポートしていません。そこで以下の４種類のファイルをAssetsフォルダ直下に置くことでプリプロセッサ定義を読み込ませます。
/Assets/smcs.rsp (C#用)
/Assets/gmcs.rsp (C#エディタスクリプト用)
/Assets/us.rsp   (UnityScript、俗にJSと呼ばれている物用)
/Assets/boo.rsp  (Boo用)
このrspファイルにはC#コンパイラのコンパイラオプションとして渡すオプションが記述できます。ですので http://linux.die.net/man/1/mcs などに列挙されているコンパイラオプションであればひと通りなんでも使用可能です。今回はプリプロセッサ定義をやりたいので、以下のように書けばOKです。
-define:DEBUG
複数の定義が書きたい場合は、
-define:DEBUG -define:USE_DEV_SERVER
のようにスペースで空けて複数記載するか、
-define:DEBUG
-define:USE_DEV_SERVER
のように改行して複数記載するか、
-define:DEBUG;USE_DEV_SERVER
のようにセミコロンで列挙して書くことができます。注意点として、C/C++/Objective-Cのdefineマクロと違って
-define:DEBUG=1
のように値を定義することはできないみたいです。あくまでシンボルを作るだけみたいですね。

以下Twitterでのやりとりです。

さて、これでプリプロセッサ定義はバッチリできるようになったのですが、問題はこれをビルドごとに書き換える方法です。最初はビルドスクリプトでこのrspファイルを書き換えていたのですが、どうもこれをUnityが全く認識しないのです。普通にファイルをただ書き換えてもダメなようです。

そこで黒魔術を導入します。以下のスクリプトで使われているコードを利用して、無理やり書き換えた後のrspファイルをUnityに認識させます。
https://github.com/prime31/P31UnityAddOns/blob/master/Editor/GlobalDefinesWizard.cs#L131
AssetDatabase.Refresh();
reimportSomethingToForceRecompile();

private void reimportSomethingToForceRecompile()
{
 var dataPathDir = new DirectoryInfo( Application.dataPath );
 var dataPathUri = new System.Uri( Application.dataPath );
 foreach( var file in dataPathDir.GetFiles( "GlobalDefinesWizard.cs", SearchOption.AllDirectories ) )
 {
  var relativeUri = dataPathUri.MakeRelativeUri( new System.Uri( file.FullName ) );
  var relativePath = System.Uri.UnescapeDataString( relativeUri.ToString() );
  AssetDatabase.ImportAsset( relativePath, ImportAssetOptions.ForceUpdate );
 }
}
これでC#で書かれたコードに対しては無事にrspファイルへの変更が反映されるようになります。

しかしながら更に落とし穴があります。UnityScript(JavaScript)で書かれたファイルに対してはこの黒魔術が効きません。したがってUnityScriptで書かれたファイルに対して動的にus.rspファイルの定義を適用することができないようです。すべてのJSファイルに対して上記の黒魔術を適用しても効果がなかったため、おそらくダメだと思われます。


■結論

UnityScriptは使わないようにしましょう。
投稿時間：
タグ： ,

2012年11月11日日曜日

iOS 6.0の advertisingIdentifier と identifierForVendor にはバグがあるので注意

いささかタイミングを逃した感が強いのですが、厄介なバグにぶち当たってしまったので共有いたします。

iOS 6からUDIDに変わる識別子としてUIDeviceのidentifierForVendorとASIdentifierManagerのadvertisingIdentifierが使えるようになったのはすでにみなさんご存知かと思います。ですがどうもこやつらiOS 6.0だと正しく機能しない場合があるようなのです。

詳細は以下のとおり。
http://stackoverflow.com/questions/12605257/the-advertisingidentifier-and-identifierforvendor-return-00000000-0000-0000-000

こちらの情報元によると、iOS 6.0に Over-The-Air アップデート (iTunesを使わないで端末からアップデートする方法) するとこれらの識別子が常に00000000-0000-0000-0000-000000000000を返してしまうらしいのです！iOS 6.0.1では修正されているらしいです。

見事に私の UIApplication-UIID ライブラリもこのバグを踏んづけて大爆発してしまいました。

対処法としては生成されたIDが00000000-0000-0000-0000-000000000000でないか文字列比較する方法がよさそうです。
投稿時間：
タグ： ,

2012年9月26日水曜日

Unity の PostprocessBuildPlayer を使って Weak Framework を追加する方法

※2013/11/27追記: 第二版を公開しました。

UnityでiOSのアプリを作っていて困ることの一つに、iOSが提供するシステムフレームワークへのリンクをプロジェクトに追加するのが超面倒くさいという問題が挙げられます。UnityがiOSアプリを書きだした後、手動でXcode上からシステムフレームワークを追加してもいいのですが、これはとんでもなく面倒です。

そこでUnityジャパンの伊藤さんという方が PostprocessBuildPlayer という仕組みと Ruby の xcodeproj ライブラリを使ってビルド時に自動的にシステムフレームワークを追加する仕組みを公表してくださいました。お陰様で随分とはかどっていたのですが、その方法では実はシステムフレームワークをWeakリンク（Optionalリンク）することができなかったのです。これでは例えばSocial.frameworkを使うアプリをビルドしてiOS5で動かすと起動時に問答無用でクラッシュしてしまいます。困りました。iOS6/5両対応ができないと話になりません。

というわけで作りました。システムフレームワークをWeakリンクできるPostprocessBuildPlayerを。こちらです。


ライセンスはMITライセンスにしておきました。
使い方は大体見ればわかるかと思いますが、まず最初にgem経由でxcodeprojをインストールしておくこと。
sudo gem install xcodeproj
あとは上記のPostprocessBuildPlayerをUnityプロジェクトの /Assets/Editor 以下に配置して、コード中のフレームワーク名を指定している箇所をご自身のお好きなように変更してやればオッケーです。
投稿時間：
タグ： , , , ,

Unity 3.5.5 以下で Game Center / iAd / UIImagePicker などを使用したアプリが iOS 6 でクラッシュする問題

現在 Unity 3.5.5 以下でビルドしたiOSアプリが、以下の条件をすべて満たしているとクラッシュしてしまう問題が発生しているようです。
  • UnityのiOSアプリビルド設定で、画面方向を横向き（Landscape Left/Landscape Right）のいずれかのみに設定している。
  • Pluginなどを経由してGame Centerを使用している。またはiAdやUIImagePickerなどのiOSが提供する特定のView Controllerを使用している。
  • iOS 6を搭載したiPhone/iPod Touch上で動作させる（iPadは大丈夫）。
詳細はこちら。
http://developer.coronalabs.com/forum/2012/09/17/ios-6-orientation-crash





すでにUnity側で問題は把握しているようで、現在修正版の3.5.6を用意してくださっているようなので、続報を待ちましょう。・・・といっても、すでにUnity 3.5.5以下でビルドされたiOSアプリをリリースしていて、しかもAsset Bundleを使用していたりすると、Asset Bundle間の後方互換性問題のためかなり厄介なことになると思われます。最悪過去のバージョンのサポートをすべて切る必要が出てくるかもしれません。


さて、ここからは技術話の余談です。

このクラッシュ問題なのですが、原因はiOS 6で変更になった画面回転（Auto Rotation）APIにあると思われます。iOS 6からはなんとこれまで画面回転に使用されていた
UIViewController shouldAutorotateToInterfaceOrientation:
が完全に廃止になっており、基本的には全く呼び出されないようになってしまっています。その代わりにより体型だった画面回転の仕組みが導入されています。iOS 6からの画面回転は、「アプリが対応する画面方向」と「各View Controllerが対応する画面方向」の２つによって画面の回転する方向が決定されるという仕組みになっています。

ここで、アプリが対応する画面方向は以下のように決定されます。
以下優先順位順に、
1. UIApplicationDelegate application:supportedInterfaceOrientationsForWindow: が返す向き。iOS 6以降のみ。
2. UIApplication supportedInterfaceOrientationsForWindow: が返す向き。iOS 6以降のみ。
3. Info.plist で指定されている UIInterfaceOrientation の向き。
各View Controllerが対応する画面方向は以下のように決定されます。
各ViewControllerが supportedInterfaceOrientations を実装しているなら、それが返す向き。
していないならば、
iPhoneだと UIInterfaceOrientationMaskAllButUpsideDown
iPadだと   UIInterfaceOrientationMaskAll
この２つの積集合をとって、両方が一致した向きに画面回転が行われる仕組みになっています。

では、ここで両者が全く一致しない場合はどうなるでしょう？答えは簡単でクラッシュします。ワオ。素敵。ふざけんなバカApple爆発しろ。

それを踏まえると、今回の問題でクラッシュしてしまう仕組みはこう考えられます。
  1. Unity 3.5.5以下が書き出すiOSアプリは当然ながらiOS 6に完全対応していない。
  2. Game Centerなど、Appleが提供しているUIコンポーネントは全てiOS 6の画面回転に対応しているが、それらのうち幾つかのものはiPhoneだと縦向き画面にしか対応していないものがある（iPadは基本縦横どちらでも表示できるように対応する必要があるとされているため、無事のようです）。
  3. Unityが書きだしたアプリは横向き画面にしか対応していないのに、上記のView Controllerは縦向きにしか対応していないと言い出すので、クラッシュする。
やれやれですね＞＜
ちなみに対応策としては、アプリ自体は縦方向にも横方向にも対応しているというふうにapplication:supportedInterfaceOrientationsForWindow:メソッドを使って値を返すようにした上で、コンテンツを表示するUIViewをUIViewControllerに管理させるようにして、UIViewControllerのsupportedInterfaceOrientationsで横向き画面の値だけを返すようにするといいかんじになると思います。しかしながらiOS 5/6両方で上手く回る画面は結構大変そうです。
投稿時間：
タグ： , , ,

2012年8月19日日曜日

Unity のプラグインで iOS の bundle を使えるようにする方法

OS XやiOSには Bundle という仕組みがありまして、 NSBundle というBundleを扱うためのクラスが用意されています。皆様も一度は
[[NSBundle mainBundle] pathForResource:@"MyMusic" forType:@"mp3"];
みたいなコードを書いたことがあると思います。このBundleの仕組みを使うと、
  • 複数の画像や文言、JSONなどのデータファイル、音楽などを一つにまとめて扱うことができる。個別のファイルとしてプロジェクトに加えなくてよいので利便性が良い。
  • Bundleには最初から多言語化リソースを扱うための仕組みが用意されているため、多言語化が非常に簡単にできる。
  • OS Xだけになりますが、Bundleにはコンパイル済みのコードを含められるので、プラグインの仕組みが簡単にできる。
以上のようなメリットがあります。例えば実例を上げると、Facebook SDKなどがBundleの中に画像や文言などのリソースを格納して配布するようになっています。実際には確認できていないのですが、おそらくmobage, GREEのSDKもそのようになっているのではないでしょうか？ということでSDKなどを配布するときには非常に便利です。

で。このBundleによる配布はなかなか便利なので、UnityのiOSプラグインとして配布するときにも是非使いたいのですが、そのまま/Assets/Plugins/iOS以下にBundleを配置しても正しくBundleが認識されませんし、iOSのアプリにインストールされません。

そこでBundleを配布するときは、/Assets/Plugins/iOS/以下ではなくて、/Assets/StreamingAssets/以下にBundleを配置するようにしましょう。実は/Assets/StreamingAssets/以下のパスには隠し要素があって、このパス以下のファイル・ディレクトリは全てアプリケーション自身の/Data/Raw/ディレクトリに配置されるようになっています。
参考: http://sehm.blog48.fc2.com/blog-entry-159.html

あとはプラグインとして用意したiOSコードの中で以下のようにしてBundleを取得すればOKです。
NSBundle *bundle = [NSBundle bundleWithPath:[[NSBundle mainBundle] pathForResource:@"MyBundle" ofType:@"bundle" inDirectory:@"Data/Raw"]];
これでUnityプラグインを多言語化したり画像リソースを使ったりするのが楽になると思います。

将来的にUnityのバージョンが上がって、/Assets/Plugins/iOS/以下においたBundleも扱えるようにしてくれると楽なんですが・・・Unity 3.5の地点ではどうもダメっぽいです。
投稿時間：
タグ： , ,

2012年7月25日水曜日

LLDB を使って CUI で動作させているテストケースをデバッグする

GHUnit のテストケースを Jenkins で自動的に走らせるために CUI のテストを作っているのですが、 GUI を使ったテストでは問題なく通るのに CUI を使ったテストのときだけテストが落ちるという問題が発生してしまいました。 Xcode 経由の実行であれば Instruments だろうが内臓のデバッガだろうが使い放題なのですが、 CUI となるとそうもいきません。そこで LLDB を直接使って CUI で動作させているテストケースを直接テストしてみることにしました。

参考にしたのはこちら。
http://lldb.llvm.org/tutorial.html

さっそくやってみましょう。lldbコマンドで LLDB の対話環境を起動した後、
process attach --name MyApp --waitfor
でMyApp.appという名前のプロセスが立ち上がるのを監視します。



この状態でMyApp.appというアプリを起動すると、上の画像のようにばっちり LLDB がプロセスを検知して捕まえてくれます。今、MyApp.appはポーズ中になっているので、適当な箇所に
breakpoint -f MyTestModel.m -l 123
とかやって適当にブレークポイントを設置した後、
thread continue
で続きを実行開始します。



ご覧のとおりバッチリブレークポイントで捕まえることに成功です。こちらの図はEXC_BAD_ACCESSが発生した時になんか自動的に止めてくれたときのものです。Xcode経由で起動するときに比べれば不便ですが、何もないよりはだいぶはかどりますよ。
投稿時間：
タグ： ,
登録: 投稿 (Atom)