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が今後第３極として台頭してくるのか楽しみですね。

パーソナルアシスタントの未来

AppleのWWDC、MicrosoftのWindows Phone Summit、GoogleのGoogle I/Oと、ここのところ立て続けにイベントが開催されて、興味深いニュースが沢山出てきました。

順番は前後して、まずMicrosoftからですが、Windows Phone8でカーネルがWindows 8系に刷新されることが発表されました。Windows Phoneではいままでマルチコアがサポートされてなかった為にハードウェアスペック的にはかなり見劣りしたものとなってましたので、これでようやくiOSやAndroidと戦えるものになりました。

MicrosoftがOSカーネルの基本機能で出遅れるというのも何だか意外な感じもしますが、逆にここはいつでもキャッチアップできるからUXの開発を優先したとも言えます。

ただ、後述しますがAppleやGoogleは既に次のフェーズへと戦いの舞台を移しているので、周回遅れを挽回したとまではまだ言いがたい状況です。

Appleは、今回のWWDCの目玉はRetina Macbook Proで、iOSに関しては控えめな発表のように思いました。これはiPhone5の登場に向けてまだ何か隠し玉があるような気がしてますが、どうでしょうか？

影響の大きそうなところと言えば、Mapを従来のGoogle Mapから独自のものに切り替えたことでしょう。GoogleのAndroidとは競争が熾烈になってきているので、コアな機能を他社に握られたままでいることは好ましくない為、ある意味当然と言えば当然の戦略ですが、まだ地図の完成度が低いので正式版に向けてどう仕上げてくるのか楽しみではあります。

独自のMapを強力な武器に仕上げられなかった場合は、逆に足かせとなる可能性もあり、そういう点では諸刃の剣と言えるでしょう。ただ、GoogleはiOS向けにMapアプリを提供し続けるでしょうから、ユーザーとしては実用的な方を単に使えば良いだけなのかも知れません。

Googleは、Jelly Beanで着実にAndroidの完成度を高めました。特に画面遷移の滑らかさやタッチのレスポンスでこれまで遠くiOSに及びませんでしたので、額面通りに改善されたのであれば、Androidもいよいよ死角が無くなってきたのかも知れません。

もとより、OSの機能としてはAndroidの方が上だと個人的には考えており、ICSでUIのデザインもかなり洗練されたと思ってます。iOSは始めの完成度が高かったことから見栄えはほとんど変わっておらず、そのせいもあってか、情報量の少ないホームスクリーンもいまとなっては何だか古臭く感じるくらいです。

しかしAppleやGoogleはOSの機能よりはスマートフォンの今後のあり方や使われ方、特にパーソナルアシスタントとしての機能向上に開発のフェーズを移しているような気がするのです。

というわけで相変わらず前置きが長いですが、ここからが本題です。

パーソナルアシスタントとしての機能は、AppleがSiriで先鞭をつけた感があるのですが、Androidは従来からある音声検索の機能を改善するという手で来ました。AppleのSiriのように特別なネーミングを付けなかったのは、もしかしたらAndroidという名称自体が既にそのような性格を持ち合わせているからなのかも知れません。

Siriや音声検索はユーザーからの能動的な問いかけに対するものですが、パーソナルアシスタントとしてより重要なのは、Google NowのようなユーザーのTPOに応じてスマートフォンが自律的にユーザーに取って有用な、あるいは利便性の高い情報を提供/提案するような機能でしょう。

しかしこのようなパーソナルアシスタントが有効に機能するには、ユーザーのかなり詳細な行動(スケジュールや位置情報など)やプライベートな情報(交友関係や趣味、趣向など)を情報としてインプットしなければならないので、セキュリティがこれまで以上に重要になります。

極私的な情報がいつネットに流出するかも知れないという不安がある中では、誰も安心して使えないですものね。それにこういうユーザーの行動が広告などに二次利用されることへの嫌悪感をどう払拭できるか？というのも大きな課題だと思われます。

本来、行動ターゲッティング広告というものはユーザーに取ってもメリットのあるものであるはずなのですがね。

また要人におかれましては、自分の位置情報がプライバシーの侵害や犯罪に利用される可能性も否定できないので、こういう技術が単に便利だからと、すぐに世の中で受け入れられて使われるようになるまでは、まだまだ時間がかかるものと思われます。

そういう意味では、ユーザーが機能をコントロールできるon{X}のようなものの方が、始めは受け入れられやすいのかも知れません。ただ、一般ユーザーがJavaScriptでコーディングするというのもハードルが高いし、最終的にはGoogle Nowのような検索履歴等から自動で機械学習するようなシステムじゃないと普及しないでしょう。

