2011年07月28日

Android Fragmentsの練習(with M3Navigator)

Android 3.0からサポートされたfragmentsフレームワーク。画面をいくつかの領域に分けて振る舞いを記述できるというもの。せっかくタブレット端末を買ったのに使ってみないのは勿体無いということで、ちょっと遊んでみる。せっかく遊ぶなら実用的な例題でということで、拙作のM3Navigatorをタブレット向けのUIへ移植してみた。

いきなり表示例。
fragments.png
左側にリスト、右側に詳細表示。この辺りはgmailの画面構成とかと同じ…というか、Android SDKのfragmentsサンプルまんまである。実際に、レイアウトや画面の遷移は大きくサンプルから流用している。

概論:意外と簡単。 既存のAndroidアプリをfragments対応するのは大変じゃないかとビビっていたが、実際のところ、タブレットっぽく見せる程度の改造はそれほど難しくなかった。ただし、MVCアーキテクチャ(モデルとビューとコントロールを切り分けようというUI設計の基礎論)に沿って設計することが大事だと思う。

レイアウト:条件付レイアウトフォルダを活用すべし。 タブレットっぽいUIの醍醐味は、傾けると変化するレイアウト。縦版と横版のレイアウトを作ることで、フレームワーク側でよしなにやってくれる。フラグメントを動的に切り替えていく箇所(上図右サイドとか)は、frameLayoutで仮のスペースを確保しておく。で、そこに生成したfragmentをアタッチする。

アクティビティの処理:フラグメントに移植、インテントの扱いに注意。 アクティビティのonCreateなどに書いていた処理は、fragmentの相当物に移動させれば大体うまくいく。ActivityやContextが必要な時は、Fragment.getActivity()を使えばよい。注意すべきはプロセス間通信。ActivityはIntentでやり取りするが、Fragmentの引数はBundleである。Intent.getExtras()を使って、中身のBundleだけを取り出してFragmentに食べさせればよい。

ビューの扱い:ビューの組み立てはonCreateViewでやる。 Activityでは初期化処理を全部まとめてonCreateに書くので、ちょっとコードの整理が必要かもしれない。

データベースの扱い:そのまんま。 とくに手を入れるべきところは無い。SQLiteもPreferenceも使える。

ボタンイベント:FragmentでListenerを継承、または無名クラスを利用。 無名クラスを使うとおそろしく捗る。直感的に理解しがたいが、インナークラスのコードからアウタークラスのメンバに触れるのだ。しかし、Cに慣れた身としては、メソッドの引数が納まる位置にクラス定義が鎮座しているのは落ち着かない。

あとは、メニューフラグメントとかも試してみたいと思う。そのうち時間をとってやってみる。

posted by yuji_at_radiance at 00:18| Comment(0) | TrackBack(0) | ソフトウェア | このブログの読者になる | 更新情報をチェックする

2011年07月20日

ABC2011Summer報告(カンファレンス)

前回の続き。午後のカンファレンスのこと。メモと消えかけの記憶が頼り。

■Session1:ロボットトラック:「ADKボードを用いたワークショップ」
アールティがOpenADKの概要とGoogle I/Oの様子を報告するという内容。 技術的に濃い話というよりは、ロボットの作り方とかリアルとクラウドのつなぎ方の持論が興味深かった。ADKのキモというのは拡張ボードそのものではなくボードとAndroidデバイスを結ぶプロトコル、特にボードと結びついたアプリやサービスをボード側が指定できることなのだという。ユーザやスマートフォンは、接続相手のことを事前に知る必要がなく、最初の接続時のネゴシエーションで全てが上手く行く。リモコンになったり、説明書になったり、デバッグコンソールになったり。
ロボットや家電の作り方のヒントとしては、スタンドアローンでもしっかり動くように作っておいて、Androidデバイスと接続した時にプラスアルファの機能・性能を発揮するという思想が大事とのこと。ネットワークに依存しないと何もできないロボでは意味がない。実際に沢山のデモを行った経験から出る言葉は説得力があった。
RT-ADK(open Accessory Demo Kit)についても説明あり。フレームワークとデモボードの名前が紛らわしいことについては、失敗だったとの談。4000円くらいで買える安価なモデルも展開する予定があるとのことで、試作品が会場に持ち込まれていた。
ADKの遅延については、体感的には100ms行かない程度とのこと。wifiと比べればずっと速いらしいが、Androidデバイスに制御系を入れてフィードバック制御するには遅い。ロボット側に(分散?)制御系を入れるなどの工夫が重要。先述の作り方ヒントにも繋がってくる。

