Just another blog for akaiho.com
akaiho St. » Archive of 'Apr, 2009'

Live FolderやAppWidgetで見えてきたAndroidに込められた狙い No comments yet

Android 1.5に搭載される「Live Folders」とは
http://japan.cnet.com/mobile/story/0,3800078151,20392373,00.htm

1.5から実装されたものにLive Folder、AppWidgetなどがあります。これらを実際に使ってみると見えてくる、Androidの方向性のようなものがどことなく感じとれます。

Live Folderは、Home画面にFolderのようなアイコンで置いておけるショートカットなのですが、それ自体は例えば「全てのcontacts」、「電話番号のあるcontacts」、「スターしてあるcontacts」(contactsは連絡先。Androidにプリセットで入ってる連絡先アプリで、Gmailのconatcsと自動的に同期する。)などと、ある絞り込みをした状態で一覧を出す、といった条件付けをしたリストを表示できます。
これの正体は実はContent Providerです。Androidには、Content Providerという、Androidに組み込まれているデータベースであるsqliteを使うためのクラスがあるのですが、これはパーミッションを設定することで、そのテーブルを作ったアプリケーションに限らず、他のアプリケーション間でデータを共有することができます。
Contactsアプリは、Content Providerで連絡先データを共有できる設定になっているため、自分で作ったアプリケーションでもContactsからデータを取得してくる事が可能です。
そして、このLive FolderはContent Providerにあるデータを拾ってくることができるため、これを利用して共有されているデータをただ表示することもできれば、ある一定の条件を満たすデータのみを絞って表示することもできるというわけです。(SQL文のわかる人なら要するにselect文だということはわかるでしょう。)
こういった形で、すぐに呼び出したいデータをいちいちアプリを起動しなくても先にデータ一覧だけ表示し、そのデータを見るだけで済むならそれで楽ですし、そこから何かをするならその一覧からアクションをするといった事もできます。例えば、良く連絡する友人だけど名前の漢字がわからないなどといったときは、スターしたcontactsを見れば済むというわけです。Contactsアプリをいちいち起動しなくて良い。それでもし、その人に電話する用があるときは、一覧から名前をタップすればDialアプリが起動して電話をかけられます。

ShortCutも似たような機能です。私自身は、Gmailラベルのshort cutを使っています。 これは特定のラベルの付いたメールを直接表示する形でGmailアプリが起動します。いちいちinboxに行かずに設定したラベルの付いたメールを開くので、Gmailを起動してMenuからラベルを指定して…と行ったアクションをとばせるわけです。

App Widgetは、Google Gadgetなどと同様に、アプリの一部分を切り出したものをHome画面に置いておくことができます。これは使いように依っては非常に便利。今回の1.5よりデフォルトで入った、カレンダーのwidgetは、Home上に日付と、GCalに登録してあるその日の予定を表示できます。タップすればCalendarが起動します。

これらの機能によって、ユーザーはよりシームレスに端末内の情報を取り出せるようになったといって良いでしょう。 contactsを見るには基本的にはContactsアプリを起動しなければいけませんでした。大して重いアプリではないです。ただ、その一手間を省いているわけです。特定のラベルのついたメールを見るには、Gmailを起動してラベルを選択して…というステップを踏む必要があったのですが、それもショートカットできるようになりました。widgetによってHomeに常に表示しておきたい情報は表示させておくことができるようになりました。
アプリケーションとHome(待ち受け画面)の垣根、そしてアプリケーション内のデータとHomeの垣根も下がりました。Widgetで、アプリケーションの起動さえほとんどしなくて済むかもしれません。

さらにAndroidにはIntentというクラスがあり、これによってアプリケーション間の呼び出しやその際付随させるデータのやりとりを統一化しています。 Androidでは、画面全体を使うアプリに関しては基本的に最低一つ以上のActivityというクラスによって成立しています。Intentを発行することで異なるActivityの呼び出しを行うのですが、そのActivityは必ずしも自分の作成したActivityである必要はありません。 つまり、呼び出したいアプリがどのようなIntentを受けとるのかを把握してさえすれば、自分のActivity(アプリ)から他のActivityの呼び出しが、ただの画面遷移のように行うことができます。

