preload
4月 13
WifiSignalChecker

WifiSignalChecker

Android Market への初めてのリリースです。とは言っても、わかるひとには一瞬でつくれるような素人作品なのですが。。大したものではありませんので、ご笑覧いただきたく。

WifiSignalChecker は Android を搭載したデバイスでの Wifi (802.11無線LAN)電波強度をモニタするための電波測定ツールです。現在接続中のアクセスポイントから受信しているシグナルレベルをリアルタイムに表示します。

WifiSignalChecker は Android Market でフリーソフトウェアとして配布しています。Applications > Tools の下にあります。社内無線 LAN 環境のちょっとした電波調査や、PC で公衆無線 LAN を使用する際の座席選定などに、お気軽にご利用ください。

なお、日本国内での利用においては、端末の利用が制限/規制対象となっている場合があります。電波法を確認いただき、ご利用は自己責任にてお願いいたします。


こうしている間にも、レビューが付いたりコメントが付いたりで、嬉しいですね。ヘボアプリなので、いろいろ厳しい意見も来そうですが、ぼちぼち糧にしていければとおもいます。

ほんとはいろいろお遊び機能を盛り込む予定だったのですが、ちょっと忙しくなってきてしまったので、単一機能にて先にリリースすることにしました。今後更新することができれば、こちらのブログでも更新情報を流していく予定ですので、よろしくお願いします。

Tagged with:
4月 07

日本Androidの会主催の定例イベントでお話を聞いてきましたので、簡単にレポートします。

DalvikVM on JavaVMの話をメインで聞きにいきましたが、後半の家電ビジネス周りのお話も初めて知ったことが多くて、勉強になりました。とても濃いお話で楽しめましたです。

Ust録画がここで見られそうな予感。幹事のかた、スピーカの皆様、ありがとうございました。

イーフロー 久納さんによる、DalvikVM を Pure Java (CLDC) で実装した話

  • 久納さんがこれまでにつくったものの紹介
    • QuickBASICの処理系
      • 6000行くらい
    • JavaScriptで動くGameboyエミュレータ
      • ほんとに動いてた。変態だw
      • Canvas処理周りが、Google Chromeが最速とか
      • Wiiブラウザでも動くようにつくってあるとか
      • 4000行くらい
    • Skype4Java
      • Skype APIのJavaラッパ .. Skype公認とか
  • DalvikVMをつくってみたことについて
    • Google公開の仕様ドキュメントがやけに少ないので、自分でつくってみて、よく理解してみようとおもったらしい。ふむふむ
    • すでにケータイJavaVMで動くJavaVMの実装を作ってあったらしく、それに手を加えて4日半くらいでつくったとか。おおー
    • オープンソースで公開することで、イーフローさんがDalvikVMに取り組んでることをアピールしたいとか。なるほどねえ。勉強させていただきます
  • つくったDalvikVMの動き
  • どうやって作っていったか、とか、作っていて気づいたこととか
    • dexdump使って、dexバイトコードをダンプしてみて、追ってみる
      • バッチファイル書いて効率化。$ adb shell “<adb shellで実行するコマンド>” とかでadb shellへコマンドを飛ばせるらしい
    • DalvikVMの命令コードは2Byte(16bit)単位の可変長(最大80bit)らしい
    • バイトコードのエンコードを短くするための工夫が見られる。長いメソッドディスクリプタに命令コードを割り当てなおしたり、配列のデータをとり回す処理が一命令コードになってたり。
    • メソッド内でのレジスタの使い方が変わってる?引数やメソッドローカルな変数などはレジスタに。返り値や例外は、特別な場所へ入れてる?(このへん、意味がよくわからず)
    • 命令コードの説明などなど。Constなんとかでレジスタへの変数格納とかとか。
  • ベンチマーク
    • Embedded Caffeine Mark
    • Google Dev Phone(Dalvik)とP905i(JBlend)で比較
    • StringでDalvikVMの方が1/10くらい遅い
      • なぜか?実行コードが単純に多いからっぽい。JITコンパイラ使って最適化すれば、高速化の余地はありそう
  • VM on VMについて
    • 開発済み資産の再利用とかとか
    • Java MEの世界でいえば、動的なクラスロードができないという制約を超える一手としても