■Session2:開発トラック2:「Linuxカーネルから紐解くAndroid」
アプリケーションフレームワーク(Javaのクラスライブラリとして見える部分)を支えるカーネルに着目しようという企画。セキュリティ、プロセス間通信、電源管理、メモリ管理について簡単な説明があった。生コードは残念ながら出てこなかった。
セキュリティ。これは、UID/GIDをアプリごとにユニークにつけるサンドボックス思想の説明だった。
プロセス間通信。Binderの話。先述のセキュリティより、アプリ間の相互干渉は困難である。ファイルシステムを介したやり取り以外に、Binderと呼ばれる仕組みがあるよという話。実はIntentを使う時にお世話になっているのだが、そのことはあまり知られていない。Unixのミドルウェアを移植することを想定してUnix的なプロセス間通信との得失を問う質問があったが、将来的な互換性とセキュリティの観点からAndroidの流儀に沿うことが薦められていた。ただし、Binderを生で使うのは技術的ハードルが高いとのこと。良い子はIntentを使おう。またはSocketを使うべし。
電源の話。WakeLockの話だった。
メモリ管理の話。LinuxではOutOfMemoryが発生すると立ち上がっているアプリがキルされるが、Androidでこうなるとまずいので、他のアプリをキルする処理が走るよという話。で、犠牲者を探す際には優先順位がきっちりと決まっているのだよ、と。サービスは優先度が凄く高くてキルされにくい。タスクキラー入れてもメモリ足りないと泣いている人は、サービスを乱発していないか調べてみるとよいだろう。「アプリの管理」→「実行中タブ」からサービスの起動数が見られる。

■Session3:開発トラック1:「アプリ開発・端末毎の解像度の違いを吸収する方法」
OpenWnnフリック対応版の中の人が講演。リソースディレクトリの上手な使い方と、ソツ無いレイアウトを作るコツの話。列挙すると、

  • 画像のオートスケールは避ける。ボケるから
  • 端末の最大解像度は今後大きくなるのだから、思い切って大きめに画像を作るべし
  • マニフェストにはminSDK=3(Android 1.5)とする。後方互換性のため
  • Project Build TargetのSDKバージョンを色々変えて動作確認する。最後に最新のターゲットでリリース版を作る。
端末の解像度やセンサの特性データベースが欲しいですとの談。対して、AndroidDeviceInfoShareというソフトがあるとのレスポンス。

■Session4:アカデミートラック:「MONAC・モバイルP2Pとクラウドを融合するメッセージングシステム」
継続的なネットワーク接続が困難な状況で通信の到達性を高める通信手法(DTN:遅延耐性ネットワーク)の実装。3G接続が制限された状況下でP2Pのメッセージ交換を駆使してインターネットへのメッセージアップロードを実現しようという技術の説明。震災に触発されたとのこと。 実は、クラウドサービスのユーザ認証を透過的に扱う仕組みがなおの事凄い。メッセージ交換アルゴリズムは、epdemic routingという、手当たり次第にメッセージを交換する仕組みなので、中継する端末に負荷がかかるらしい。課題は、インターネット側からDTNにデータをダウンロードする(持ち込む)技術の確立とのこと。活発に質問が飛び交った。

