Hello, Ubuntu Touch

前回のエントリー(リンク)でiOSとAndroidに次ぐ第３極を担うモバイルOSとして、個人的にはUbuntu Touchに期待している旨をお伝えしました。Ubuntu Touchはまだ採用を表明している端末メーカーやキャリアが無く、そういう点ではFirefox OSやTizenからは出遅れている感は否めないですが、逆に完成度の高さはMWCでも評価されてました。

実は友人がNexus7にインストールしたものを私も触らさせていただきましたが、非常にスムーズには動くもののアプリなどの中身はまだほとんどがモックで、商品レベルまでにはまだまだ時間がかかる印象を受けました。

ただ、実機にアプリをインストールすることは可能そうで、Ubuntuからpreview版のSDKもリリースされてますので、今回ちょっとHello worldまで試してみました。

■VirtualBoxにUbuntu12.10をインストール
Macの環境を壊したくなかったので、USBメモリーからUbuntuを起動できるようにいろいろ試してみたのですが、どうしてもできなくて仕方なくVirtualBoxにインストールして実行できるようにしました。インストール方法はここのサイト(リンク)を参考にやりました。

■Ubuntu SDK previewのセットアップ
SDKのセットアップに関しては、公式のサイト(リンク)にやり方が載ってますので、これをそのまま実行すれば良いかと思います。

■サンプルアプリの作成
さていよいよ本題のアプリの作成ですが、これにはQt Creatorという統合開発環境(下図)を使います。ちなみに、Ubuntu SDKがいまはUbuntu用にしか公開されていないので、このような手順を踏んでますが、Qt Creator自体はMac OS X版も存在しますので、Mac用のUbuntu SDKが公開されれば、今回やったようなUbuntu環境のセットアップは不要になるものと思われます。

アプリ作成の手順も公式にあるドキュメント(リンク)を参考にしましたが、基本的にはQtアプリを作るのと相違無いようです。違いはQt用にUbuntu Touchのコンポーネント(Ubuntu.Components)と実機転送のプラグインが用意されているところだけ？なのでしょうかね。

試しに作成したUbuntu Touchアプリのソースコードは以下です。

import QtQuick 2.0
import Ubuntu.Components 0.1
 
MainView {
    objectName: "mainView"
    applicationName: "Hello World"
    id: root
 
    width: units.gu(60)
    height: units.gu(80)
 
    property real margins: units.gu(2)
    property real buttonWidth: units.gu(9)
 
    Label {
       id: title
       ItemStyle.class: "title"
       text: i18n.tr("Hello Ubuntu Touch")
       height: contentHeight + root.margins
       anchors {
           left: parent.left
           right: parent.right
           top: parent.top
           leftMargin: root.margins
           topMargin: root.margins / 2
       }
    }

    MouseArea {
       anchors.fill: parent
       onClicked: {
          Qt.quit();
       }
    }
}

Ubuntu Touchアプリは通常は上記のようなQMLという言語を用いて開発するようなのですが、他のQtアプリと同様にC++を用いて開発することもできるみたいです。QMLは見た通り、ビューとロジックをJavaScriptに似た記法で記述しますが、まだ馴染めなくてもう少し腰を据えていろいろ試す必要がありそうです。

で、実行すると下図のようなウィンドウが表示されました。まぁ、単なるHello worldアプリなので、面白くも何ともないですね。

■所感
歴史と実績のあるQtアプリの開発環境をベースにしているだけあって、特に大きな不具合に遭遇することも無くHello worldまで進めることが出来ました。QMLという言語はちょっと独特で学習コストが気になりますが、Qt自体はMac、Windowsアプリはもちろんのこと、iOSやAndroidアプリも開発できるマルチプラットフォームな開発環境なので、マスターすればもしかしたらいろいろなところで使いでがあるかも知れません。

個人的には、Ubuntu Touchは良くも悪くもUbuntuであるところに魅力を感じております。PC用のOSをモバイルに使うので、確かに消費電力は気になりますがスマートフォンやタブレットのハードウェアスペックもどんどんあがってますので、そのうち問題にならなくなることを期待してます。

あと、昔から外出している時は携帯の形で使えて、家に戻ったらディスプレイにつなげてPC的に使える携帯があればいいなと思っていたのですが、Ubuntu Touchだとまさにそのように使えるんですよね(下図)。

