モテるAndroidアプリ開発

2012/9/30 3175hit

この内容はオープンソースカンファレンス福岡2011で喋った内容を元にメンテナンスを加えたものです。
モテるAndroidアプリ開発 Androidアプリ開発勘所

近況

Androidやたら売れています。
どれくらい売れているかというと
Gartner調べによれば8月は前年比倍以上の売れ行きです。

シェアでは6割を超えてスマートフォンのデファクトスタンダードとしての地位を固めつつあります。


さて、Android最大のプレーヤーはもちろんGoogleなのですが、
Googleは最近方向性を変え始めたように思えます。
そのキーワードのとなるのが
多方面展開からリソースの集中
いろんな新しいツールを沢山だすのではなく、ターゲットを絞って完成度を上げていくスタイルへ変化したように思います。
Googleは開発者向けとして、AndroidとChromeを二本柱として押しているように思います。
その成果としてAndroid4.0がリリースされました。

Android4.0はフルニューと言えたAndroid3.xモデルの実用版という感じ。
と言いつつ機能拡張は幅広いです。
カレンダーAPI
新しいUI部品
Low levelストリーミング用パスの提供
オーディオリモートコントロールAPI
新しいメディアタイプへの対応
グリッドレイアウト機能
OpenGL ES texture views機能
ハードウェアアクセラレータ2D描画のサポート拡充
新しい入力デバイスの対応
新しい入力イベントの対応
スクリーンショット機能
Webのパフォーマンス向上
メールアプリの改良
NFCによるAndroid Beam
顔認証アンロック
WiFiダイレクト対応
Bluetooth HDP対応
スマートフォンとタブレットの統合
Social API
Visual voicemail API
ホームスクリーンフォルダの改良
ドラッグでアプリの情報が見られる
プリインストールアプリの無効化
お気に入りトレイ
多機能なロックスクリーン
素早い電話へのレスポンス
スワイプによるアプリの終了
スワイプによる通知の削除
スペルチェック機能の改良
音声入力エンジンの改良
ネットワーク通信量の上限値設定
盲目・視力障害のためのエクスプラバイタッチモード
フォントサイズのカスタマイズ対応
ソーシャルと紐づく新しいピープルアプリ
新しいカレンダーアプリ
改良された通話アプリ
改良されたカメラアプリ
フォトエディタ機能付きの改良されたギャラリーアプリ
改良されたフォトギャラリーウィジェット
ビデオライブエフェクト
テキストサービスAPI
アクセシビリティAPI
テキストスピーチAPI
セキュアな証明書管理
アドレス空間レイアウトのランダム化
VPNクライアンとAPI
カメラポリシー(使用不可)の設定

スマートフォンにはAndroid3.xが適用されなかったためこれらの変化に加えてAndroid3.xでの変化もプラスされることになります。
参考
Android 3.0 Platform Highlightsを訳してみたよ
Android 3.1 Platform Highlightsを訳してみたよ
Android 3.2 Platformを訳してみたよ
Android4.1ではさらなる強化も行われています。
Android4.1で何が新しくなったか
これらの変化が目指しているものは
パフォーマンス改善、面白さへの転換、サービスを集約する、多環境で動く ことを目指しているように見えます。

パフォーマンスの改善はマルチタスクやGPUといったハードウェアを活用した仕組みに変わり4.1は驚くほどの滑らかさを見せてます。

面白さへの転換として、従来のAndroidにありがちな動けば良い という野暮ったさが触っていて楽しさを感じるように求められています。
トロン的なUIイメージへの統一や様々なエフェクト、アニメーション効果がプラットフォームのバージョンアップのたびに追加されています。

サービスへの集約は、1つのアプリで全ての機能を実現するのではなく、実現すべきサービスに対して複数のアプリが機能するというプラグインのようなスタイルです。
もともとAndroidはintentなどにより複数アプリがサービスのために連携するという仕組みがあったわけですが、APIの見直しなどによりOSが握っていた機能をアプリに展開するスタイルが広がっています。

他環境対応もAndroid登場時からのテーマですが、よりその幅は広がりタブレットやノートパソコン、さらには今後多種多様なデバイスで同じアプリが動くというスタイルが広がるものと思われます。
Androidで動くプログラムはJavaか? という議論は置いておくとして
JAVAはone write any runというキーワードを本気で実現できるのはAndroidかなと思ってます。
その一例がGoogleTV
バージョンアップしてHoneyCombベースになったことに加えてマーケットに対応し、スマートフォンのプログラムがテレビで動かせるようになりました。

しかし、その事は開発者に重大な課題を与えます。それが

多環境への対応

多環境への対応
one write any runのanyが増えれば増えるほど、開発者が考えないといけない要素は増えていきます。
全てのAndroidアプリで動くプログラムを書くのは大変ですが、その方法を考えていきたいと思います。

断片化を超える

大前提としてAndroidは当初より様々なデバイスで動くことを想定していて、そのための解決策が提供されています。
それを知ることで様々な端末の差を超えることができます。

dip(sp)指定

Androidでサイズを指定する時はドットではなくdipまたはspで指定します。
これにより、液晶のドットサイズとは関係なく現実のサイズを指定できます。
ユーザーにとってはドットより実際のサイズのほうが大事なことが殆どなので特別な場合を除いてdipを使用するべきです。
spはdipに似ていますが、ユーザーが設定した文字サイズによりサイズが変化します。テキスト周りやテキストと連動させるサイズにはspを指定すればフォントサイズの差を吸収できます。