Celevo 岩佐さんによる、家電向けDalvikVMとCE向けAndroid Marketに関する話

  • CE は Windows CE(懐かしい)ではなくて、Consumer Electronics のほうでした
  • Celevo の話
    • 家電ベンチャー。デジカメ作ってるそうです
  • デジタル家電がハード勝負からソフト勝負になっていってる話
  • 家電メーカーにとって、ソフト差別化が(いろんな理由で)難しいし、舵切りできてないという話
  • ハードで勝負するにも、モジュール化が進んでて、海外の部品特化メーカ(IntelとかT1とかNVIDIAとか)が強い
  • 家電にユーザが作ったアプリが載る時代 .. 家電メーカーからすると「来ちゃったか」
    • PCつくるのは儲からない .. 家電もそうなっちゃうかも
  • 小規模でもハードウェアに参入できるようにもなってきたという話
  • デジタル家電のプレイヤーの話
    • 量販では、BUFFALOとかI/O DATAの売り場と(旧来からの)家電売り場で流通マージンがちがうのでごにょごにょ
    • 大手家電メーカは動きにくいね、という話
  • CE 向け Android Market の登場が、大きなターニングポイントになりそう
    • メーカは家電販売が主。そういうアプリの販売機能を持ちにくい。サーバホスティングもやりたくない、らしい
    • 出てくるには、メーカをまたいだUIの標準化や仕切り、メーカ承認フラグみたいな仕組み、DRMとかとかも必要に
  • 誰がやるんでしょうね、とかとか

日本Androidの会 木南さんによるLBSの話

  • LBSつくった話と、アイデアなど。
    • ショートペッパー、良いですね!
Tagged with:
3月 22

3/19, 20 に開催された Android Hackathon に参加してきました。参加者は 2 日間いずれかへの参加を選ぶ形式で、僕が参加してきたのは 3/19 のほう。主催は Android SDK Japan(User Group)、会場は Google さんの東京オフィスでした。というわけで、イベント概要やら、そこでつくったものの報告とか、メモとか、感じたこととかを書いておきます。

ところで、Hackathon というのは、Hack + Marathon の造語らしいですが、平たく言うと、お泊まり無し(そうでない場合もあるかもだけど)の開発合宿みたいなものです。で、今回は、Android Hackathon だったので、みんなで Android アプリ/サービスをつくろうぜ、的なイベントだったということになります。

今回の Hackathon では一週間ほど前に事前ミーティングが開かれており、そこで参加者のチーム分けや Ideathon なるアイデア出しの打ち合わせがおこなわれていました。チーム区分は以下の通り。

  • Lifestyle & Travel – 日常生活や旅行先で使える便利系アプリ/サービス
  • Multimedia – マルチメディアを駆使(?)するもの
  • News & Weather – ニュースとか天気とか。RSSフィード使ってごにょごにょとか。
  • Specific Device(Feature) – デバイス固有の機能を使ってごにょごにょ
  • Tutorial – テーマは決めず、チュートリアル的になんか作ってみる

僕は Specific Device のチームに参加させていただきました。で、Ideathon でいろいろ討議した結果、「端末によるモーションジェスチャを検知する仕組み(ライブラリ)の開発」&「その仕組みを使ってかめはめ波を撃つ」という壮大な目標にチャレンジすることとなったのでした。

さて、Hackathon 当日の成果ですが.. 結果から言うと、「かめはめ波」の捻出には至りませんでした。まだまだ修行が足りなかったようです。残念。

ただ、以下のような見栄えの、「単純なジェスチャの検知」アプリまでは行き着くことができました。

device