Androidでも確かにテレビなどの大画面なモニターにつないで使うことは可能なのですが、基本Androidなんですよね。PCの形態で使う時は、やはりLinuxの膨大な開発ツールを使いたいじゃないですか？まぁ、Ubuntu for Androidを使えばいいのかも知れませんが、そこは携帯とPCでシームレスに使えるUbuntuにアドバンテージがあるかな？と。

そんなわけで個人的にはUbuntu Touchに期待してますけど、iOSやAndroidの存在を脅かすのはUbuntu Touchでも、ましてやFirefox OSやTizenでも無く、きっとKindle何だろうと自分は思いますけどねw

Hello, Firefox OS

先週までバルセロナでMWCが開催されてて、今年はiOSとAndroidに次ぐ第３極を担うモバイルOSとして、TizenやFirefox OSに大きく注目が集まりました(Windows Phoneェ...)。

個人的には、iOSやAndroidの牙城を崩すのはかなり厳しいように思い、これまであまり興味が沸かなかったのですが、いろいろニュースになっていることや、Firefoxにプラグインで簡単にFirefox OSのシミュレータをインストールして試せることがわかりましたので、ここのサイトを参考にちょっと試してみました。

アプリケーションを長い時間かけてビルドして作成する従来の方法とは違い、HTML5などのWeb技術でチャカチャカとソースコードを記述してすぐにアプリをデプロイできるこのお手軽さは結構アリでは無いか？と思いました。

そういう意味ではTizenとFirefox OSではHTML5アプリオンリーというFirefox OSの潔さにいまのところは好感を持っております。

Tizenでネイティブアプリをわざわざ作るくらいなら、自分はAndroidでいいですね。Tizenをそこまでして使うメリットを感じません。

ただ、HTML5アプリでは重い処理がおぼつかないというケースも考えられるので、いざとなればNaclでネイティブに処理を逃せるMobile Chrome OSが”もし”あれば、本当なら自分はそっちの方がいいかなぁ？とは思いました。普段のブラウザもChromeを使っているしね。

でもまぁ基本的にアプリロジックで重たい処理はクラウド上のサービスに逃がして何とかするってモデルなんだろうな、とは思います。

ってことで、Firefox OSは想像していたよりも使えそうな印象を受けたのは確かですが、ではAndroidから乗り換えてまで使いたいか？と言われると、そこまででも無いですね。

個人的にAndroidの自由(いい加減)なところとアプリ連携の仕組みはかなり気に入っていますし、何よりbackキーはやはり偉大な発明だったのではないかと思ってます。これがあるからなかなか他のプラットフォームに移るのは今後も難しいような気がしてます。いや、マジで。

それでも、何か他のOSに浮気をするとすれば自分はUbuntu Touchかなぁ？と思います。モバイル用のOSでアプリケーションを真のマルチタスクで動かせるのはいまのところUbuntu Touchだけですよね？だって、中身はUbuntuそのまんまでGUIがTouchデバイス対応にしたもののようなので(詳細をきちんと理解しているわけでは無いので、ウソ書いてるかも？)。

だからきっと電池の消費とかは激しいのでしょうけど、解像度が上がって画面の広くなってきてるタブレット端末なんかは電池容量にも余裕があるし、かなり相性がいいのでは無いかと想像してます。

Tizenはドコモが今年対応端末をリリースすると言ってますし、Firefox OSの端末はauが2014年にリリースを目指しているようなので、Ubuntu TouchやWindows Phone、Blackberryを含め、どのモバイルOSが今後第３極として台頭してくるのか楽しみですね。

xib2js & TiMockをリリースしました

frogonmobileのサイトにxib2jsの新版とTiMockをリリースしましたので、ご案内すると同時に簡単なQuick startガイドをここに記したいと思います。

基本的に、frogonmobileのサイトで公開している英語版のQuick Start Guideの和訳＋αみたいな感じにしたいと思います。

ここのサイトに来ていただいている方ならばxib2jsに関してはもうご存知だと思われますが、前回のエントリーで述べた通り今回はこれのバージョンアップと共にTiMockというTitanium Mobileアプリを併用することで、モックアップを簡単に作成し実機で確認できる環境を構築することができるようになったのが大きな売りとなっております。