パーソナルアシスタントの機能が、ユーザーからの膨大なインプットから、ユーザーがもっとも欲するデータを引き出すものであるとすると、ユーザーからの大量のインプットを処理するには、データを格納する器となるデータセンターやクラウドコンピューティングなどのシステムが欠かせません。

Appleは沢山のアクティブユーザーを抱えていることから、インプットに関しては申し分無いと思われるけど、器を作る能力にはやや不安がある。Microsoftはりっぱな器を用意する力はありそうだけども、如何せんインプットが少なそう？

そういう意味ではこの分野は、いまのところGoogleが一番うまくやれそうな気がします。検索市場を独占していることから、Androidユーザー以外からの膨大な検索クエリーのデータもアルゴリズムの改善に活用できることも有利に働くでしょうし、データマイニングも研究者集団たるGoogleの得意とするところのような気がします。

しかし、AppleのUXデザインの巧みさや、短い時間でキャッチアップしてくるMicrosoftの開発力も侮れないので、実際の人間のように三者三様にそれぞれに性格の違うパーソナルアシスタントとして発展して行けば面白いのではないか？と思います。

例えば、Appleのはクールビューティで的確な回答を示すが扱いが少々気難しいところがあるとか、Googleのはほとんどの場面で完璧な答えを出すけど、稀に重要な情報をうっかり外に漏らしてしまうドジっ娘だったりとか、で、Microsoftのは何でも卒なくこなして実用性では一番なんだけど、なぜだか一般受けが悪かったり？とか。

そんな近未来を妄想する今日この頃です。

AIRとTitanium MobileがBonjour

モバイル端末上のアプリケーションデータを、PC上の別アプリケーションに送りたいような場合に、HTTPサーバーを立ててやる方法もあるにはあるんですが、事前にIPアドレスを知っていないといけないとか、もひとつエレガントさに欠けると思うんですよ。

で、PC側がMacintoshでモバイル側がiPhoneならば、Bonjour(リンク)を使ったらネットワークの面倒な設定をしなくても簡単にやり取りを出来るんじゃないかと思い、試してみました。

iPhone側はTitanium MobileがBonjourをサポートしているので、これを利用すれば良さそうです。今回は、Kitchen SinkにBonjourを使ったサンプルがあるので、せっかくだから、これをそのまま使用します。

Mac側はAIRでアプリを作ることに決めているんですが、残念ながらAIRではBonjourをサポートしておりません。仕方ないので、NativeProcessで外部アプリを利用しましょう。

1. dns-sdコマンドラインツール
 Macにはdns-sdというコマンドラインツールがあって、これでBonjourサービスの検索や登録ができます。このツールを使って、接続したい機器のアドレスとポートの情報を取得するまでの手順を確認しましょう。

まず事前に、Kitchen SinkのPlatformタブにBonjourってのがあるので、これを選択しておきます。これは、Bonjourのサービスを起動すると共に、そのサービスとのやり取りを兼ねたサンプルとなっております。

ソースコード(リンク)を見てみると、サービスタイプが _utest._tcp になっているので、以下のコマンドを実行すると、このサービスタイプを提供している機器のインスタンス名を取得できます。

$ dns-sd -B _utest._tcp

インスタンス名が取得できれば、以下のコマンドでアドレスとポートを知ることができます。

$ dns-sd -L <インスタンス名> _utest._tcp

ここまでわかれば、後はAIRで、このアドレスとポートに接続するSocketを作成してあげれば、それを通じてやり取りが出来るようになります。

実際に上記コマンドを実行して、出力されるログを確認してみてください。

2. AIRアプリの作成
AIRで外部のプログラムを起動するには、NativeProcessを使用します。以下のようにして、まずインスタンス名を取得するコマンドを実行します。

var process:NativeProcess = new NativeProcess();

var args:Vector.<string> = new Vector.<string>();
args.push("-B");
args.push("_utest._tcp"); // 今回のサンプルのサービスタイプ

var info:NativeProcessStartupInfo = new NativeProcessStartupInfo();
info.executable = new File("/usr/bin/dns-sd");
info.arguments = args;

process.start(info);
process.addEventListener(ProgressEvent.STANDARD_OUTPUT_DATA,
    onBrowseService);

コマンドの実行結果は標準出力に出ますので、ハンドラー関数の中で以下のようにして、結果を取得し、インスタンス名に当たる部分を抜き出します。

private function onBrowseService(event:ProgressEvent):void{
  var stdo:IDataInput = process.standardOutput;
  var result:Array = stdo.readUTFBytes(stdo.bytesAvailable).split('\n');
  var column:String = String(result[result.length - 3]);
  var index:int = column.search("Instance Name");
  if (index != -1) {
    var instanceName = result[result.length - 2];
    instanceName = instanceName.slice(index); // インスタンス名
  }
}

