羅針盤制作秘話 第6回

By akane
このエントリをはてなブックマークに追加このエントリをdel.icio.usに追加このエントリをLivedoor Clipに追加このエントリをYahoo!ブックマークに追加このエントリをFC2ブックマークに追加このエントリをNifty Clipに追加このエントリをPOOKMARK. Airlinesに追加このエントリをBuzzurl(バザール)に追加このエントリをChoixに追加このエントリをnewsingに追加

羅針盤制作秘話 第6回。
今回は、各機能の切り替えをおこなうリボルバーと、
水平器(カメラモード)の開発を行った
岩村氏の話をもとに記事を作成しました。


——-

各機能(ランドマーク、星空、コンパス等)を切り替えることが役割であったリボルバーメニューでは、
ActivityStackの動きを正確に理解し、それをコントロールする必要があった。

基本的にAndroidアプリでは一機能をActivityという単位で構成する。
Activityは1つ以上のView(画面)を保持しており、
ユーザにはこのViewを画面として表示する。

普通にアプリを作れば、画面が開かれる度に
OSによってActivityがスタックに詰まれ、
画面が閉じられるとActivityがスタックから消される。

【状態1】
HOME <= 表示中

【状態2】
Application1(Activity1) <= 表示中
HOME

【状態3】
Application1(Activity2) <= 表示中
Application1(Activity1)
HOME

【状態4】
Application1(Activity1) <= 表示中
HOME

【状態5】
HOME <= 表示中

画面遷移が複雑だとこのActivityStackを
意図的にコントロールする必要に迫られるのだが、
OSは予想とは違う動作をする場面が多々あった。

一例を挙げると、上記(状態3)のときにAcitivty1が大量のメモリを消費
していたならばOSが勝手にActivity1を削除する。(状態4)に
なるときに改めてActivity1を作成する。といった挙動をする。

このような例外的動作を洗い出すため、
様々なケースをテストし、どのようなタイミングでどのような
コールバック関数が呼ばれるのかを調査する必要があった。
デバッグプログラムを作成するなど、オンラインドキュメントからは
分からない情報を整理するために、岩村は少し手間取ったという。

当時のAcitivtyStackの設計は困難を極めていた。

これ以来、機能はなるべくApplicationレベルで分離し、
ActivtyStackはシンプルに設計するべきかもしれないと思うようになった。
Applicationが別であっても
それぞれが協調するための仕組みはAndroidOSが十分に用意しているためである。

話を変えて、次に水平器の開発について述べる。

水平器(カメラモード)において、
カメラで写した映像を背景として表示することは、
オンラインドキュメントでサンプルコードが紹介されていたため難しくはなかった。
方位やピッチについても三角関数を使えば単純に描画できた。

suihei

岩村が難しいと思ったのは、カメラでの撮影機能だった。
参考にしたのはAndroidOSに最初から組み込まれているカメラアプリの実装である。
アプリから制御できるのは撮影開始をOSに指示するだけで、
そこから先の撮影処理はOS以下のレイヤーで行われていた。

アプリから出来ることに対し色々と限界があった。

しかし、Androidが提供するカメラ撮影のAPIは、
コールバック関数が多用されているものの、
アプリ開発者が実装するべき部分と、
OS以下が実装するべき部分が明確に分けられており、理解しやすかったという。
APIを考えること、如いては関数一つを作るにしても、
そこには使う側を意識した意図を感じとることができる。

この開発を通し、岩村はAndroidについてこう思ったという。

Androidが提供するフレームワークは、
他のプラットフォームでは見られない思想が数多く詰め込められており、
その一貫性はすごい。
AndroidOSやそれにプリインストールされているアプリの
ソースコードは一部オープンソースとして公開されており、
誰もがそれを見ることが出来る。
これらは出版されているどのAndroid関連書籍よりも、
参考になるし、Androidを勉強する上では、ベストな教材で
あることは言うまでもない。

——-

(次回 羅針盤開発秘話 第7回は6月4日(金)投稿予定です。
プロジェクトマネジメントについて、PMを担当した矢吹氏に話を伺います。)

関連する投稿