ワークフロー的には、下図のようにXcodeでUIのコンポーネントを並べて.xibファイルを作成し、それをxib2jsでJavaScriptに変換した後にTiMockを使って実機やシミュレータ上で確認しながらコンポーネントの位置や大きななどをコードを改変して微調整するという感じになります。

1. XcodeでUIを作成
XcodeでFileメニューからNew Fileを選択し、iOSのUser Interfaceのテンプレートを選択します(ここではEmptyを選択してます)。

後は、コンポーネントを並べてUIを構築していけば良いのですが、ここでの注意点としましては、ファイルの形式を"Interface Builder3.1"を選択しておくことです。それ以外のバージョンではxib2jsが正常にコードを生成できないことを確認してます。

2. xib2jsで.xibファイルをJavaScriptに変換
UIが出来たら、毎度お馴染み.xibファイルをxib2jsにドラッグ＆ドロップすると、いつもの通りにJavaScriptのコードが生成されます。

今回のバージョンから生成されるJavaScriptがCommonJSのスタイルに則っていることが確認できると思います。

3. TiMockと連携してUIのカット＆トライを行う
さて、ここからが今回の売りであります、TiMockを併用したUIのカット＆トライです。まず、TiMockを実機かシミュレータで起動できるようにまずはビルドから始めます。

Githubからコードをダウンロードしたら、Titanium Studioで適当な新規モバイルプロジェクトを作って(Titanium Mobile SDKは2.0を選択する)コードや画像ファイル等をコピーし、ビルドします。

特に難しい部分は無いと思いますが、実機用にビルドする時にはui/ApplicationWindow.jsファイルの３１行目のコードのコメントを外してください。

//require("api/Includes");

シミュレータで実行する場合は、そのままビルドして問題ありません。

ビルドが完了しましたら、TiMockを起動してください。TiMockは起動するとBonjourで_timock._tcpサービスをサーチします。xib2jsが起動していれば、xib2jsがこのサービスを提供しますので、TiMockアプリ上に"TiMock Service"というボタンが見えていると思います。

このボタンをタップすると、xib2jsとTiMockの通信が確立されます。xib2js上のSyncボタンが有効になるのと、TiMock上のボタンもConnectedとなったことが確認できると思います。

試しに、この状態でSyncボタンをクリックすると、変換されたJavaScriptのコードがTiMock側に転送されて、UIを実機上で確認できます。

後はxib2js上で微妙なレイアウトの崩れなどを、コード上でコンポーネントの位置やサイズのプロパティ値を調整しながらカット＆トライしてUIのモックを仕上げていきます。コードを編集したら、都度Syncボタンをクリックすることで実機上で修正内容が反映され確認できます。

尚、コードの編集に関しては、TiMock上で正常に動作させるには、かなり制約されたものになります。

まず、関数とexportsの定義は変更できません。また、self変数に何らかのUIコンポーネントのインスタンスを格納し、それを返り値として返す形を取る必要があります。

function ApplicationWindow() {             // この行は編集してはダメ
  var self = Ti.UI.createWindow();           // self変数にインスタンス化した
                                                              // UIを格納する
  // ここの中はわりと自由に書ける

  return self;                                          // 必ずselfを返すようにする
}                                                           // この行は編集してはダメ
module.exports = ApplicationWindow; // この行は編集してはダメ

このルールを守れば、逆に関数の中身に関してはわりと自由に書けますが、あくまでも目的はUIのモック作成なので、あまり本格的なアプリケーションロジックをここでコーディングすることはお薦めできません。

とは言え、どんなコードなら動くのかはある程度試行錯誤が必要だと思いますので、いろいろ試してみて自分なりの答えをみつけてください。

また、xib2jsは拡張子が.xib以外のファイルを受け取った場合は、そのファイルをTiMockに転送します。TiMock側は受け取ったファイルをTi.Filesystem.applicationDataDirectoryに保存しますので、コード上でパスを適切に設定することで、画像をUIにはめ込むことが可能です。

ここで指定するパスは、実際のアプリを作成する際にリソースが置かれる位置とは違うものと思われますが、画像がどのような位置・サイズで表示されるのかを確認するには便利に使えるのでは無いかと思います。