ここでは、直前の行の"Instance Name"文字列の位置を手がかりにインスタンス名を抜き出してます。また、同名のサービスタイプを提供する機器が複数存在する場合を考慮してません。

インスタンス名がわかれば、以下でアドレスとポートの情報を取得します。

var process = new NativeProcess();

var args:Vector.<string> = new Vector.<string>();
args.push("-L");
args.push(インスタンス名);
args.push("_utest._tcp");
    
var info:NativeProcessStartupInfo = new NativeProcessStartupInfo();
info.executable = new File("/usr/bin/dns-sd");
info.arguments = args;
process.start(info);
process.addEventListener(ProgressEvent.STANDARD_OUTPUT_DATA,
    onResolveService);

同様にコマンドの実行結果は標準出力に出ますので、ハンドラー関数の中で以下のようにして、結果を取得し、アドレスとポートに当たる部分を抜き出します。

private function onResolveService(event:ProgressEvent):void {
  var stdo:IDataInput = process.standardOutput;
  var result:Array = stdo.readUTFBytes(stdo.bytesAvailable)
                                      .split("can be reached at ");
  if (result.length == 2) {
    process.removeEventListener(ProgressEvent.STANDARD_OUTPUT_DATA,
        onResolveService); 
    result = result[1].split(" (");
    var iNamePort:Array = String(result[0]).split(":");
    var address:String = iNamePort[0];     // アドレス
    var port:int = parseInt(iNamePort[1]); // ポート
  }
}

アドレスとポートがわかれば、それとやり取りする為のSocketを作成してあげます。

var socket = new Socket();
socket.connect(address, port);
socket.addEventListener(Event.CONNECT, onConnect);

無事に接続すると、ハンドラー関数が呼ばれます。Kitchen Sinkのサンプルでは、ターゲットに"req"という文字列を送ると、機器情報を返信してきますので、これを受け取れるように受信ハンドラーを設定しておきます。

private function onConnect(e:Event):void {
  socket.addEventListener(ProgressEvent.SOCKET_DATA, onSocketData);
  socket.writeUTFBytes("req"); // ターゲットにデータ送信
}

// ターゲットからデータを受信
private function onSocketData(e:ProgressEvent):void {
  var reply:String = socket.readUTFBytes(socket.bytesAvailable);
}

ご参考までに、以下に実際に動作するAIRアプリのソースコードを置いておきます。
http://homepage.mac.com/daoki2/lab/Bonjour/BonjourTest.tar.gz (4KB)

以上のようにすれば、Bonjourを介して、MacとiPhoneで簡単にデータのやり取りを行うアプリを作ることが出来そうです。ただ、Mac以外やAndroidでは、どうすれば良いのでしょうか？

実は、ここ(リンク)にBonjourのJava実装のソースコードがあるので、これを使えばもしかしたらその他のプラットフォームでも同じようなことが出来るかも知れません。

