9月24日発売の、ASCII.technologies 2009年11月号（アスキー・メディアワークス）に寄稿しました。
総力特集 「グーグルフォンを解剖する Androidはクラウドの夢を見るか？」内の「Android UIの特徴とゲーム開発テクニック」です。
コードを中心にした内容ではないので、そこら辺を期待してた人には申し訳ないですが。
個人的には、DoJa（iアプリ）とAndroid SDK間での主立ったクラス、メソッド等の対比表がなかなか便利かな、なんて自分で思ってたんですが、ページ数の都合上カットされてしまいました。そんなこともあるある…！
![ASCII.technologies (アスキードットテクノロジーズ) 2009年 11月号 [雑誌]](http://ecx.images-amazon.com/images/I/51lbtBHTI3L._SL160_.jpg)
ASEがupdateされてました。r13。
http://www.damonkohler.com/2009/09/ase-r13-released.html
インストールは↓の右ペインのFeatured downloads内、apkファイルをDL＆インストール
http://code.google.com/p/android-scripting/
以下、アナウンスの和訳
管理上の変更
・バージョンスキームの変更。 ASEは今回のr13(release 13)より、リリースナンバーを順次増加させていく形にする。（ASEは今もアルファバージョン）
・インタプリタのアーカイブのバージョン管理はASEとは別とする。こうすることで、リリースが簡単になるため、今までよりリリースのサイクルが早くなる。
機能
・ターミナルでソフトキーボードが使用可能に
・apkを小サイズ化
・pythonインストールに必要な容量を小サイズ化
・python help() が使えるようになった
・test.py が新しくなった。 これにはAPIを使用する例が多く含まれているので、スクリプトアーカイブと共に提供される形になった。バグフィックス
・Locale用のAPI更新
・いくつかのRPCメソッドを修正
ターミナルでソフトキーが使えるようになったのは何気に嬉しいですね。
あとはpython関係のupdateが多いですかね？
フォーカル、デジタル名刺「Poken」のオリジナルキャップを作成
http://japan.cnet.com/news/tech/story/0,2000056025,20400055,00.htm
実際にこのニュースに端を発して、日本Androidの会でもTシャツに続いてオリジナルキャップでもどうですかねなんて話が議題に挙がったりなどしております。
確かに会のイベントにはPoken持ちの人が稀に良く居るのでアリはアリなのですが、ボクが個人的に思うのは、これ自体を直接Androidに刺すわけでもないのでいまいちピンとこないです。
いやボクもPokenは持ってますけど、これでハイフォーしてPCやMacに刺して情報を取得して、というプロセスに何らAndroid関係ないんだよなーなんてことを思ってしまうわけですね。
iPhoneには、端末同士を重ねて振ればお互いのコミュニケーション情報が交換されるようなアプリが初期の頃からあったのですが、Androidもそのような形でPokenアプリみたいなのがデファクトであれば、Pokenも必要ないわけです。
しかし、現在市場に出ているAndroid端末やiPhoneにはそういう非接触式ICのような機能はないですし、IrDAもないです。
iPhoneアプリでは、代わりにGPSなどで端末のロケーション情報を取得しつつ加速度センサーなどを利用して、同地点で、同時に同じような動きをしている端末を検知したら情報をサーバー経由でやりとりする、といった事をするわけです。
現状adhoc通信のできない端末の場合、このような迂回策ですれ違い通信らしきものを実現することは理論上は可能です。
けれど、HT-03Aなどはまだ屋内でのGPSの精度がよろしくないので、例えば居酒屋で懇親会をしていて何組かがほぼ同時期に使ったりすると、正しく動作しない可能性が高い状況。
adhocモードか、非接触ICが搭載されてAPIが公開されるような端末が出てきてほしいですね。おサイフケータイが普及している国内の現状では、今後国内メーカーさんが出してくるであろうAndroid端末に、iDのようなものが載ってくるだろうことはわかるのですが、あれはあくまで決済システムですし。
PokenはUSB、Magic(HT-03A)やHeroにもUSB(miniB)があるから変換コネクタさえかませば物理的には刺さるんですけど、AndroidはUSBのhostにはなれず。
言うまでもないでしょうけど、Magic ＝ HT-03Aと考えてOKです。
| Tatoo | Hero | Magic | |
|---|---|---|---|
| CPU | MSM7225™ 528 MHz |
MSM7200A™ 528 MHz |
MSM7201a™ 528 MHz |
| ROM/RAM(MB) | 512/256 | 512/288 | 512/192 |
| screen | 2.8″ 240×320 QVGA |
3.2″ 320×480 HVGA |
3.2″ 320×480 HVGA |
| control | 4方向キー | トラックボール | トラックボール |
| cam | 3.2Mピクセル | 5Mピクセル オートフォーカス |
3.2Mピクセル オートフォーカス |
| battery | 1100 mAh | 1350 mAh | 1340 mAh |
| etc | 3.5mm オーディオジャック、 FMラジオ |
3.5mm オーディオジャック |
なし |
HTC Sense(Heroから使われてるUI、というかHome）がデフォルトのHomeより少しかっこいい分、スペックも少し要求するみたいで、HeroのイメージをMagicに入れて試してみるとswapだらけでちょっと実用には向かないのだとか。Heroだと特にストレスなく動くので、CPUに大きな差がない事を考えるとRAMがネックぽいですね。
そこを考えると、Tatooが普及機とはいえ、Senseを満足に動かせる分はメモリを（Magicより）増やさなければならなかったのかもしれません。
忘れないうちに今日のTokyo GTUG night #2の内容の補足を書いておきます。
mobileだとGoogle maps APIが遅い？ emobileだから？
「emobileで発表してたからたまたまとても遅かったのだけど、本来ならもう少し早い。mobileで特別早くなるということはないが、たとえばAndroidなどで使っていると早い」と勝又さんは答えていました。
それについての補足ですが、
なぜ、SDKや端末にプリインストールされているMap.appやGoogle Maps.appが高速に動いてるように見えるのかというと、クライアントがほぼnativeで実装されているからです。通常PCで見るmapsのようなflashやjsではないですし、Androidアプリである以上dvmは動作していますが、中身は多くがnativeだったりします。だから速度が出ます。
ちなみに、Androidでmaps apiを使う方法は大きく分けて二通りあります。
一つは、iPhoneなどのように、ブラウザ上でPC等と同じmaps apiを使用する方法。
もう一つは、ブラウザではなく、AndroidアプリケーションとしてJavaからcom.google.android.mapsのライブラリを利用してMapViewを表示する方法。
前者だと、ブラウザ上での動作なのでやれることはPCと大きくは変わりませんが、現行機種に搭載されているブラウザは多くがflashに対応していません（している機種もあります。HTC Heroなど）。
後者は、Androidアプリ製作で許可されてるハードウェア機能はすべて使えるので、例えばGPSやコンパスといったセンサーと連動させることが容易にできます。その代わり、Android専用アプリになります。
したがって、前者のブラウザ上で動作させる場合はハードの機能は使えないという形にはなっていますが、これはブラウザに依存する部分でもあります。
例えば、iPhoneのSafariだと、HTML5のGeolocation APIを利用することが可能になっているため、webアプリでもGPSを使用して現在地を取得することが可能です。
Androidのブラウザも、機能的にはiPhoneとほぼ同等のSafariなのですが、少しビルドが古いのかHTML5のGeolocation APIは（少なくともHTC Magic(HT-03A)では）使えません。ところが、AndroidのブラウザにはGearsが搭載されているため、GearsのGeolocationが使えます。したがって、ブラウザの設定でGearsをenableにしてあれば、GPSから現在地を取得できます。
詳しくは古旗さんの記事でもどうぞ。
iPhoneのJavaScriptアプリをAndroidに3行で移植
http://ascii.jp/elem/000/000/457/457545/
Web屋もハードウェアを直接使いたい、Googleなどはそんな取り組みをしているのか？
Androidに関しては、GPSなら今上に書いたように使うことができます。
Android以外では、ネイティブコードを実行するという事でなら、GoogleはNaClがあります。ブラウザからネイティブを実行するプラグインです。ネイティブを実行できるという事なら、理論上はハードも使えます。
(9/13 追記）ただ、だからこそ色々セキュリティ上の制約はあり、現状ではハードを自在に扱えるようなものではありません。(追記終わり)
さらに上げると、Chrome OSはブラウザからハードも使えるようになっているはずです（さすがに現時点では詳しくはわかりませんが）。
話を再度、Androidに戻すと、AndroidアプリではWebViewというクラスを使うことで、ブラウザのレンダラを使用した表示をすることが可能です。WindowsでいうところのIEComponentのようなものです。アプリの中でWebViewを表示することで、ブラウザでWebページを表示するのと同等の表示結果が得られるわけです。
そして、当然WebViewはブラウザなので、JavaScriptも動作します。
つまり、こういうことが可能です。Androidアプリ(Java)で端末のセンサーなどのハードウェア機能を制御し、その結果をWebView内のjsに渡してwebを表示する。まあこんなことする意味があるのかどうかはおいておくとして、可能は可能です。
さて、ハードもひっくるめてwebアプリで制御するようなプロダクトを作りたい、といった事ですが、そのような試みを実際にしている企業さんや個人さんなどがAndroid界隈には既に結構な数の方がいらっしゃって、日本Androidの会やOESFなどでは既に何人もの方が発表していますので、興味のある方は是非月例イベントなどに足を運んでみてはいかがでしょうか、という宣伝で終わらせてしまう、ピュアなハートの大人でした。
WEB+DB PRESS Vol.52と組込みプレス Vol.16（共に技術評論社）を読みました。
両誌ともに、Androidと関連性の深い特集が掲載されています。
WEB+DB PRESSは
～良いコードを書くために，知っておくべきこと～［新人さんに贈る］Javaプログラミングの習慣
第1章：人に意図を伝えるコーディング
良いコードを書く道しるべ
第2章：イディオム
名前付け，メソッド定義，総称型，列挙型
第3章：継承とオーバーライド
人に使ってもらうためのプログラミング
第4章：インタフェース
約束でつながるプログラミング
第5章：クラス設計
例外設計，不変オブジェクト，クラス分割
といった内容です。Javaの特徴の基礎的な部分の解説です。AndroidはJava5がベースとはいえ、厳密にはJVMで動作するわけでもありませんし、独自ライブラリを使用したり、挙動が純正なSunのJavaとは違うところがあるのは確かです。ですが、基本的にはJavaのsyntaxですし、基本となる部分は一緒です。Java5ベースとなっていますので、Googleから提供されているサンプルコードなども当たり前のようにGenericsやannotationが使われています。なんとなくの理解で済ませてきた人や、Java4以前の記述法しか知らない人などは、復習してみる良い機会かもしれません。
一方、組込みプレスの方は、
Androidによる組込み開発
第1章：Androidが変える組込みシステム
第2章：Android高速化テクニック
第3章：Androidネイティブコードデバッグ手法
第4章：Android NDKを用いたJNI開発手法
第5章：プロファイリング手法
第6章：Androidポーティング事例
という特集です。
Eclipseを使ったネイティブ開発など、アプリ開発に直接役に立ちそうな記事もあります。でもそれだけではなく、Androidの低レイヤーの部分の理解を深めることで、アプリ動作時のOSの挙動などの原因がわかり、それによりアプリ開発であれデバッグや改善などがしやすくなるはずです。
興味があったら読んでみてはいかがでしょうか…！