また、xib2jsにはファイルをまとめて複数ドラッグ＆ドロップしても、同時には１つのファイルしか処理できませんので、お手数でも１つずつドラッグ＆ドロップしてください。

4. コードの保存
さて、最後にここまで調整してきたモックのコードを保存します。Saveボタンをクリックするとファイルの保存先を選択するダイアログが表示されますので、Titianium Studio上の適切なプロジェクトのResourceフォルダーを選択してください。

尚、いつもの注意点ですが、保存の際にxib2jsはファイルの存在の有無を確認しませんので誤ってファイルを上書きしないようにお気をつけください。これ、いい加減にちゃんと対応しないといけませんね。。

ここまで来たら、後はTitanium Studioに引き継いでアプリケーションの開発を継続しましょう。

Code Strong,

xib2js 2.0 preview

久々の更新ですね(^_^;

Titanium Mobile 2.0 ローンチ記念イベント in Tokyo!!が開催されましたので、参加してきました。イベントの詳細レポートはTitanium Newsをどうぞご参照ください。

イベントの中でLTの枠がありましたので、長らく放置してましたxib2jsの新しいバージョンを発表させていただきました。ちなみに、デモがメインだったのでスライドの公開予定は特にありません。

xib2jsで生成するJavascriptは当時のKitchenSinkを参考にしましたので、現在は推奨されていない所謂マルチコンテキストと呼ばれていたスタイルのコードを生成していましたが、今回のバージョンアップで、CommonJSスタイルのコードを生成するように変更しました。

まぁそれだけでは面白くないので、TiShadowを真似て変換したJavascriptを実機やシミュレーターに転送して実行できる機能を組み入れました。

TiShadowでは、HTTPのサーバーと接続するのにIPアドレスをいちいち打ち込む必要がありますが、xib2jsはMac + iOSでの利用を前提にしているので(なぜならXcodeで作成した画面レイアウトをJavascriptに変換するツールなので)、簡単に接続できるようにBonjourを使うようにしました。

後は、画面のレイアウトを作った後に画像データを貼り込むケースを想定して、.xibファイル以外をドロップした時は、端末のアプリケーションデータディレクトリーにファイルを転送して保存する機能も追加しました。

実際のアプリを作成する時は、違うディレクトリーにアセットやリソースを置かれるとは思いますが、実機上で画像の位置やサイズとかを簡単に確認・調整するには便利に使えるかなと思ってます。

正式に公開するまでには、まだじゃっかんコード整理以外にもやることがありますので、もうしばらくご辛抱くださいまし。

Code Strong,

Thoughts on Flash vs HTML5

世の中、何事も対立軸で見た方がわかりやすいし、面白いですよね。最近度々起こるFlash vs HTML5論争もそんな感じなのですが、この論争のきっかけ(のひとつ)を作った敬愛するSteve JobsがAppleのCEOの座を辞職することになったので、これを機会に彼のThought on Flashを真似て、Thoughts on Flash vs HTML5として、自分の考えをまとめてみました。

■FlashとHTML5はそもそも競合する技術なのか？
一部のHTML5支持層はHTML5によって今後Flashは不要になると言う。Flashの多くの支持層は、FlashとHTML5はお互いを排他する存在ではなくて、両方をうまく使ってよりよいものを作って行ければ良いと言う。双方にそれぞれの言い分があるようだ。

じゃー、私はどう思っているのか？と言いますと、私はFlashとHTML5は基本的に競合する技術だと思う。確かに両方をうまく組み合わせて使うことを否定はしないけど、HTML5がFlashのポジションを狙っているのは明らかじゃない？

いまはまだリトルリーグと大リーグくらいの力の差はあるのかも知れないけど、HTML5少年もいつかは大リーガーになることを夢見てこれからも練習に励んでいくんだろう。Flashはその頃には更に先に進んでいるんだろうけど、HTML5で多くの人が必要十分だと思う機能はいずれ実現されると思う。

但し、用語に混乱があるような気がする。HTML5と言っても何がHTML5なのか私にはよくわからない。なので、この手の話はFlash vs その他のWeb技術と捉えるようにしている。もっとぶっちゃけると、Flashを無くしたいと思っている人達と、無くしたく無いと思っている人達の論争なんだろうな、と。

■何でそんなにFlashを無くしたいの？
Flashを無くしたい人達は何でそこまでFlashを嫌うんだろうか？幾つかケースを考えてみた。

1) iOSで見れないから
これはわかる。これは他に選択肢が無いもんね。でも、みんながみんなiOSを使っているわけじゃないんだし、実はFlashを見られない人よりもHTML5を見られない人の方が多いらしいよ？いまんとこね。