Androidにあるデータはなるべく共通化して使えるようにし、見かけ上は(ユーザーからすれば)アプリケーション毎に明確な壁がないかのように見せています。(セキュリティが気になる人もいるでしょうけど、内部的には各アプリケーションは全て別プロセスで動作しています。データも明示的に共有許可していない限りはアクセスできないため、安全性の面でも配慮はされています。)Android端末に入ってるアプリケーションはAndroidの他の機能と溶け合うかのように一つになることで、端末の機能が追加されていくようにしています。

データとアプリケーションは緩い結びつきにしておき、データだけを自由に取り出せるようにし、アプリケーション間の往来も、より自然に見せることで、端末自体を「たくさんの独立したアプリケーションの入ってるデバイス」ではなく、「アプリケーションの追加は、端末の機能の追加」と位置づけているようです。
ユーザー側からすればこれは違和感もなく、むしろ本来そうあるべきだったのではないかとさえ思わせるくらいです。 あっちのアプリに入ってるデータをそのまま使ってくれればいいのに、と思うような場面はPCにしろケータイにしろ、良くあったと思います。そこに一石を投じたということでしょうか。

Google Buzz

Android SDK update(1.5r1)とdevPhone imageもupdate No comments yet

今回はdevPhoneのイメージも同時にupdate来ましたね。
で、早速dev phoneをupdateしてみたい方も多いと思います。

http://www.htc.com/www/support/android/adp.html

基本的に上記HTCのページに書かれている手順通りに行えば良いです。
ものすごく簡単に書くと

radio image (ota-なんたら.zip)

recovery image(signed-dreamなんたら.zip) をダウンロード。

端末をUSBでPCやMacに繋ぐ。adb devices などでちゃんと認識されていることを確認。
adb push <radio image file> /sdcard/update.zip
でradio imageを端末のSDカードへ転送
転送が終わったら adb shell sync などで転送が本当に終わってるかどうか確認。

端末を再起動。HOME(家のアイコンボタン)を押しながら再起動させて、「!」マークの出てる画面が出るまで待つ。
出てきたらキーボードを開いて ALT + l(エル) キーでログを表示させる。
ALT+s で update.zipをインストール(しばらくかかります)
終わったら、 HOME + BACK(矢印アイコンボタン)を同時押しすることで、インストールしたイメージを書き出してreboot。

無事にHome が起動したら、
adb push <recovery image file> /sdcard/update.zip
と、<radio image file> だったところを<recovery image file> に差し替えて同じ手順でもう一度繰り返す。

最後まで行ったらOK。

ところが、実はここで公開されている1.5 imageは、locale がEnglishしか入っていません。全体を日本語で表示することはできません(もちろん今までどおり、webやアプリケーション内での日本語表示はできます)。 ソフトキーボードなどは実装されていて使うことはできますが、IMEもないです。

そしてGoogleの某氏いわく、「(このdev phoneの公式のイメージに、今後English以外のlocaleが入ることは)まず、ないだろう。」とのこと。

うーん…。

Google Buzz

AppWidget frameworkが実装されました. No comments yet

公式(英語)の方にも書かれていますが、先日のAndroid SDK 1.5 early lookより、実際にHome Screen上のWidgetsの開発が可能になっています。今までだと時計やフォトフレームなど、数種類のプリセットだけでしたが、今回より自作のwidgetをHomeに置いていくことが可能です。もちろん、既に作成した自分のアプリのインターフェースとして使うといったことも可能です。
ミュージックプレイヤーの曲情報表示やコントローラーとして使う例もありますね。

ss

公式のサンプルとしては Wiktionary “Word of the day”をServiceからWiktionary APIを叩いて表示させる、というものが公開されています。
http://code.google.com/p/wiktionary-android/source/browse/#svn/trunk/SimpleWiktionary

いくつかコツがあるようで、解説されています。

  • XMLでwidgetのメタデータを定義する必要アリ
  • Home screenはセルベースのレイアウトのため、メタデータで指定した値の近似値のセルサイズに補正される

なお、セルは

Minimum size in dip = (Number of cells * 74dip) – 2dip

という式で算出できるとのこと。
つまり、横に2セル、縦に1セルのwidgetを作りたい場合、

<appwidget-provider
    xmlns:android=
    "http://schemas.android.com/apk/res/android"
    android:minWidth="146dip"
    android:minHeight="72dip"
    android:initialLayout="@layout/widget_message"
    android:updatePeriodMillis="86400000"
    />