原則標準UI

独自のUI部品を作ることは魅力的な操作感を表現するのに効果的ですが、標準UIはあらゆる端末で最適に表現されることが保証されています。
独自のUI部品の数を減らし、標準のUI部品をベースにカスタマイズすることで端末が変わっても問題が発生しにくくなります。

ステータスバー

Android3.0から採用されたステータスバーは単なるUIデザインの変更ではなく、画面の操作に関わる部分をプラットフォームに委ねるという重要な役割があります。
これにより、タブレットでは多くの部品を表示したり、ワイドテレビでは側面に表示したりと多種多様な端末によって最適なUIを提供できます。

9Path

9Pathは可変サイズの画像を作るのに重要な形式です。
9Pathを使えばテキストの中身によって変わるボタンとか、あらゆるドットの画面に適合する外枠を1ファイルで作ることができます。

要素を可変に 隙間を固定に

デザインしていると、ついつい、要素を固定にして余った部分を可変にしてしまいがちですが、
それはカッコ悪いデザインになりやすく、ユーザーのリソースを活用できなくなります。
ユーザーが大画面の端末を使っているときに沢山の要素を見ることができて、小さい画面の端末を使っている時は小さい画面にあわせて要素をデザインされるのと
大画面でも小さな画面と同じ要素しか見ることが出来ず、小さい画面の端末を使っているときに要素が画面をはみ出すのと
当然ユーザーにやさしいのは前者ですしデザイン的にも綺麗になりやすい



Fragment

Androidの多環境問題を英語でFragment(断片化)等と揶揄されていたのが、Googleが出してきた回答がまさにFragment
これはUIの塊や処理の塊を部品としてまとめ上げ環境ごとに使いまわせる機能。
例えばタブレットなら1画面にメニューと詳細を表示して、スマートフォンなら最初の画面にメニュー、次の画面に詳細を表示するような場合
メニューのFragmentと詳細のFragmentを作っておけばスマートフォンとタブレットではそれぞれ画面の遷移を変えるロジックを書くだけで済みます。
参考 Fragment

代替手段を作る

端末固有の機能に依存するのではなく、その他の方法で代替できるようにしておくと、特有の機能がなくても問題なく操作できます。
例えばタッチパネルがない場合のために、カーソルキーで操作できるようにしておくなどです。
操作方法や画面が全く同じでないといけないことを諦め、ユーザーの環境で最適に動くことを目的とすることで多環境化が容易になります。

断片化に潜らない

断片化を超える方法を紹介しましたが、そもそも断片化がある高さまで潜らないという方法もあるわけです。
例えばHelloWorld!のようなシンプルなアプリはそもそも断片化しない。断片化するのは相応に多機能なアプリです。
そこで、

アプリを多機能にしない

Andrdoidに備わった複数アプリ連携機能を使えば自分が作るアプリの機能をシンプルに保てます。
例えばカメラを撮影して編集してSNSに投稿するアプリを作りたいと思った場合、
カメラとSNS投稿は別アプリに任せて、写真の共有intentを送受信できる画像編集アプリにすれば、面倒なカメラまわりを触らなくていいですし、
ユーザーが使っているSNSに最適化され、新しいSNSはマイナーなSNSにも投稿出来るようになりユーザービリティも改善します。

ソレでもダメなら

断片化を超えない

ここまでのテクニックを使ってもダメな場合、対応機種を絞って断片化を超えることを諦めるという手もあります。
GoogleTVとスマートフォンではこれほどの異なる特徴があります。

それぞれの場合に応じて有効なアプリが変わるので、カーナビアプリをGoogleTV向けに出しても意味が無いですし、
家族で共有する黒板アプリはスマートフォンには向かないかもしれません。
なるべく多くの環境で動くのが望ましいですが、絶対に必要な機能は諦めるべきではないです。
それならいっそ範囲を絞ってしまうという手があります。
それによりリーチできるユーザーは減ってしまいますが、マーケットの評価を高く保つことが出来れば、実際にインストールされるユーザー数は多くなるかもしれません。

実際にGoogleはHoneyCombをスマートフォンを切り捨てタブレットのみで実行可能にしました。

MultipleAPK

MultipleAPKを使うことで環境に適したAPKをマーケット上で一つのアプリとしてまとめることができます。
タブレットに特化したAPKやスマートフォンに特化したAPKを作ることで断片化を超えるコストを抑えることが出来るかもしれません。
けれども、保守が面倒になるのと、不要なアプリを無理やり動かす理由にはならないことを注意してください。

そして最後に必要なことが

テスト

すべての端末で動かそうなんてテストは膨大なコストと労力が必要ですし無意味です。
明日以降発売の端末では動かせないので、すべての端末で動かすというテストは将来のユーザーを無視するのと同じです。
それよりは、特徴が大きく違う端末を幾つかピックアップしてソレで問題が出ないような作りにするという方がいいかと思います。
もし、それぞれの端末への最適化を行わずにGalaxyNexus、Nexus7、HT-03A、GoogleTVで動くアプリを作れたのであれば他の環境でも大きな問題が出ることは殆ど無いのではないでしょうか

前:Android4.1で何が新しくなったか 次:FireworksでAndroidデザイン入門 アイコン編 追記

コメントを投稿する

名前URI
コメント