2) オープンソースじゃないから
Flash Playerがオープンソースじゃないというのは、いまの時代には嫌うに充分な理由になると思う。自分は、Adobeもそのことは充分承知しているが、オープンにすることで互換性の無いPlayerが広まることを恐れているのでは無いかと勝手に想像している。

だから、Adobeはオープンにしない代わりにみんなの為にいろんなプラットフォームやブラウザ間での互換性を保つ為に血の滲むような多大な努力を払っているんだなと思うようにしている。

まぁ、オープンにしてほしいけどね。

3) プラグインを入れるのが嫌だから
自分もプラグインを入れると何となく不安定になるんじゃないかというイメージは持っているので、なるべくプラグインは入れたく無いという気持ちはよくわかりますし、実際、必要だと思う最低限のものしか入れないようにしてます。でも、常用のブラウザ(Chrome)にはデフォルトでFlash Playerのプラグインが入るようになったんですよ・・・

4) 過去に何か嫌な思いをしたから
過去に糞重いFlashサイトを開いてしまって、すごく迷惑だった？あるいはいきなり大音量が出て恥ずかしい思いをしたとか？何でもそうですけど、一度失った信用を取り戻すというのは大変なことですよね。これに関しては、私から言えることは何もありません。

ただ、Flashが流行り始めたあの頃と違って、いまはそんなにひどいサイトはあまり見かけないと思うんですけどねー。

5) ちょっとした出来心
HTML5によって以前よりもインタラクティブなサイトがFlashを使わなくても作れるようになったというのは歴然たる事実だと思う。だから、Flashイラネとか言ってみたらちょっと受けるかな？とか、ちょっとした出来心で言ってしまったってのが本当のところじゃないのかな？

■FlasherはFlashが無くなったら困るの？
じゃー仮にFlashの無い世界がやって来たとして、Flasherは困るのだろうか？実はそんなに困らないんじゃないのかなぁ？と思ってます。むしろFlashを毛嫌いして、インタラクティブなUIやコンテンツをあまり作ってこなかった人達の方が、HTML5の時代になって、そういうコンテンツを求められた時に困るのでは無かろうか？

AdobeもHTML5対応のツールを今後積極的に出していくと思うし、Edgeを見てみても、それは現在のFlash IDEの使い勝手をある程度踏襲したものになるだろう。であれば、極論すれば、Flasherに取っては出力フォーマットがFlashかHTML5の違いでしか無いのだ。

だからHTML5の時代が来ても、インタラクティブなUIや演出に長けたFlasherの仕事は減ることは無く、むしろ増える方向に行くのでは無いだろうか？HTML5にはまた違ったKnowHowが当然求められるだろうが、Flashで一回乗り越えた人達の方が、いろいろと鼻は効くような気がする。

それに、最終的にAdobeはFlash IDEでFlashコンテンツを作っても、プラグインが無いとHTML5にフォールバックするようなコンテンツを作れるようにするでしょ？それは絶対間違いないでしょ？だからHTML5派の人もFlashを使えるようになってても損はしないと思うけどな。

■まとめ
個人的にはHTML5がFlashを駆逐すると言うにはまだまだ時期尚早だと思うし、現実解としてのFlashは今後もしばらく、というかずっと使われることになると思う。だからと言って安泰というわけでも無く、ある領域に置いてはHTML5にその座を譲ることになるのであろう。

だけど、そんなことはどうでもいいことじゃないだろうか？正直、HTML5とFlashのどちらが明日生き残ろうが、大した問題では無い。そんなことより、大好きなあの子に今日フラれるかも知れないことの方がよっぽど重要な問題だよね。

Titanium Meetup Tokyo #5 参加

6/21に開催されたTitanium Meetup Tokyo #5に参加してきました。

基本的に、各々がモクモクとコーディングをする(だけの)会なのですが、@masuidriveさんを捕まえてTitaniumの深いところまで質問できるのが、個人的には魅力的だと思いました。

ちょうどいま、Titaniumを使って初めて本格的なアプリを作ってて、幾つか質問したいことも溜まってたし、今回は開催地がオフィスの近くということもあって、いろいろ好都合でした。

ってことで、恥を忍んで、質問したことをここに晒そうと思います。

1. Toolbarのあるウィンドウから無いウィンドウに遷移すると黒背景が見える
app.jsでbackgroundColorを黒に設定してました・・・orz お恥ずかしい

2. 階層の深いウィンドウから元のウィンドウに一気に戻る
下図のように、どんどん階層の深いウィンドウに潜って行って、一気に一番はじめのウィンドウに戻りたい時ってありますよね？でも、どうやればいいんでしょう？

これは、増井さんも良いやり方がわからないとのことでした。でも、必要性はわかっていただけたと思うので、そのうちFrameworkでサポートされるかも知れませんね？こういったリクエストを直接なかの人に伝えられるというのも、こういう会合に参加するメリットだと自分は思いますよ。

で、自分は、一番はじめのウィンドウにカスタムイベントを飛ばして、そのハンドラーの中で直下の子ウィンドウをクローズすることで、ムリヤリ実現していたのですが、増井さんもいまはそれしかなかろうということでした。