となるようです。

さらにサンプルではBroadcastReceiverをwidgetで受け取るための設定などをAndroidManifestに記述、そして実際のJavaコード(Service)の一部まで解説されています。
注意点として、便利だからといってあまり頻度の高いupdateをwidgetにしないこと、なぜならそれをするとあっという間にバッテリーを食ってしまうため、という点を上げています。
これは、Serviceの利用においても同様のことを何度も言っていますね。

サンプルとして公開されているSimpleWiktionary はソースも非常に短いので、Androidプログラミングを既に始めてる人ならすんなり読めると思います。

ともかく、非常に要望が多かったAppWidget frameworkがついに解禁となったのは嬉しいですね。

Google Buzz

講演するとき No comments yet

環境が想定外の事態(機材トラブルなど)に陥ったとき

慌てて黙々と対処するのが三流
慌てず対処しつつトークで場をしのぐのが二流
そもそも想定外などないほどに準備しておくのが一流

だそうで。

サーバーとの通信が前提ならローカルサーバも用意しておく
PCトラブルのために予備のPCも用意しておく

だそうで。

勉強になります…!

Google Buzz

OpenSocial Hackathon in April No comments yet

来る4月24日に、OpenSocial-JapanがOpenSocial Hackathonを開催します。gooホームも先日、OpenSocialのSandboxを用意し、且つ公式よりも充実してるドキュメントと評判も良いようです。これを機にOpenSocialガジェットの開発を手がけてみてはいかがでしょうか。 場所はリクルート メディアテクノロジーラボです。
詳しくはこちら。

なお、よういちろうさんとえーじさん(Google API Expert仲間です。お二人はOpenSocialでボクはAndroidと、担当は違いますが。)が先日より技術評論社さんのサイトでOpenSocialガジェット入門の連載を開始してます。
OpenSocialを利用してガジェットを作ろう!

参考にどうぞ。

Google Buzz

Androidで物理エンジン 1 comment

最近android developersでホットだったのが2D Physics、いわゆる2Dで使う物理エンジンに関してです。AndroidのアプリケーションはJavaのsyntaxを採用しているため、Javaベースで構成されている物理エンジンならば、ライブラリ周りさえ解決できればそのまま動くはずですね。(とはいえ、そのライブラリ関係で問題が出ることが多いわけですが。)そこで、Phys2DやJBox2Dを使用したものの、パフォーマンスが思わしくないんですけど…というトピックが発端で、色々な議論やテストが行われています。

JBox2Dよりももっとよく動きそうだということで、 simpull というエンジンが挙げられていました。議論の途中から作者も登場してきましたが、Android上で自分でsimpullを動作させたときのパフォーマンスには満足できなかったようです。だいたい10オブジェクトぐらいまでなら移動とコリジョンはOKだった、とのこと。やはりGCが問題になるらしく、Android用のパフォーマンスチューニングしたエンジンにしないことには、どの既存のエンジンにせよ、きっとまともに使えるものではないだろう、との結論に至っています。

さらに、Antonさんが趣味でAndroid用のチューニングした物理エンジンを制作中で、それを使ったデモを公開しています。 http://www.antonstoys.com/android/BallPit.apk

かなりよくできているように見えますね。浮動小数点演算とメモリアロケーションをメインループからざっくり外したようです。エンジンのコアの部分をC++(Native)で記述しているとのこと。

そして、今度はKelemenさんが「私もJBox2Dのパフォーマンスにはがっかりしたので、APE (Actionscript Physics Engine)をJavaに移植してみている」とのことで、プロジェクトごと公開してます。 www.kotiposti.net/lkelemen/android/testape2d.zip

Androidはせっかく加速度やコンパスなどのセンサーが簡単に使えるので、それと画面上のオブジェクトを連動させる意味でも、計量で高速な物理エンジンに寄せられる期待は大きいですね。

(ちなみに。apkのインストールは、実機で直接そのURLを読みに行けばインストールしようとするはずですが、Settings -> Application -> unknown sourceをチェックしていても、うまくいかないことがあるようです。
なので、開発環境がある人(SDKをインストールしている人)でしたら、AndroidをUSBで繋いだ状態で、普通にPCやMacのブラウザでapkをダウンロードした後、apk install をした方が簡単だと思います。)

Google Buzz
Top of page / Subscribe to new Entries (RSS)