■Session5:アカデミートラック:「いま求められる、Androidのセキュリティ」
セキュリティ部の設立趣旨と、camellia for Android(暗号ミドルウェアの移植)の紹介、ウィルス対策ソフトウェアの是非を扱う紙芝居の3本立て。マルウェア対策については教科書どおりの話だった。

ラベル:android
posted by yuji_at_radiance at 00:08| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2011年07月19日

ABC2011Summer報告(バザール)

7/17に早稲田大学にて開催されたAndroid Bazaar and Conference 2011 Summerを観てきました。資料やメモを清書するついでに、webに残しておこうかなと。今日の更新分はバザールの話。順番は巡回した順。巡回先が偏っているのは仕様。書き始めたら分量が膨らんで終わらなくなってしまった。

■mbed部
mbedを使ってADK(open Accessory Development Kit)準拠のI/Oボードを実現するという企画。 何かイベントをやるときはGadget Cafeを中心に活動されるとのこと。 まだ、ボードの着脱→インテント→アプリの立ち上げの手順のどこかに不備があるらしく、 アプリがボードを認識しないとのこと。RT-ADKをプロトコルアナライザで観てみたいと言っていた。

■横浜支部・ロボット部、神戸支部・ロボ部
ひとまとめにしてごめんなさい。展示の棲み分けを把握できていませんでした。

  • ATTiny(とPIC?)でADK準拠のI/Oボードを作る
  • twitterと連携する、しゃべるロボ
  • ロボットハンド。スマートフォンの画面を指でなぞると3自由度(たぶんそれくらい)の腕を振る
  • クモっぽいロボット
ADKを駆使してスマートフォンから動かすロボを実現。悩みの種はスマートフォンの電池の消耗だとか(外付けIOボードはスマートフォンから給電する)。

■実機展示(主宰者失念)
Camangiの7inchタブレットを展示していた。まだ発売前なので調整が不完全とのことだが、良く動く。画面が小さい&解像度低いので、HoneyComb的に大丈夫かと思っていたが、特にストレスは感じなかった。HTC flyerのHoneyCombアップデートも案外期待できるかもしれない。

■Yamaha
担当の人が熱かった。Androidで電子楽器を作る際には、タッチ→音出力の遅延が重要になってくる。その遅延を縮める技術の説明を2つ。一つはADKを使ってarduino MIDIシールドからMIDIを出力、MIDIの機材で演奏するというもの。もう一つは、HW音源と改造カーネルで音を鳴らすというもの。IS03に入っている(たぶん着メロ用)音源チップを叩いて音を鳴らしていた。カーネルを改造して、midiを扱うjavaクラスライブラリまで作ったとのこと。
また、参考展示として、米国miselu社が企画中のandroid搭載電子ピアノのモックを紹介。 オンラインセッションとかそういう時代が来るのだろうか? 以前のCEATECで、ヤマハがネットワーク接続できる電子ピアノを参考出展していたことを思い出した(参考リンク:インプレスBB watch)。

■ガイガーカウンター(主宰者失念)
浜ホトは職人芸でしたねーと雑談。安価に量産できるGM管のデザインを作成したらしいが、工場のオファーは今のところ無いみたい。

■TechBooster
AndroidのプログラミングTipsを掲載しているサイト。 9月中旬に「Android タブレットアプリ開発ガイド」を出版するらしい。 Android3.2にも対応との事。努力してますね。でも、3.2でAPI仕様ってそんなに変わったかな。

■スマート・ドライブ・メーター製作委員会
加速度センサを使って道のバンプの高さを検出するソフト。 実際に東北地方を走って、高速道路の歪みを測定したというから恐れ入る。 原理は加速度の二重積分だが、累積高度を取るのではなく、一定時間内の高低差を求めているようだった。 測定精度は中々だが、もう少し頑張れそう。 積分値をとる計測区間の選び方を工夫するともっと正確になるんじゃないだろうか。

ラベル:android
posted by yuji_at_radiance at 00:13| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。