上の画像は、アプリ起動後、端末を上方向に持ち上げたときの画面表示です。とりあえず、端末を平面方向タテヨコナナメに直線に動かした際の8方向について、なんとなくジェスチャが検知できています。ほんとは、ここからこういったシンプルなジェスチャを組み合わせたジェスチャコマンドを認識させ、かめはめ波を撃って、あと、昇竜拳くらいまで行きたかったのですが、残念ながら力及ばず.. でした。

当日開発されたソースコード一式は、以下の hackathon-jp リポジトリから取得できますので、ご興味のある方、どうぞご覧ください(コミット権限はHackathon参加者に限っているようですので、read-onlyにてご了承ください)。

http://code.google.com/p/hackathon-jp/


さて、以下、今回の Hackathon 参加で自分なりにやってみたことや感じたことをメモしておきます。

今回は、事前準備として OpenIntents の Sensor Simulator を動かしてみたり、OpenIntents の trunk にいつのまにか入っていた SensorGestureDetector の実装を読んでみたり、なんとなくヒントがあるんじゃないかと Firefox の All-in-one Gestures の実装を読んでみたりしてました。

また、「ジェスチャを複合して『かめはめ波』のような複雑なジェスチャを組み立てるより、任意のジェスチャパターンを学習させられるようなトレーニングアプリを作って、ジェスチャパターンを数値化していくのが良いんじゃないか」とも考え、ジェスチャ時の各種センサの値をcsv出力するデモアプリを作ってみたりもしました。そんな折に、チームの方から、「HMM(隠れマルコフモデル)による学習/識別が主流らしい」との情報もあり、ググってみて、なんだか難しい論文に行き着いたりしていました。

ただ、Hackathon 当日は、なんだかんだで時間制限に押され、

  • ジェスチャで取得できたcsv値も隠れマルコフモデルとかもよくわからん.. 深みにハマりそう
    • やっぱしとりあえずはシンプルなジェスチャを認識させるところを作ろう
  • どうも加速度センサの値がオカシイ
    • 重力加速度の影響を受けてしまっているみたいだ
      • 重力加速度をキャンセルできるように、逆向きの加速度を渡してみよう
        • 端末のどちら側が地表側を向いているのかを適切に数値化するのが難しい..
          • とりあえず、端末の向きは固定で使うってことにしよう
  • Z軸方向のジェスチャの認識を加えると、認識精度が落ちるみたいだ
    • とりあえず、今日のところは X-Y 2方向の平面ジェスチャのみでいこう
  • 平面でもイマイチ精度が悪い
    • 一定時間(回数)以上、同方向の加速度が取れることをジェスチャ認識の条件にしよう
    • センサデータ取得時の速度を変更させるオプションがあるらしい => 最高速度(SENSOR_DELAY_FASTEST)に!

と、まあ、こんな感じに試行錯誤の繰り返しに多くの時間を使ってしまっていたような気がします。最後のプレゼンが終わった後になって、他の参加者の方に「重力加速度のキャンセルにはローパスフィルタ使うといいよ!」って教えてもらったり、既に試行錯誤されていた方のエントリを発見したり、という感じで、なんだかんだで準備不足、力不足を痛感したわけでした..

とはいえ、こういった開発は久しぶりに新鮮でした。「時間制限(のプレッシャー)」と「チームでの開発」があったおかげでしょうか。意見交換したり、コード見せ合ったりしながらも、ひとりで深みにハマる前に、上のような「問題の単純化(「あきらめ」ともいう)」や、「仕様の割り切り」「当座の目標決定」を短いサイクルで繰り返し、一日での成果を出すことに集中する、ということができたような気がします。で、しかも、それが、とても楽しかったわけです。良いですね、こういうの。僕、いわゆる「開発合宿」には参加したことが無いんですが、その楽しさの一端が垣間見えたような気がしました。


そんなこんなで、当日の他のチームのプレゼンや飲み会の部まで含めると、とても書き切れないほどの多くが得られた、楽しいイベントでした。同じチームの皆様はじめ、ご参加の皆様、主催や協力の皆様、お疲れさまでした。ありがとうございました。