まぁ、これでやってやれないことは無いのですが、やってみるとわかりますが、元に戻るのに結構時間がかかります。一瞬ハングったかと思うくらい・・・多分、内部ではいろいろ後始末に追われているんでしょうね(汗

3. アプリケーションがバックグラウンドに回った/戻った時のイベント
アプリケーションが動作中に電話がかかってきたなどで、バックグラウンドに回ることがあるじゃないですか？あるいは、ユーザーがホームボタンを押したとか。そういう時、あるいは逆にバックグラウンドからまた復帰した時のイベントは無いのか？ということを最後にお尋ねしました。

これに関しては、ドキュメント化されていないけど、Ti.App.addEventListener()で以下のイベント設定すれば取れるということでした。

pause	アプリがバックグラウンドに回った
resume	アプリがバックグラウンドから復帰

流石にこれは、ドキュメントに書いておかなアカンやろ(笑

Code strong,

Xib2JsでTitaniumアプリ作成入門

前回のエントリーで、Titaniumでアプリ開発をする際の面倒な点として、GUIのRADツールがまだ無いので、拙作のxib2jsというツールを紹介させていただきました。

今回は、もう一歩進んで、xib2jsで具体的にアプリを作成する手順をご紹介させていただこうかと思います。

１. Titaniumアプリの新規プロジェクトを作成
まず、Titanium Developerで新規プロジェクトを作成してください。

２. アプリケーションの画面を設計
次にInterfaceBuilderでアプリの画面を作成します。InterfaceBuilderを立ち上げてiPhoneアプリの作成を選択します(iPadアプリの場合はiPadを選んでください)。

次にTab Bar Controllerを画面構成ウィンドウにドラッグ＆ドロップして作成します。

新規作成したTab Bar Controllerにインスペクターウィンドウから名称を設定します。名前は何でも構いませんが、スペース等を入れると後のJavaScriptのコンパイルでエラーが出ますので、ご注意ください。

 それぞれのTabにUIViewを配置しまして、以降は通常のやり方でUIComponentを画面上にドラッグ＆ドロップで並べて行きます。

今回は、あまり見栄えはしませんが、Titanium Developerで作成されるデフォルトのアプリケーションと同じようなものにしてみましたが、適宜、いろんなUIComponentを使って画面を作成してみてください。ひと通りのもの使えるようにしてあるつもりです。

使用するUIComponentに名称が設定されてあると、後にxib2jsがJavaScriptのコードに変換する際に、その名称を使用しますので、適宜名称を設定しておきます。名称が未設定の場合はxib2jsの方で、コンポーネントの種類と通し番号で適当な名称に変換します。

[注意]

xib2jsはTab Bar Itemに設定されているラベルの名称でTitanium.UI.Tabを作成するコードを生成します。InterfaceBuilderはデフォルトで"Item 1"のようにスペースの入ったラベルを作成するので、このままでは後ほど生成されたJavaScriptをコンパイルする際に、エラーとなってしまいます。これを避ける為、ここではラベルを"Item1"のようにスペースを削除してます。

画面設計をひと通り終えたら、ファイルを保存しておきます。

３. JavaScriptコードへの変換

InterfaceBuilderで作成したファイルをJavaScriptへ変換するのにxib2jsを使用します。ここから(link)アプリをダウンロードしてください。zipで圧縮してあるので解凍してできた.airファイルをダブルクリックしてインストールします。

xib2jsアプリが起動したら、先程InterfaceBuilderで作成した.xibファイルをアプリにドラッグ＆ドロップすると、JavaScriptに変換されます。

画面左上の[Save]ボタンを押して、変換されたコードを保管するディレクトリーを選択します。ここでは、最初に作成したTitianiumアプリのResourceフォルダー以下を指定します。

[注意]

xib2jsはファイルを保存する際に、同名のファイルが存在しても無断で上書きしますので、必要なファイルを誤って上書きしないようにご注意ください

また、xib2js上で作成されたコードは選択してコピー出来ますので、必要な部分のみを選択して、自分のコードにペーストして使用するという方法もあるかと思います。

４.コンパイル＆実行

作成されたコードをTitanium Developer上のRun EmulatorでiOSシミュレータを起動します。JavaScriptのコンパイルに成功すると、シミュレータが立ち上がって先程作成した画面がアプリに反映されていることが確認できると思います。

ここで、Tabの順序がInterfaceBuilderとは逆になっているのは、ご愛嬌(笑)。JavaScriptを編集して、Tabの設定順序を変更してください。

このようにxib2jsは、まだInterfaceBuilderで作成した画面を100%完璧に再現するJavaScriptのコードに変換できるわけではありませんので、変換に失敗した場合は寛大な気持ちでコードを適宜修正して使用してくださいまし。

Code Strong,

MogSnap

iPhoneユーザーの皆様、是非MogSnapという無料アプリをAppStoreからダウンロードして触ってみてください。

これ、最近注目度の上がってきているTitanium Mobileという開発環境を使って作られているのですが、恐らく言わなければネイティブのObjective-Cで作られたアプリだと思われることでしょう。それくらい素晴らしい出来なんです。

自分は少し前からTitaniumを触ってますが、AIRなどと比べてUIはネイティブのCocoa Touchを使いますので、他のアプリとのルックアンドフィールの統一感や、何よりパフォーマンスの面で有利です。

Packager for iPhoneは、現状自分の持っているiPhone 3Gでは使い物にならないくらいの速度しか出ないのに比べて、上述のMogSnapなんかもボタンの表示が(いま現在は)おかしくなるようですが、何とか動かせられます。

まぁ、AIRにはAIRの良い面もあって、例えば、Particle BreakやRealCircleのようなゲームをTitaniumで作るのは、逆にちょっと難しいような気もします。

ただ、Titaniumの場合は、Titaniumが提供する環境で解決できない問題が発生した場合は、ネイティブコードで作成したモジュールを呼び出すという技が使えるので、(もちろんそれ用に別途用意する必要があるので)労力を別にすれば、作れないアプリなど無いのかも知れませんが。

とまぁ、ここまで読んで試しにTitaniumを触ってみようと思われた方、Titaniumの現在の泣き所は、開発ツールがまだ充実していない点です。アプリは基本的にJavaScriptで記述するのですが、GUIのRADツールが現状用意されていないので、いまどきGUIをコードで記述して構築しないと行けません(FlexでいうところのMXMLのような仕組みも無い)。

なので、そこんところが面倒だという方は、拙作のxib2jsというアプリを試してみてください。これは、Interface Builderで設計したUIデータをTitanium Mobile用のJavascriptコードに変換するAIRアプリです(変換精度は要改善)。

そう、AIRはこういうちょっとしたツールを作るのにも便利ですよね。

Titaniumに関する情報は以下のblogに詳しくまとめられておりますので、ご参考にしてくださいまし。

http://d.hatena.ne.jp/donayama/

とにかく、いま日本のTitanium開発者の間ではMogSnapに追いつけ追い越せって感じで盛り上がっていますので、今後も面白いアプリで出てくると良いなぁと思ってます。

Code Strong,