Evernote Hackathon in Tokyo を開催します (1/25 19:00 - 1/27 14:00)というblog記事を見かけ、半ばダメもとで応募したら当選してたので参加してきました。
Evernote APIについては、Evernote APIを使ったAndroidアプリを作る(1) な記事を書いたりと以前から興味を持っていて、昨年のEvernote Devcupへの参加もかなり本気で準備していたのですが形に出来ず 悔しさが残っていました。
組んだチームの話や開発したものの話は改めて書くことにして、今回は自分では初めて開発に使ったTitanium Mobileについての所感的なものを軽く書いてみます。
今回のハッカソンでTitanium Mobileを使った理由は、
- iOSネイティブアプリを作りたかった
- UIデザインと開発を切り分けて並行作業したかった
- チームメイトが、これを使ってアプリを開発した経験を持っていた
- 万能薬というよりは、最低限のものを共通コード基盤で複数プラットフォームに向けて作るためのものという認識だったけど、実際に使ったことは無かったので使ってみたかった
- JSなので、辛くてもまあ最終的にはなんとかなるだろうと考えた
というあたりです。
Titanium Mobile、JSでネイティブUI要素を書いていくことが出来る点はとても良いです。UI設計/組み込みと開発の作業分担についても、JSベースなので従来から慣れていれば新しいことを覚える必要がない点はとても良いです。しかし、最新版(3.0.0)のTitanium Studio(とそのツールチェーン)は厄介な問題を抱えてます。以下は、iOS実機(iPod touch 5th gen)用にプロジェクトをビルドした際に生成されるApplicationRouting.mというファイルの一部です。どうもJSとPNG等のアセットをまとめて突っ込んである領域のようです。
-- お分かり頂けただろうか?拡大してもう一枚。
つまりJS系での実行用データをObjective-Cのソースファイル内にパックして詰め込んでる箇所なのだけど、途中で生成を諦めてます。これはどう頑張ってもビルド出来るはずがない。
これをなんとか解消しないと実機テスト出来ない(Xcode用のプロジェクトファイルは生成されるけど、これはTitanium Studioから生成されたコードのビルドをするだけ)わけで、少し調べてみました。けれど再現方法を絞り込んでいる最中に 同Mac上・同コードで挙動が変わったのを見て心折れました。 iOS: Build - Titanium mobile project fails to build intermittently というタイトルで既に登録されていたものの再現性イマイチで問題としてはスルーされる方向にある感。
実際、Titanium Studioからのシミュレータ実行(ベストケースで15秒、中央値で30秒ぐらい)、実機実行共にファイルとしての保存タイミングとビルド&シミュレータへ投入した際のファイル版がイマイチ一致していない気もするし、まだまだだなーという印象でした。Eclipseベースなのでプラグインそのまま使えて、Vrapperとか投入出来るのは良いのだけどね。
Titanium Mobileを触ってアプリをひとつ開発した結果、Objective-C/Cocoa Touchの良さを再認識出来た気がするので取り急ぎObjective-Cの勉強に戻ります。