もしうまく動かせたら、是非教えてください (^_^;

b-mobile Fairレポートその２

昨日、b-mobile Fairの簡単なレポートを報告しましたが、自分の普段のスマフォの使い方を詳しく書かなかったので、あまり参考にならなかったと思います。

今日、平日の典型的なパターン通りに使ってみて、データ通信量がどの程度だったか、確かめてみました。以下、普段の利用パターンです。

・まず、自宅では事情が無い限りは機内モードに設定し、Wi-Fiを有効にしてある
・家を出る時にWi-Fiと機内モードを無効に設定(つまり3Gを有効にする)
・通勤電車内で、twitterとwebサーフィンを少々
・帰宅したら、また機内モードに設定

これで、今日確かめてみたら3MBしか消費してませんでした(笑)。
結局のところ、自分は通勤電車内(往復約１時間)で少しネットをやるくらいなので、ほとんどデータの通信は発生しないみたいですね。もしかして、スマフォ要らん？

後は、稀に休日に出先で調べ物をしたりとか、今後、勉強会でノートPCのテザリングに使った時にどれだけ消費するか？何だけど、目安の250MB/月を大きく超えることはないような気がしてます。詳細は、その機会があった時にまた調べてみようと思います。

あと、スピードに関してですが、AndroidのSpeedTestがようやく東京のサーバーを捕捉してくれたので、比較してみました。

Download/Uploadスピード

NexusOne	2.78/0.38Mbps
iPhone3G	1.21/0.22Mbps

計測する場所や、その時のネットワークの状況にもかなり左右されるとは思いますが、自分の体感的にもNexusOneの方が明らかに速く感じるので、やはりドコモ回線はそれなりのスピードが出るようですね。

が、まぁご参考程度にお考えください。

b-mobile Fair購入レポート

b-mobile Fairを購入して、手持ちのNexus Oneに挿して使ってみました。

実はau EVOのWiMAX&テザリングに魅力を感じてたので、XOOMとのセット販売がされれば購入しようかとも考えてたのですが、セット販売はWi-Fi WALKERのみというナゾ仕様なので、当面手持ちのNexus Oneを活用して、夏モデル以降に期待という戦略に切り替えました。

だって、EVOって海外だと１年前のモデルでっせ？それが日本では最新の携帯として売られるこの悲しさ・・・

それに、WiMAXより3Gの方が受信が安定して速度も出るケースが多そう？なので、自分の使い方とデータ通信量しだいでは、今後もb-mobile Fair + SIMフリー端末で行く可能性もあるかな。

ちなみに、今日、普段の使い方に近いイメージで使ってみて、大体6MBくらいを消費。これだと、250MB/月を下回るので、4ヶ月持つ計算に一応はなるね。まぁ日によってだいぶんと前後するんだろうけど、2500円/月で通信費を運用できれば、かなりお得だ。

で、気になる速度をSpeedTest使って計測してみたけど、Android版がなぜか何回やっても東京のサーバーを捕捉してくれないので、参考程度に海外のサーバーで比較すると、概ねソフトバンク回線の1.5倍ほどスピードが出ている。上りは3倍くらい出ることも珍しくはない感じ。

ここら辺はさすがはドコモ回線というところか？でも端末のCPUの速度も結構違うので、その影響も多少あるのやも知れん。

と言うことで、すっかり古くなってしまったiPhone 3Gは塩漬けにして、しばらくAndroidを常用してみようと考えているんだけど、Nexus Oneさんのバッテリー消費が結構激しいのねん・・・

AIR for iOSやってみた

AIR2.6 SDKからiOS用のパッケージを作成できるようになりました。ただ、所有しているiPhoneが3Gの為にiOS3.xからアップデートを行っておらず(AIR2.6 SDKで作成できるのはiOS4.x以降のパッケージ)、いままで試す機会がございませんでした。

今回、iPod 4thを手に入れましたので、早速以前にAndroid用に作成したアプリをiOS向けに書きだして、どんなもんか確かめてみました。尚、AIR2.6 SDKの詳細に関しては上条さんのblogに詳しいので、そちらをご参照いただければと思います(リンク)。

１. 開発証明書ファイルとプロビジョニングファイル
iOS用AIRアプリケーションの作成手順に関しては、ここのドキュメント(リンク)が参考になりますので、目を通しておいてください。

iOS用にipaインストーラーファイルを作成するには、Android同様にadtコマンドを使用しますが、その際に、P12ファイル形式のApple開発用証明書ファイルとApple開発用プロビジョニングファイルが必要になります。

既に、iOS用にアプリ開発する環境がセットアップされていれば、開発証明書ファイルはキーチェーンアクセスから書きだすことが出来ます。また、プロビジョニングファイルは、iOS Provisioning Portalからダウンロードできます。

具体的なadtコマンドは以下のようになります。

adt -package -target ipa-debug 
    -keystore iosPrivateKey.p12 -storetype pkcs12 -storepass qwerty12 
    -provisioning-profile ios.mobileprovision 
    HelloWorld.ipa 
    HelloWorld-app.xml 
    HelloWorld.swf icons Default.png

２. アプリケーション記述ファイル
iOS用のアプリケーション記述ファイルで指定できる内容に関しては、ここのドキュメントをご参照ください(リンク)。Androidとは指定する内容や、記述方法がだいぶん違うことにはじめは戸惑いますよね。

まぁ、何はともあれ、これでipaファイルを書きだせば、後はそれをダブルクリックして、iTunes経由で実機に転送というPackager for iPhoneと同様の流れになります。ちなみに、ipaファイルの書きだし時間はPackager for iPhoneと比べて、だいぶん短縮されてます。

で、動かしてみたのですが・・・「お、遅い」。えぇ、Android(NexusOne)と比べて明らかに遅いのです。まぁ、全く同じハードでは無いので、厳密な比較はできないのですが、iPhone4相当のiPodとNexusOneで、そんなにハードウェアの処理速度に違いがあるとは思えません。

比較したアプリが、Bitmapの描画とフィルターを酷使するもの(Particle Break)だったので、恐らく高解像度なRetinaディスプレイが不利に働いているものと思われます。

また、iOSではNativeApplication.nativeApplication.exit()が効かないらしく、アプリ側からアプリを終了させることが出来ません。ホームボタンを押して、アプリがバックグラウンドにまわった時には、一応実行は止まります(アプリを選択することで、動作が再開します)が、ちょいと不便ですわね。

まだ触りはじめたばかりなので、何か勘違いとかしているかも知れませんが、個人的にはややがっかり・・・でも、まだ出たばかりだし、Androidもはじめは遅かったから、今後ランタイムがチューニングされて行くことに期待しましょう。