Tagged with:
1月 12

はてなの人気エントリをぺぺーと流し読みしていたら、去年はAJAXとCometがWebを変えた、というようなくだりが目に入った。Comet?ええ、恥ずかしながら初耳です。
と、いうわけでヒマな会議中に情報収集。
要は、サーバからのコンテンツPUSHを実現する手法論を指しているようだ。
たとえば、クライアントからのリクエスト(ポーリング)に対して、レスポンスを保留しちゃおう、ということらしい。チャットとかでサーバ側のコンテンツに変更があったらレスポンス返す、という感じで、その間HTTPコネクションは張りっぱなし。このポーリング方法はlong-pollともいうらしい。prototype.js でもひょろっと実装できるみたいだ。なるほどね。原理としては、ここの絵がわかりやすかった。
で、ここでふと疑問。long-poll なんて、どんなクライアント環境でも現実的に機能できるものなのかしら。タイムアウトにならないのかな。
タイムアウトについて調べてみると、RFC2616やら、その周辺解説やらキーワード辞書やらに当たる。

ほとんどのサーバでは、一定時間接続がないとその接続を切断するようなタイムアウト値を持っています。
(※) 例えば、Apache の場合、あらゆる初期値は “httpd.conf” という設定ファイルに記述されますが、そのうち「接続を確立してから最初のリクエストを発行するまでの時間」は Timeout、また「パイプラインを利用して、既に確立されたコネクションから次のリクエストを受け付けるまでの時間」は KeepAliveTimeout にて設定される値になります。

うーん、これはサーバ側実装についての話が殆どだな。RFCを見るに、Connection: Keep-Alive でリクエストした際、レスポンスに Keep-Alive ヘッダとして、タイムアウトまでの待ち時間や受付可能最大リクエスト数が返される、という感じらしい。
でも、このKeep-AliveってTCPレベルの話だよな.. TCPセッションをどんだけ効率的に再利用するか、という話であって、僕が知りたいのはブラウザの振る舞いなんだけど..
たとえば、ブラウザから(javascriptとかで) long-poll を発行したとき、ブラウザはずっと応答を待ち続けるんだろうか。勝手に再送したりしないんだろうか。このあたりがわかってないと、クライアントが応答待ちで固まったり(非同期に使うから、それは考えなくても良いのかな)、サーバ側に未応答のセッションが堆積したりという事態が発生すると思うんだけど。
で、ちょっと調べてみたが、なかなかブラウザ側の仕様についての一次情報は少ない。が、この辺この辺の議論、MSの技術情報を読む感じだと、ブラウザは30秒または5分というタイムアウト値(と見なし.. 再リクエストしたり、レスポンスを無視したりするのかな..)を持っていそうな気配だ。

「リクエストの送信を完了してから30秒以内に
ヘッダーを含む1バイトもレスポンスが無い場合は
リトライとして再度リクエストを送信する」仕様のようです。

Internet Explorer では、仕様により、サーバーからデータが返されるまでのタイムアウト時間が設定されています。タイムアウトまでの時間は、バージョン 4.0 および 4.01 の場合は 5 分、バージョン 5.x および 6 の場合は 60 分です。これにより、サーバーに問題がある場合に、サーバーからデータが返されるまで Internet Explorer が無期限に待ち続けることはありません。

30秒でヘッダを含めてまったく応答が無いと再リクエストする、というのは、本当なら危なっかしい仕様だ。long-poll が勝手に再発行されてしまうのではないか。
などと、見てるだけではいろいろ分からないことも多い。ちょっと手を動かしてみて、検証してみないとダメかな。
ちなみにサーバ側でレスポンスを保留(suspend)する部分は、HTTP処理のカスタマイズになるので、実装が厄介そうだ。Jetty6 だと、ここの実装をかなり簡便にしてくれるらしい。使ったこと無いけど、これを機会に試してみようかな。

Tagged with: