T

Titanium + VMware(Android x86)でAndroidアプリ開発

そう、さっきのエントリを読んでお気づきの方もいらっしゃるでしょうが、実はほぼ同じやり方でVMware上のAndroid x86を動作させることも可能です。インストールについてはこちらの記事なんかが参考になるでしょうか。ネットワークの設定はブリッジで追加のデバイスとすれば

$ adb connect 192.168.1.5 #VMware上のAndroidのIPアドレス(例)
$ adb devices
List of devices attached 
emulator-5554	device
192.168.1.5:5555	device

こんな感じで認識します。CLIからのビルドとインストールはこんな感じ(デバイスの指定は例です):

titanium build --platform=android --build-only && \
adb -s 192.168.1.5:5555 install -r build/android/bin/app.apk

androx86

こっちはActionBarに対応していましたね。

もちろん、Androidのエミュレータでx86のイメージを使ってもいいんですが、あれっていまいち不安定でちゃんと動かなかったりすることが多くないですか?原因の切り分けが難しい割に再現する頻度は高いので、最近ちょっとくじけています。

Titanium + BlueStacksでAndroid開発

Androidのエミュレータの動作の遅さには困ったものがあります。ホストと異なるアーキテクシャのマシンをエミュレートするのですから遅いのは当然のことではありますが、開発の意欲を削ぐほどのノロさなので、いくらなんでも限界というものがあります。そういう場合、普通は(1)諦める(2)報復を仄めかす(3)工夫するといった選択肢が考えられますが、われわれ歌と踊りが大好きな愉快で楽しいTitaniumユーザーとしては、3の路線でいきたいものです。

というわけで、先日発表されて話題になった、WindowsやMac OS上でAndroidのアプリが実行できる環境を提供するBlueStacksを使ってみました。BlueStacksのインストールは簡単で、Mac OS Xならダウンロードしたファイルを展開してコピーするだけです。さっそく起動してみましょう。

bs

なんかそれっぽい画面が出てきましたね。さっそくゲームとかいろいろやってみたいところですが、いったん我慢して、Titaniumで作成したAndroidアプリをインストールできるようにします。ターミナルからadbをリロードしてみましょう。

$ adb kill-server
$ adb start-server

おそらくこれだけでBlueStacksがエミュレータとして認識されるはずです。されていなければ、ここだけの話ですが、localhostの10000とか10001とか10002、あるいは5550から順番にconnectを試したら繋がります。

$ adb connect localhost:1000x
$ adb connect localhost:555x

ひどい話ですね。

$ adb devices
List of devices attached 
emulator-5554	device

こんな風に表示されたらしめたものです。あとはTitaniumがエミュレータとして認識してくれれば楽なのですが、面倒くさい+CLIしか使わないので「build-onlyでapkファイルだけ作成」したら「adbでインストール」という手順でやってしまうことにしました。プロジェクトのディレクトリから

$ titanium build --platform=android --build-only && \
adb -s emulator-5554 install -r build/android/bin/app.apk

これで、apkファイルを作成し、インストールするはずです。さっそく実行します。ところが…

なぜだ…

なぜだ…

あれーっ!エラーがいっぱい!そう、実は3.0.2.GA時点でAndroidはbuild-onlyオプションが正しく動作しないのです。仕方がないので対応させてみましょう。$HOME/Library/Application\ Support/Titanium/mobilesdk/osx/3.0.2.GA/android/cli/commands/_build.jsを編集します。

$ diff /tmp/_build.js /tmp/_build_old.js 
404,405d403
<       } else if (cli.argv['build-only']){
<         return;

うーん、問題なければPull Requestしようかな。これでbuild-onlyを無視しなくなります。もう一度さっきのコマンドを実行してみます。

$ titanium build --platform=android --build-only && \
adb -s emulator-5554 install -r build/android/bin/app.apk

BlueStacksには普通のAndroidデバイスにあるようなアプリ一覧みたいなメニューがないので、ホーム画面左側の大きな「My Apps」ボタンをクリックします。

bs2

インストールされていましたね(画像のActionBar2っていうのがそうです。ええ、ついうっかりFruit Ninja Freeも入れましたとも)。ActionBarの動作を試したかったのですが、どうやら対応していないみたい。

bs3

TCAD Certification Trainingの閲覧方法

Titanium Mobileのセミナーで「TCAD Certification Trainingの閲覧方法がわからない」と質問を受けたので、まとめておきます。確かにどこにも解説がありませんね。

A gitをインストール済みの場合

手順1:プレゼンテーションエンジンを用意

$ mkdir tcad && cd tcad
$ git clone git://github.com/appcelerator-training/presentation-engine.git

手順2:TCAD Certification Trainingを準備

$ git clone git://github.com/appcelerator-training/tcad_certification.git

手順3:なし

もうおしまいです。tcad_certificationディレクトリのindex.htmlを開きます。

B gitをインストールしていない場合

口に出すのもはばかられるような悲しい理由でgitをインストールしていない方も、まあ閲覧するくらいならできます。

手順1:ダウンロード

TCAD Certification Trainingのページの上の方にある「ZIP」ボタンをクリックしてファイルをダウンロードします。

手順2:名前の変更

ダウンロードしたファイルを展開して、一番上のディレクトリ(フォルダ)をtcad_certificationという名前に変更します。

手順3:またダウンロード

presentation-engineのページから先ほど同じく「ZIP」ボタンを見つけてダウンロードします。

手順4:また名前の変更

ダウンロードしたファイルを展開して、一番上のディレクトリ(フォルダ)を今度はpresentation-engineに変更します。

手順5:ありません

tcad_certificationディレクトリ(フォルダ)のindex.htmlをお好きなブラウザで開きます。Safari、Chrome、Firefoxで動くそうです。ただしZIP派にもいいことはあって、gitだとcloneするのに結構時間がかかります。回線が栄養失調みたいに細い方はどうぞ。

TiAudioRecorder

Titanium MobileにはAndroid用の録音機能が実装されていないので、Twitter上で誘われたこともあって空き時間にちょちょいと作ってみました。Java初心者が引き続きなんかやってるとゆるくご笑覧ください。

TiAudioRecorder

最低限の機能しかありませんが、とりあえず録音は出来ています。ファイルは好きなところに設置できますが、フォーマットは3gpで保存します。ただ、最近のモジュール作成方法を追いかけていなかったのであんまり感じのよろしくないAPIになっています。まあ、AndroidのMediaRecorderを使用する限りはメソッドの呼び出し順が決まっているのでそこら辺の制約はJavaと一緒だからいいかと無視しています。

そうそう、Ti.Filesystem.applicationDataDirectoryに保存した音声ファイルはなぜかTi.Media.createSoundで開いて再生することができませんので、録音したデータを再生する際はご注意ください。

使い方は下の通りです:

var audio_file = Ti.Filesystem.getFile(Ti.Filesystem.externalStorageDirectory + 'test.3gp');
var tiaudiorecorder = require('org.selfkleptomaniac.ti.mod.tiaudiorecorder');
tiaudiorecorder.setPath(audio_file.nativePath);
tiaudiorecorder.prepare();

モジュールをrequireしたら、まず録音データを保存するファイルをnativePathを使ってフルパスで渡してください。それからprepareを実行すれば録音の準備が完了します。prepareを実行すると非同期でinitializedイベントが発生するので、録音を開始するときにはaddEventListenerでこのイベントをキャッチすることができます。

tiaudiorecorder.addEventListener('initialized', function(e){
  var dialog = Ti.UI.createAlertDialog({title:'Audio Recorder', message:'OK, we are ready.', buttonNames:['Start', 'Cancel']});
  dialog.addEventListener('click', function(e){
    if(e.index == 0){
      tiaudiorecorder.start();
    }else{
      tiaudiorecorder.reset();
    }
    return;
  });
  dialog.show();
  win.add(dialog);
});

イベントは他に録音開始したとき(start)、停止したとき(complete)、エラーが発生したとき(error)にfireEvnetで発火しますので、それぞれにlistenerを用意するといいでしょう。詳しくはexample/app.jsをご覧ください。

ただ、録音開始になっても冒頭が切れたりすることがあるので、Androidってそういうものだと思って工夫してください。

それから、最大録音可能時間やファイルサイズでキャップしたりそこに到達したときにcallbackを実行させたりすることも可能らしいので、時間ができたらやっておきます。またpauseも追加してみたのですが、うまく動くかよくわかりませんでした。そもそもAndroidのMediaRecorderにはpauseというメソッドはありません。

どうしてTitanium Mobileなの?

ウェブ開発者がiOSやAndroid向けアプリを作ろうと思い立った場合、今なら大きく分けて2つの選択肢があります。ひとつは他の人たちと同じようにObjective-CやJavaで素直にアプリを作ることです。まあ、当たり前ですね。もうひとつの方は、PhoneGapTitanium Mobileのようなサードパーティーのツールを利用してJavascriptなどウェブ開発者の慣れ親しんだ言語で開発するやり方です。それぞれ一長一短があります。先のやり方では、ネイティブな開発用言語だけあって全ての機能を最大限に活かすことができます。AppleやGoogleも最大限の開発支援を提供してくれることでしょう。しかし、Objective-CやJavaに慣れ親しんでいた人でなければ学習曲線がなかなか上昇してくれないかもしれません。特にウェブ開発者はWebObjectsをやっていた人でもない限りはObjective-Cに馴染みの無い人が多いでしょう。また、ヘッダファイルを書くことやDelegateみたいなまだるっこしいデザインに疲れてしまうかもしれません。そんな場合、サードパーティーのツールで素早く開発しながら徐々に慣れていく方が安全なやり方といえます。一方で、サードパーティーのツールには最上位のベンダつまりAppleやGoogleの意向でいつ排除されてしまうかわからないというリスクもあります。これまで見たところでは、今年や来年にそんなことが起きるとは到底考えられないのですが、それでも細かいトラブルはあるでしょう。

以上のような状況を鑑みるに、もしあなたがObjective-CやJavaでの開発に不安が残る状態であるなら、迷わず後者の方を選択するべきでしょう。その上で、自分の開発しているプラットフォームについて知ることは重要であり、そうであればいずれはネイティブな言語での理解が必須になるでしょうから、得られる知見を最大限に活かしてObjective-CやJavaでの開発について学んでいくのが理想です。例えば、PHPを使って開発をしていても、それだけしか知ろうとせず、ウェブサーバやPHP自体の実装といった抽象化されて隠された部分に分け入って進もうとしない人が、筆者の経験ではありますが、競争に耐えうる優秀な人材であった試しはありません。幸いにもサードパーティーのツールにはソースコードにアクセスできるものもあるので、良い手本になることがたくさん見つかるでしょう。

では、数あるサードパーティーのツールの中で、一体どれを選べばいいのでしょうか。

もちろん、おみくじで決めたとしても、それは当人の責任の範疇ですから、全く構いません。しかし、それでもやはり、いくらなんでももう少し真面目に考えないと不安になるかもしれません。なので、そうですね、それぞれのツールの特徴を掴んだ上で判断する方がいいでしょう。私自身も決定的な答えを用意しているわけではないので、知っている範囲で自分の意見を述べたいと思います。情報は最新とは限りませんので、ここは違う、いや今はこうなっている、などなどご意見あれば是非聞かせてください。いずれにせよ、現段階ではちょっとした宗派の争いみたいになりがちな話題なので、リラックスしてお読みくださいね。

サードパーティーのツール、と上ではひとくくりにしましたが、大きく分けるとこれも二種類に分かれます。ひとつはPhoneGapやRhodesのようにHTMLとJavaScriptで作ったUIをWebView(UIWebView)を使って表示させる、ウェブアプリとネイティブアプリが合体したようなもの、もうひとつはTitanium MobileのようにネイティブなAPIを叩いてJavascriptで記述しながらネイティブアプリとして動作するものです。ここでは実際に使ったことのあるPhoneGapとTitanium Mobileを比較します。

私見では、PhoneGapのいいところは第一にそれがシンプルであることです。例えば生成されるJavaのクラスは非常にシンプルで、実際に使ってみたところカスタマイズも容易でした。APIも数えるほどしかなく、プラグインの作成もそれほど難しいものではありません。また、UIはHTMLとJavascriptで作るので、ウェブ開発者やデザイナのこれまでに培った技術を活用することができそうです。

それに、例えばFacebookアプリは現在PC向けのものはHTMLで作られていますが、モバイル向けも今後は同じくHTML5を利用して記述され、Facebookのモバイル用アプリ内で動作するといったものになっていくことが予想されます。クロスプラットフォームでの開発が容易なのはHTMLの強みですから、こうした流れにソーシャルゲームのプラットフォームも追随していくのではないかと思います。

しかし、欠点もないわけではありません。jQuery MobileやSencha Touchといったツールを使ってなるべくネイティブアプリに似せることは出来ますが、それでもUIはネイティブなものではありません。これらのツールキットはまだ開発されてから日も浅くベストプラクティスも少ないので、開発はお世辞にも快適とはいえないのですが、それなのに特にiOSではHTMLとCSSででっち上げた「ネイティブっぽい」UIの「偽物」っぽさが際立ちます。動作もまだまだ快適とはいえません。またネイティブな機能への橋渡しをしてくれるAPIも豊富とは言い難いので、少しでも複雑なことに挑戦すると結局Objective-CやJavaでプログラムを作成する必要が生じます。UIレベルの話ならまだしも、例えばiCloudへの対応といった要求にはツール側での対応を待つかそれなりの工数を費やしてプラグインを作成することになってしまうでしょう。それに、これは年月が解消してくれる問題なのかもしれませんが、例えばSnapdoragonの第1世代のIS03のような貧弱なハードウェアではWebViewのようなリソースを消費するものはどうしても動作が遅くなります。オリエンテーションの変更の際にレイアウトが酷く崩れるといったユーザに不安を与えるような現象が発生することもあります。

最近、PhoneGapの開発元がAdobeに買収されることが発表されましたが、資金的には大きな後ろ盾を得たと同時に、大企業であり、これまで数々のプロダクトをディスコンにしてきたAdobeにその命運を握られてしまったともいえます。

以上、駆け足ですが個人的に思うところを述べてみました。先ほども書きました通り、ここは違う、いや現在はこうなっているといったご意見などございましたらお知らせください。

さて、その一方でTitanium Mobileの場合、Javascriptで記述した内容は評価された後にプロキシを通じてiOSやAndroidのAPIに渡されて実行されるため、実際に動作するのは通常のアプリと同じものなので外観は全くネイティブなアプリと変わりません。と同時に、Titanium.UI.WebViewというものが用意されているので、やろうと思えばHTMLとJSでUIを作ってしまうことも可能です。またこのJSとネイティブな機能を繋ぐのも非常に容易なので、この点でも大きなアドバンテージがあります。動作速度はネイティブアプリと比較すれば、インタプリタとコンパイル言語ほどではなくても、まあある程度の差はあります。しかし、シビアな反応が求められるゲームや電子書籍リーダといった特定用途のアプリでなければ実際に問題になるほどではありません。ネットワーク越しにデータをやり取りするアプリ、ウェブサービスのフロントエンド用アプリとして利用するには十分といえます。それに、驚くべきことに、最近ではQuickTiGame2dのような高速で動作するゲームエンジンも開発されていますので、ゲームの開発に利用されるようになる日も近いでしょう。また、このようなサードパーティーのモジュール開発も盛んで、Open Mobile Marketplaceで有料、無料を問わずたくさんの機能拡張用モジュールが公開されています。Githubにソースコードが公開されているものも少なくありません。

それから、jQuery MobileやSencha Touch(Ext.JS)といった一種独特なJavascriptよりも、commonJSといったモダンなJavascriptで記述することが推奨されているのもポイントです。最近ではNode.jsのようなサーバサイドのJavascriptもありますが、Titanium MobileのJavascriptもCoffeeScriptやcommonJSのような今時の技術を習得する近道となるでしょう。というのも、Titanium Mobileは基本的にはよくあるイベント駆動型のGUIのプログラミングなので、Node.jsのようなコールバックにつぐコールバックの連続にも面食らうことはありません。

と、いいことばかり並べましたが、もちろん問題もないわけではありません。Aptanaを買収してEclipseベースの独自のIDEがリリースされましたが、Eclipseがそうであるように人によってはあまり快適とはいえないものです。もちろん使わないで開発することも可能ですが、最初はやはり公式なツールを使いたくなる方も多いでしょうから、そこら辺で面食らうこともあるかもしれません。またビルドスクリプト内部にビルドにかかる時間短縮のため高速化する工夫があるのですが、何度も繰り返してビルドするうちにそれが邪魔をしてアプリの挙動がおかしくなることがありますので、ときどきCleanしてあげる必要があるといった癖のあるところも見受けられます。また海外製品にありがちなことですが、Pythonを使ったビルドスクリプトはUTF-8のMac OS Xで日本語の処理に問題がある箇所が多数ありますのでアプリ名称やプロジェクト名、ソースコードのフルパスに日本語が含まれていると辛い目に遭います。その辺りは、日本語でも有志によるサポートコミュニティがありますので、活用してください。

これらは今後改善されるべきことではありますが、一方で大半は公開されたソースコードから追いかけることも可能なことであり、ついでにいえばパッチを送って直してしまうことだって出来ます。個人的には、いつか大金持ちになって暇を持て余すようになったら、面倒の多いPythonの部分を全部Rubyにしてしまいたいと思っています。また、Titanium Mobileを入り口としていろいろと学びましたが、逆にネイティブな言語で開発しなくてもいいやという気にもなってきました。やっぱりDelegateとかってうんざりますよね?

以上、駆け足で比較していきましたので粗雑な部分、間違いなどもあるかもしれません。上にも何回か申し上げましたように、これは違うぞ、といったところがあればどしどしご指摘ください。よろしくお願いします。

Titanium、みんなどうやって書いてる?

Titanium Mobileでアプリを作るとき、みなさんはどうやって書いてますか?最近のプログラム開発なら、オブジェクト指向的な書き方であったりMVCなどいろいろなやり方があるでしょうが、TitaniumでJavaScriptだけで書いていると、どうもそれらとはあんまり親和性が高くないな、と気になっています。

自分はどうかといえば、例えば下のようにごく普通の書き方をしています。

//便利関数群
var utils = require('utils').utils;
var style = require('style').style;
var db = require('db').db;

//お約束
Titanium.UI.setBackgroundColor('#000');
var tabGroup = Titanium.UI.createTabGroup();

//初期化処理
db.init();

//rootウィンドウでも作りましょうか
var win = Titanium.UI.createWindow(style.top_win);
var tab1 = Titanium.UI.createTab(style.top_tab(win));

//rootウィンドウを表示しましょう
tabGroup.addTab(tab1);
tabGroup.open(style.open_tab);

そんなに大きな特徴はないですが、強いて挙げれば、viewの作成時のパラメータはHTMLとCSSみたいな関係にしてロジックとは分離したいので、style.jsというファイルを別に用意して、そちらに置くことで後で楽になるようにしています。i18nの絡みで文言などもこちらに移しています。

例えばこんな感じ。

var style = {
	top_win:{
		title:L('howdy'),
		backgroundColor:'#fcf',
		barColor:'#000'
	},
	top_tab:function(win){
		return {
			window:win,
			title:L('pow pow pow')
		};
	},
	open_tab:{
		transition:Titanium.UI.iPhone.AnimationStyle.FLIP_FROM_LEFT
	}
};
exports = {style:style};

わかりやすいし、別に問題はないのですが、美しくはありません。例えば「便利関数群」となっているところなんかは、もっときれいになるはずです。

が、どうもまだこれといったやり方が思いつきません。皆さんはどんな感じでやってますか?

TitaniumのHTTPClient

TitaniumでTitanium.Network.createHTTPClientをネストさせて使おうとするとうまくいかない。

var url = 'http://example.com/a';

var http = Ti.Network.createHTTPClient();
http.onload = function(){
  var url2 = this.responseText;
  var http2 = Ti.Network.createHTTPClient();
  http2.onload = function(){
    //素敵なサムシング
  };
  http2.open('GET, url2);
  http2.send();
};
http.open('GET', url);
http.send();

詳しく調べていないが、なんとなく試してみたら下のようにするとうまく動作する。

function http_client_two(url){
  var http = Ti.Network.createHTTPClient();
  http.onload = function(){
    //素敵なサムシング
  };
  http.open('GET', url);
  http.send();
}
function http_client_one(){
  var url = 'http://example.com/a';
  var http = Ti.Network.createHTTPClient();
  http.onload = function(){
    var url2 = this.responseText;
    http_client_two(url2);
  };
  http.open('GET', url);
  http.send();
}

http_client_one();

こんな感じでネストするHTTPクライアントを関数として外に出す。とりあえずのメモ。

Titanium DeveloperでAndroid(5)

今まで見つけた、Androidの場合に起きる不具合について。

(1) httpClientでPOSTリクエストが送れない、外部とのsocket通信ができない

これは笑っちゃうようなレベルの不具合で、よくもまあリリースしたもんだと飽きれる。HTTPによる非同期通信を起動しても、POSTリクエストで値を送信することができない。じゃあsocket通信でなんとかしようと気合いを入れ直すと、実はAndroidではsocket通信も動作しない

対応方法は、GETまたはリクエストヘッダに細工してデータを送るくらいしかない。次期リリースで改善されるという噂だが、どうだろう。正直まだあまり信用できない。

(2) 暗黙のIntentで適切なメディア再生用アプリケーションが起動できない

Intentで直接メディアプレーヤーやPDFビューワを起動したくても、いったんブラウザが起動してからブラウザ経由で呼ばれてしまう。

対処方法としては、AndroidManifest.xmlにIntentFilterを記述してやればいいようだが、時間がなかったのでIntentを作成している箇所をいじってTitanium mobileの機能を拡張した。ちょうどここにやり方が出ていたのでこれをヒントにやってみたらうまくいった。

(3) MediaPlayerがサーバ上のデータにアクセスできない

驚いたことに、KitchenSinkからリモートサーバのメディアへのアクセスがAndroid版から削除されていた。これはどうしようもないので、(2)と同じようにTitanium mobile側を改造するか、諦めるしかない。

というのも、例えばUIWebViewでHTML5のvideoタグを使ってメディアプレーヤの代用としてみても、Androidではアプリ内から起動するwebviewではvideoタグは起動しない仕様なので、いくら頑張っても無駄になる。

ただし、(2)の方法を使うと、openURLの改造でIntentが思い通りに動くようになるので、その場合はTitanium.Platform.openURL(またはそれを拡張した関数)でリモートのURLを呼び出してしまえばいい。メディア再生用の別アプリケーションが立ち上がるが、iPhoneと違ってAndroidなら再生が完了したらまた自分のアプリに画面が戻る。

(4) orientationの制限がまともに動作しない

これはAndroidManifest.xmlをいじって対応できる。まあ、魔術としかいいようがないが。

これらはいずれもiPhoneでは正常動作しているものが、Androidに限って動かないケース。繰り返しになるが、よくまあリリースしたもんだ。

Titanium DeveloperでAndroid(2)

前回まででSDKの用意ができたので、今度はサンプルを動かしてみよう。Titanium mobileには開発元のAppceleratorが公開してくれている「Kithchen Sink」というサンプルがあり、githubから入手できるので、さっそくインポート。失敗したら、新規にプロジェクトを作成してファイルをコピー(とチュートリアルに書いてある)。

ではエミュレータを起動、ほらすごい!といいたいところだが、なんとこのサンプルが、動かないのである。困ったものだ。原因はいろいろあるのだろうが、そもそもエミュレータで起動しない。もうどうしようもないので諦めるしかない。ちなみにiPhoneではちゃんと動く。 update: 動くようになった。

Androidに関してはKitchen Sinkはクソの役にも立たないわけだが、これでTitanium mobileのAndroid向け開発の能力には多いに疑念が湧いたため、シンプルなプロジェクトを新規に作成してサンプルにある各機能を試してみたが、全く先に進まない機能もある。でも試行錯誤するうちに、そんなときには、たまに何かわからないことがあったら、AndroidのSDKからこんなツールを起動してみるといいことがわかった。

Dalvik Debug Monitor

201012242236.jpg  

これは起動中のエミュレータをアタッチしてログ情報を表示してくれる便利ツールで、Android SDKのtools/ddmsという名前で格納されている。ちなみにマルチモニタに対応していないため、MacBookなどで主画面以外で起動するとクラッシュするので要注意。

もちろん、それでもダメなものはダメだ。例えば、ビデオのストリーミング再生はどう頑張っても音声しか出てこない。エラーをみるとバッファの取得中にタイムアウトしているようだが、だからなんだというのか。困ったものだ。

Titanium DeveloperでAndroid(1)

Mac OS Xでの作業を記録。

まず何より先にAndroid SDKを入手。brew からでもいいが、なんとなく、あくまでもなんとなく、ダウンロードして$HOME直下に設置。

設置したら、今度は各プラットフォーム向けコンポーネントをインストールする必要がある。ターミナルから$HOME/android-sdk-mac_86/tools/androidを起動する。

android.png

「Available packages」からAndroid Repositoryを選択して、とりあえず全部一気にインストール。

ここでちょっとした作業が必要になる。android-adk-mac_86/platform-tools以下にadbというスクリプトがあるのだけれど、これはSDKのバージョン7まではtools以下にあったらしい。Titanium Developerの作成するビルドスクリプトではまだtools以下にadbがあるものと見なしているらしく、このままではSDKの登録がエラーになってしまう。

とりあえず、手っ取り早く

ln -s $HOME/android-sdk-mac_86/platform-tools/adb $HOME/android-sdk-mac_86/tools/adb

で対処する。

update: このとき、Third party Add-onsからGoogleのレポジトリを選択して、そちらからのデータの取り込みもやっておく。地図APIなど必要なクラスライブラリがないのでデモ用のアプリケーションが動作しないのだ。

201101111424.jpg