11/08/2012

[&] Android App Designs (omnibus)

Android App Designs (omnibus)
デザイナーがコードから読み解く
Androidアプリのデザインの幅を広げるコツとTips
http://goo.gl/zZWMG





@tommmmy

4回やってきて、今回が5回目。最後の総集編です。
これまで4回やってきた、Android App Desings というイベントでした。
結構たくさんの人に来ていただけました。
参加者内訳は、開発者が6割強。残り4割弱がデザイナー。

デザイナーズハックとうデザイナー中心のコミュニティを細々とやっています。
7月に大阪から引っ越してきたばっかりで、まだなじめていません.....

サブタイトルが
「デザイナーがコードから読み解く、
 Androidアプリのデザインの幅を広げるコツとTips」

がんばって作ったデザインが、実装後に残念な結果にならないために。
残念になる理由
B. エンジニアがでザインのことをわかっていない
A. デザイナーがAndroidデザインの基礎を理解していない

P.11
よくある話としては.....
P.12
余白が少ない。のが見て取れます。
元のデザインは綺麗につくっているのですが....

P14
白い線が入っているデザインなのに、入っていない。
影がなぜか無くなっている。
テキストにエンボスをかけているのに、無くなっている。
グレーの線の上にハイライトの線を入れているのに、無くなっている。
けっこう細かいところは、デザインしている人じゃないと、
なかなか気づかないと思うし、間違い探しと一緒。
こういうことって、結論からいうと、エンジニアが気をつけてさえくれれば、
残念なことにはならない

残念になる理由。
A. デザイナーがAndroidデザインの基礎を理解していない
むりやり押し付けてもダメだな〜と思って。
デザイナーにXMLコードを勉強して欲しい?
別にそういうことではない。
エンジニアにデザイナーを分かってほしいということでもなく....

コードからつかんだデザインのコツ。
デザイナーが知っておくと、エンジニアもデザイン実装がしやすくなる!

なかなか人が居ないとか、情報が少ないとか。
デザイナーにXMLを勉強してほしいとか、もありますが。
自分が実装しやすいように、デザイナーに仕込む。
自分が実装しやすいデザインレギュレーションを決めておいて共有すれば良い

どうやって簡単に?
たぶんデザイナーに [ dp ] とかいっても受け入れてくれないと思う
デザイナーさんの身近な言語に翻訳して伝えてみる。ピクセルとか。

裏テーマ
「デザイナーさんにわかりやすく興味をもってもらうために」
興味を持っていただくのを今日の裏テーマとして。

アジェンダ:
デザイナーさんにわかりやすく興味を持ってもらうための5つのポイント
効率的な進め方
Android App Designes アンケート結果の紹介

P.25
デザイナーさんにわかりやすく興味をもってもらうための5つのポイント
 自然に責める
壁を突破するためのきっかけになるとうれしい

1. -----------------------------------------------------------------------------
640 px x 1066 px
720 px x 1280 px
作成するデザイン案のサイズ。

ガイドラインは dp なので、そこでわからなくなってしまう。
なので、あらかじめピクセルに直して考える。
xhdpi で作る
 320 dpi といういちばん大きな画面密度で作る
 1dp = 2px なので計算がかんたん。
 320dp と 360 dp の 2種類あるのだが...

なぜ2つかというと、確認する端末によって、分ける
 ... といいんじゃないかと思う。
Android Design Preview デザイナーにとってうれしいツール。
パソコン画面をそのまま Android 端末に映すことができるツール。
http://code.google.com/p/android-ui-utils/downloads/list

320dp と 360dp これを 640px デザインしたものを表示させると、
Galaxy Nexus で見た時に、ちょっと大きめになってしまう。
逆に 720px でデザインしたものを表示させると、
320dp で見た時にちょっと小さく感じてしまう。

ぴったりに見せたい時は、デザイナーさんが持っている端末にそって
サイズを決めておけば良いと思います。
これでもしやってみて、いいこと悪いことあれば、教えてください!

2.-----------------------------------------------------------------------------
96 px と 4の倍数
各要素を決める数値です。
96px にすると、要素がぴったりあいます。
4の倍数は、ガイドラインで指定されています。主に余白です。
ピクセルに直すと、8の倍数です。
デザインしていくなかで8の倍数はけっこう大きいです。
細かいところは 4の倍数でいいんじゃないな〜と考えています。
いろいろ考えてみると、

P.43
xhdpi で 4の倍数をとると、hdpi でも整数になっています。
私の持論です。実装も綺麗になるので大丈夫です。

3.-----------------------------------------------------------------------------
伸縮幅・固定幅
横幅は原則2種類。
どこが伸縮/固定なのかをはっきりさせる
640px で作っていたら、720px のときにはどこが伸びるのか
余白はどちらの時にも固定値にする。

P.48
どっちかを作って、どこが伸びるのかを明示しておくと、
エンジニアさんに伝わりやすい。
P.50-52
これは何を意味しているかというと、
どこが伸びるか?どこが何ピクセルかを示したものです。
これはこれでデザイナーはちゃんと計算してデザインしています。
オレンジのところが、伸びるところ、または縮まるところです。

P.53
ボタンについては、1:2 の割合になっているので、
伸びたりしても、バランスが保たれます。

4.-----------------------------------------------------------------------------
9-patch
これは第1回、4-50分かけて、説明しました。
画像をのばすテクニックです。
画面サイズはデバイスによって違うので、
必ず伸縮を考えないといけません。
P.57
まず、画像を9分割して、四隅はのばさない。その他の部分を
伸びてもいいようにして、びよーんと伸びる設定にします。

世界で一番わかりやすい 9-patch の説明です!
P58〜
周りに1ピクセルつづ、余白をとります。
黒い点を打ちます。(P60) 切り取ると、(P62)
みよーんと伸びます(P63,64)

P72
このデザインに関しては、同じ。
グラデーションを扱った場合、9patch は注意が必要。

P73〜P93
結果が微妙に違う!
色味が近い場合、荒いグラデーションになってしまう場合があります。
角丸が終わるギリギリの場所で2箇所指定した場合.

もっこり感が微妙に違います!
光の具合を計算しているので、変なところが伸びていると「残念だ」と
思ってしまう。デザイナーもどこが伸びるのか指定してあげてください。
エンジニアも、伸びすぎて気になる場合は、デザイナーに確認してあげてください。
両者の心遣いが大切です。

ボタンで使う場合が多いと思います。
どこが伸びるかを指定しよう。
個人的には、グラデーションがある場合は、9patchはあまり使いたくありません。

してもらってうれしいこと。
デバイスで見るとどう伸びるのかを、一緒に体験する。
Draw9patch というツールが、デザイナーのPCで動くようにする。
慣れてきたら、Photoshop でも作るよ!
設定してあげたら、けっこういい 9patch が出来てくると思います!
Draw9patch のツールのコマンドを、ドックに入れてあげるといいです。
(Unix コマンドなので、開いたら、爆発してしまうんじゃないかと思う!)
Mac に Automater でパスを指定して開けるので。やりやすくなります。
やりはじめるとハマると思います。

5.-----------------------------------------------------------------------------
矩形 shape タグ。
CSS3 でグラデーションとか、角丸とかできるようになったのと
同じようなことができるので Web デザインをする人なら取っ付きやすいです。

コードで書ける矩形のことを知っておこう。
特にコードの書き方は知らなくてもいいと思います。
コードで書けることを知っていれば、それなりに綺麗なものが仕上がってきます。

P103
Rは角丸の半径。ボーダーも指定できます。
スタートカラーと、エンドカラー、センターカラーも指定できます。
デザイナー的には、センターカラーが変えられるのはあまりうれしくありません。
こういう光り方をしているボタンはあまり作りません。

P105
Photoshop でグラデーションを作っているところ、上70%くらいに
変化のポイントを打つことは良くありますが、真ん中にすることはあまりありません。
あ、残念だ... と思ってしまう。
グラデーションの場合、コードで可能なものか、9-patch になるのかを考えておこう。

まとめ-----------------------------------------------------------------------------

1. 640x1066, 720x1280 (px)
2. 96px, 4の倍数
3. 伸縮幅/固定幅
4. 9-patch
5. 矩形 shape

これまでまとめてきた上で、デザイナーに押さえてもらえると
ずいぶん楽になる5点です。
ぜひ広めてください!
詳しい資料を、別にまとめようと思います。

-----------------------------------------------------------------------------
後半
http://www.slideshare.net/toooommmmmmmmy/4androidtips-15080493/110

ちょっと実装とは関係ないんですが、
XMLの実装をめぐる、効率の良い進め方を再考してみたいと思います。
いままでやってきた中で紹介していきたいと思います。

アプリケーション作る時に、だいだいワイヤーフレームみたいなのを
作ると思います。エンジニアはフローチャートとかで仕様を決めておいて、
そこからデザインに入ったりすると思います。

P111
カンペを出すアプリです。
セミナーとかやっている時に、後ろからメッセージを送るアプリです。
ワイヤーベースのモックをまず作ります。
で、ここからデザイン、実装に入る時に.....

#ここで寸劇....
エンジニアの人が「一週間でお願いね!」
デザイナー「オッケー」

初めてデザインする人とかは、実装できないデザインを出してくることがある....

こういう場合、
 ワイヤーを決める
 デザインをデザイナーにまかせる
 なかなかできあがってこない
 デザインが無いと実装できない....

P126
エンジニアが、デザインの待ち時間がもったいない。
モックを作ったりとはするとは思うのですが.....
なので、
 
 同時進行!

ワイヤーさえ決めればあとは同時進行
いっかい、これをやって、気分が晴れ晴れしました!

#再び寸劇
P128-
P131
エンジニア:いわゆる葬式UIが出来上がってきました。
 いい意味で、デフォルトだけのもの。
P132
デザイナー
ワイヤーがきまっているので、そうそうずれていない。
ボタンの位置とか設定されているので、
画像を張り込むだけで良かったりするので。
すごい工数も少なく終わりました。

P.134
配置とか画像とか変えてもいいので。
ちなみに、これ、自分でデザインを作って、
ここから、XMLを実装したものなので、ちょっとしょぼいのですが、
結構気に入っています。
アナログ感をどうしても出したかった。
逆にひんそに見えるかもしれませんが。

デザイン実装した分、これも 9patch でやっていて。
アナログなアプリにしてみました。
 アプリは公開していないので、ここだけで見られるものです。

同時進行のメリット;P136
 デザインと実装を同時並行。
 設計、ワイヤーの時間をとれる。
 ちゃんと設計をしておけば、だいたい同じようなものが出来上がってくる。
 XMLのスタイリングを最後にする。
ワイヤーさえかわらなければ、最高の効率!
すごく楽しくできました。

デザイン例:P138
shape を知った上でのデザイン
shape タグで出来ることを知っていれば、それに見合ったデザインができます。
それの例を紹介します。
「カンペ君」アプリをぱっと見ていただいて、綺麗でシュッとしているように見えます。
ほとんど shape タグで実装しています。
ボタンみたいのも、全部 shape です。
先ほどのグラデーションあったかと思うのですが、全機能使ってます。

P.143
遠隔の端末でも同じメッセージが表示されるというアプリの機能です。
押せるところと、押せないところがあります。
押せるところは、赤い○で囲んであるところ(P144)
押せるところは盛り上がって押せるように見えるように作ってあります。
押せないところは、すでにへこんでいるように見えるように作ってあります。

例えば、P146 エンジニアがどう実装するかは分かりません。
私が XML の shape を分かっていで、デザインしたら、こういう形にしました(P147)
P148 綺麗に見えると思いますが、shape で作っています。
グレーのグラデーションに角丸です。
P150 send ボタンも同じです。
画像にshadowを入れています。
9patch で画像を作るよりも楽です。
いちいち photoshop で作り直さなくても良いので、その方が楽です。
shape で作れる範囲で思いっきりやろうかと。
画像使えば綺麗になるというわけでも無いので。

もう一個。こだわっているところがあって。
一番上、P151
背景に若干ノイズ、テクスチャが載っています。
ちょっと柔らかさを出したりするために、ノイズが載せたいんです。
実装どうやるかといった時に、
ボタンなら、画像を切り出しせばいいのですが....

どうやったら実装できるんだろうと、考えました。
P152 実際に実装した画面です。
結構いい感じに、少し薄いですが、まあまあいい感じにノイズが載っています。
ただ、実装した結果どうなっているかというと、
じゃっかん、角丸からはみ出ているのがわかります(P153)
これ、何をしているかというと....
P154 この場合、上からノイズの画像の透明度を10%-15% にしたものを
グラデーションの上に載せると、ノイズがかかった綺麗な画像になります。
shape とビットマップをレイヤースタイルを使って重ねています。
ノイズをなんとか表現してみたい。P155
今日までに解が見つからなかったので、教えて欲しい!
角丸でくりぬく方法があれば、教えてください!

●綺麗にデザインするためには
デザイナーが数少ない表現方法でもしっていれば、
それなりに組み合わせて綺麗なデザインを作れる。
こういうの出来るよというのをエンジニアが示してあげれば、
デザイナーは綺麗なデザインをしてくるので、それを信じて実装してあげてほしい。
残念になるのは、両方が勉強不足、コミュニケーション不足。
コードを知らなくてもちゃんとする方法を教えてあげるといいと思います。
これから資料としてまとめていければいいな〜と思っています。

Q&A

Q: shape の話で、ボタンが盛り上がっているのと、へんこんでいるのの違いが
わからなかったのですが....
A. 押せるところは、上の方が薄い色になっています。
 押せないところは、上のグラデーションの色の方が下よりも濃くなっています。
 光の当たり具合ですが、上から光があたっている時、膨らんでいると、上の方が明るくなります。
 へこんでいると、影になって、色が濃くなります。なので、こういう風にみえるように。

Q: デザイナーとデベロッパーの連携で聞きたい。
 デザイナーが5枚くらいカンペを作って、テキストサイズをまとめてシートを作って、
 18pix です。とか、カラーチャートを作って、ボタンのパーツの色を伝えたりしていました。
 実際にやる時に、どう伝えているのか?教えてほしい。4px とか。
A: 実際は XML を書いてわたしています。仕事としては「脳内」です。
  デザイナーからエンジニアに色の指定とか、テキストの指定をしているのか?
  山本さん「どうやってデザインのパーツを全部切り出して、パワーポイントで、
  全部の画面にぺたぺた貼付けて、パーツは何、カラーコードは何とか、
  そんな感じで全てのパーツに、全部つけてお送りしています」
  すごい丁寧だと思います。私だったら、自分でやっちゃうと思います。
  やり方は色々あると思います。
  変数化するよりもまとまっている方がいいですね。

Q: shape ボタンを作られるさい、
 プレビューをうまくやる方法。
A:

Q; 色の指定というのは RGB というのは255 255 255と 16進数とどちらで指定するのが良いのでしょう?
A: 16進数の方が喜ぶと思います。

Q; Nexus 10 とかタブレットとか?xhdpi の範疇に収まるものなのか?
A: 足立さん:xhdpi の高解像度になります。xxhdpi が出てくるので戦々恐々としています。

--------------------------------------------------------------
Android App Designs アンケート
日々の見えない声

P161
デザイナーとして同感で、
こういうことがいっぱいあるので、自分でやるようにしました。
なんで相談しないのか、疑問でした。
もっとコミュニケーションとって欲しい。
足立さん:そんな時間が無いんですよね。1ピクセルくらいっか〜
      ここは絶対譲れない部分と、実装が難しい部分を分かってもらうと。
ぜったい崩して欲しくない部分を明示しておくと、大丈夫かもしれない?
足立さん:素材を綺麗に切り出してもらえば大丈夫です。
    みんな1ピクセルの問題はあるんですかね?

dp で 0.66 dp とかありですか?
足立さん:無し。書けるけど、そういうこまかいことよりも重要なことがある。
     書けるけど................
1px のライン、72dpi のパソコンの解像度の 1px と android の 1dp ってちょっと
太くなってしまう。
0.66dp にしていたりします。1dp だとボーダーとかちょっとしゅっとしなくなるので.....

P166
エンジニアの「できない」は信じないほうが良いです。
でも「できる」って言うと仕事が増えるんです。
足立:アプリのクオリティをあげるのは重要で、期限があるときは、
 どこを削るのかが重要。一番最初のローンチ時の立ち上がりが重要。
 問題があるなら、全部に時間をかけるのは難しいので、
 使い勝手や、使い心地など、大事なところが2、3個ピックアップして、
 集中してやった方がいい。
 勝負できるのはスピードも重要。最初のクオリティが非常に重要。
 そこでコケてしまうと、後で取り返すがの大変。
 大量に広告しなければ、いけなかったり。
 と、個人的には思っています。
納期はまもらなければいけない。
予算が決まっているので。
 足立;細かいところ修正するよりも、
    たくさんの端末でちゃんと表示できるようにするほうが重要なのか、
    プロダクトデザイナーがジャッジするべき。

P169
P170

足立:デザインを全部みた上に面倒を見るのは大変。
  Webデザインよりも大変。人から言われて、まだプログラム書いてないのにXMLのこと言われても。
  微調整くらいはデザイナーができると楽になる。
XML の押し付け合い...........
新しい機能がでたら、git にあげて、お知らせする
足立: デザイナーのための git というセミナーを...むちゃくちゃ助かってます。
 ゆくゆく考えれば、id 設定もお願いできれば....
Webデザインがいいのは、ツールがいっぱいあって、デザイナーがいろいろできるのが良いところ。
ここはそういうツールが出てくるのを待つか、XMLをデザイナーが勉強するのか、
XMLコーダーみたいな人がでてくるのか、過渡期にあると思います。

ベースを作ってもらって、数値設定に口出しできるようになるだけでも
変わってきます。

公開したスライドには、全部の「声」が書かれています。良かったら見てください。

11/05/2012

[&] Core App Quality Guidelines



このドキュメントは
Core App Quality Guidelineshttp://developer.android.com/distribute/googleplay/quality/core.html
Creative Commons ライセンスに基づく日本語訳です。
十分に注意して翻訳しておりますが、正確な内容や詳細に関しては原文をご確認ください。

Core App Quality Guidelines


インストール、ユーザーの評価やレビュー、契約、及びユーザーの保持に関して、アプリの品質は直接的にあなたのアプリの長期的成功に影響を与えます。それらのアプリにお金を費やしてきた場合は尚更のこと Android ユーザーは、高品質のアプリを期待します。


このドキュメントは、中心となるアプリの品質基準及び関連するテストのコンパクトな組み合わせを通して、あなたのアプリの品質の基本的側面を評価するのに役立つものです。すべての Android アプリが、これらの基準を満たす必要があります。


あなたのアプリを公開する前に、多くのデバイス上でそれが上手く機能し、ナビゲーション及びデザインのためのAndroid基準を満たしているか確認してください。Google Play Store のプロモーション機会のための準備が確実かどうか、これらの基準に照らして、テストして下さい。実際のところ、あなたが実施するテストは、ここに記載されているものを凌駕して上手く行くことでしょう。このドキュメントの目的は、あなたのテスト計画に基本的な事柄を加えることができるように、基本的品質に必須の事柄を明記することです。


あなたのアプリがタブレット・デバイスをターゲットにしている場合には、タブレットの利用者に贅沢で説得力のある経験をもたらすことを確認して下さい。あなたのタブレット用アプリを最適化する方法に関する、お薦めの頃柄については Tablet App Quality Checklist を参照して下さい。



Visual Design and User Interaction


首尾一貫した、直感的なユーザー・エクスペリエンスのために、適切な場所で、あなたのアプリが標準的 Android ビジュアル・デザイン及びインタラクションパターンを提供することを、これらの基準は保証します。



Area

ID

Description

Tests
Standard design
UX-B1

アプリは Android デザイン・ガイドライン に準拠しており、共通の UIパターンとアイコンを使用しています:

  1. アプリはシステムアイコン(例えば、戻るボタンなど)の規定された機能を再定義しません。
  2. 標準的なUIの振る舞いを使う場合、アプリは標準とは完全に異なるアイコンを使用してシステムアイコンを置換してはいけません。
  3. アプリが標準的システムアイコンのカスタマイズ版を提供する場合、そのアイコンはシステムアイコンによく似たもので、標準的な振る舞いをするものでなければいけません。
  4. アイコンや振る舞いに誤解を招いたり、ユーザーを混乱させるような Android UI パターンを、アプリは再定義したり、誤用してはいけません。
CR-all
Navigation
UX-N1

アプリは標準システムである戻るボタン・ナビゲーションをサポートしますが、任意でオーダーメイドされた、画面上の”戻るボタン”プロンプトを使用はしません。
Back button navigation

CR-3

UX-N2

戻るボタンを使用して、すべてのダイアログを却下することができます。

CR-3

UX-N3

任意の時点でホームボタンを押すと、デバイスの [Home screen] に移動します。
CR-1
Notifications
UX-S1

通知(ノーティフィケーション) は、Androidデザイン・ガイドラインに準拠します。特に以下のとおりです:

  1. 複数の通知が可能な場所で、単一の通知オブジェクトに積層される。
  2. (音楽再生や電話など)進行中のイベントに関連する場合のみ、通知は永続的です。
  3. ユーザーがオプトインで許可していない場合、通知には広告やコア機能とは無関係の内容は含まれません。

CR-11

UX-S2


通知(ノーティフィケーション)のみを使用するアプリ:

  1. (着信メッセージなど)ユーザー個人に関連するコンテキスト上の変化を示すため、或いは
  2. (音楽再生や電話など)進行中のイベントに関連する情報/コントロールを表すため。
CR-11

Related resources:

  • Android Design — Android アプリのデザイン概要およびユーザー体験の成功事例
  • Navigation with Back and Up — 標準ナビゲーションパターンを説明する Android Design の文書
  • Action Bar — アクションバーの使用方法を説明する Android Design の文書
  • Iconography — 各種のアイコンの使用方法を説明する Android Design の文書
  • Notifications — ノーティフィケーションのデザインおよび使用方法を説明する Android Design の文書

Functionality


これらの基準により、あなたのアプリが適切な水準のパーミッションで、確実に期待通りに機能が作動するようにします。



Area

ID

Description

Tests
Permissions
FN-P1
アプリは、コア機能をサポートするために必要な最低限の絶対的水準のパーミッションしか要求しません。
CR-11

FN-P2

アプリは、コア機能に関連しない限り、秘密性の高いデータ([Contacts]や[the System Log]等)や、ユーザのメモリを消費するサービス(通話やSMS等)へアクセスするパーミッションを要求することはありません。

Install location
FN-L1

アプリは、通常、SDカード(アプリがサポートしている場合)にインストールされたときに機能します。


ほとんどの大容量(10MB以上)のアプリについては、SDカードへのインストールをサポートすることをおすすめします。どの種類のアプリでSDカードへのインストールをサポートするべきかについての情報は、アプリ・インストールロケーション開発者向けガイド(App Install Location) をご覧ください。

SD-1
Audio
FN-A1

オーディオは、それがコアな特徴でない限り(例えば当該アプリが音楽プレイヤーである場合等)、スクリーンがオフのときには再生されません。
CR-7

FN-A2

オーディオは、それがコアな特徴でない限り、ロック・スクリーンの背面で再生されることはありません。
(play behind the lock screen)
CR-8

FN-A3

オーディオは、それがコアな特徴でない限り、ホーム・スクリーン上やその他のアプリの上で再生されることはありません。

CR-1,
CR-2

FN-A4

オーディオは、アプリが前面に戻ってきたときに再開、またはユーザに再生が一時停止の状態になっていることをお知らせします。
CR-1, CR-8
UI and Graphics
FN-U1

アプリは、横画面と縦画面の両方をサポートします (可能な場合)。

画面方向を問わずほぼ同じ機能とアクションが表示され、機能的同等性を保ちます。コンテンツや表示の小さな変更は許容できます。

CR-5

FN-U2

アプリは両方の画面方向で全画面を用い、画面方向の変更に対応するためにレターボックス表示を用いることはありません。

画面ジオメトリの小さな多様性に対応するために若干のレターボックス表示を用いることは許容できます。

CR-5

FN-U3

アプリは、描画問題を生じることなく、画面方向の素早い変更に適切に対応します。

CR-5
User/app state
FN-S1

アプリは、そのサービスがアプリの中核的な機能に関連するものである場合を除き、アプリがバックグラウンドで実行中の場合は、いかなるサービスも動かし続けるべきではありません。

例えば、アプリは、通知(ノーティフィケーション)のためのネットワーク接続を維持するためや、Bluetooth接続を維持するため、あるいはGPSをオンにしたままにするためにサービスを動かし続けるべきではありません。

CR-6

FN-S2

アプリは、ユーザーやアプリの状態を適切に保存し、復旧します。

アプリは、フォアグラウンドから離れる際、ユーザーやアプリの状態を保存し、バック・ナビゲーションやその他の状態変更に伴う偶発的なデータ損失を防止します。フォアグラウンドに戻る際は、アプリは、編集可能なフィールドへの変更、ゲームの進行、メニュー、動画、およびアプリやゲームのその他のセクションといった、各種の保存した状態およびあらゆる重要な保留中のステートフル・トランザクションを復旧する必要があります。

  1. アプリが最近使ったアプリの一覧からレジュームされた際、アプリはユーザーのためにそれが最後に使われた際の状態を厳密に復旧します。
  2. アプリが、デバイスがスリープ (ロック中) 状態から戻った後にレジュームされた際にも、アプリはユーザーのためにそれが最後に使われた際の状態を正確に復旧します。
  3. アプリがホーム画面もしくは全てのアプリの一覧から再起動された際は、アプリは以前の状態になるべく近い状態を復旧します。
  4. Backキーが押された際には、アプリは、保存しなければバック・ナビゲーションで失われるアプリやユーザーの状態を保存するかどうかをユーザーに確認します。
CR-1, CR-3, CR-5

Related resources:

  • Making Android Apps that Play Nice — オーディオ・ライフサイクルおよび Androidアプリで予想されるオーディオの挙動について説明した開発者ブログ記事
  • Tasks and Back Stack — バック・ナビゲーションの実装方法を説明する開発者ガイド。
  • Recreating an Activity — アプリ状態の保存と復旧の方法を説明するAndroidトレーニング・クラス


Performance and Stability


高いユーザーレイティングを確保するには、アプリは、ターゲットとするあらゆるデバイス、フォームファクターやスクリーン上で、うまく機能しかつ優れた応答性を継続的に示す必要があります。こうした基準に従うことで、アプリは、ユーザーが期待する基本的なパフォーマンス、安定性、応答性を確実に提供します。



Area

ID

Description

Tests
Stability
PS-S1

アプリは、どんなターゲットデバイス上でも、クラッシュしたり、強制終了したり、フリーズしたり、その他機能異常を示したりしません。
CR-all, SD-1, HA-1
Performance
PS-P1

アプリは迅速に起動するか、あるいは、起動に2秒以上かかる場合、ユーザーに画面上のフィードバック (進行状況のインジケーターか同様のキュー表示) を提供します。

CR-all, SD-1

PS-P2

StrictModeを有効にすると (以下の StrictMode Testing を参照してください)、アプリの実行中、どんなレッドフラッシュ (StrictMode からのパフォーマンス警告) も見えません。こうしたアプリの実行には、ゲームプレイ、アニメーションや UIトランジション、アプリのその他の部分が含まれます。

PM-1
Media
PS-M1

アプリを普通に使用・ロードしている間、音楽と動画の再生はスムーズで、音が詰まったり、パチパチというノイズが載ったり、その他の歪みはありません。

CR-all, SD-1, HA-1
Visual quality
PS-V1

目立つ歪み、ブレ、或いはピクセルのずれが無いか。アプリは正しく、グラフィクス、テキスト、画像、及びその他のUI要素を表示するか。


  1. タブレットなどの大画面デバイス用も含めて、アプリは対象となるすべての画面サイズとフォームファクタのための高品質なグラフィクスを提供します。Tablet App Quality Checklist
  2. メニュー、ボタン、及びその他のUI要素のエッジで、にじんだようには表示されないことを確認します。
CR-all

PS-V2

間違いなく、アプリはテキストとテキストブロックを表示します。


  1. タブレットなどの大画面デバイス用も含めて、画面構成はサポートされているすべてのフォームファクタ上で差し支えない範囲で表示されています。
  2. 表示が欠けた文字や単語はありません。
  3. ボタンやアイコン内での不適切な文字の折り返し表示はありません。
  4. テキストと周囲の要素との間に十分な間隔があります。

Related resources:

  • Using StrictMode の使い方を解説した開発者ブログ、及びあなたのアプリ上でのパフォーマンス監視のための StrictMode の使い方。
  • Designing for Responsiveness あなたのアプリの応答速度をよくするための開発者ガイド。
  • Multithreading for Performance マルチスレッドで、パフォーマンスの向上方法を議論する開発者ブログの記事


Google Play


作成したアプリを Google Play でスムーズに販売するためには、まずアプリの評価を上げ、必ず下記内容に従ってストア内でのプロモーション準備を行ってください。



Area

ID

Description

Tests
Policies
GP-P1

アプリは Google Play Developer Content Policy に記された規約を遵守するものとします。不適切な内容や他者の特許を侵害したもの、他者のブランドを侵害したもの等は認めません。

GP-all

GP-P2

アプリの対象年齢は
Content Rating Guidelines をもとに適切に設定してください。


特にデバイスの位置情報を使用する許可が必要なものは、対象を全年齢としないでください。


GP-1
App Details Page
GP-D1

アプリの内容を判断することができるガイドラインに沿った画像を。
この Blog に掲載します. 以下の点をご確認ください:


  1. 必ず、高画質の画像を準備してください。
  2. デバイスの画像、スクリーンショット、アプリ検索用に画像サイズを縮小したうえで小さなディスプレイに表示すると読み取れないサイズの文字は使用しないでください。
  3. 広告のような画像は認めません。



GP-1, GP-2

GP-D2

アプリのスクリーンショットおよび動画は非 Android デバイスを表示または参照していません。
GP-1

GP-D3

アプリのスクリーンショットおよび動画は、あなたのアプリのコンテンツや経験を誤解を招く方法で示すものではありません。
User Support
GP-X1
Google Play ページのレビュータブ内で一般ユーザーから報告されたバグは、再発の可能性があり、多くの異なるデバイス上で発生する場合があります。バグが特定の機種だけ起こるとしても、それらのデバイスが特に人気のある、または新しいものである場合は対処しなければなりません。

GP-1

Related resources:

Setting Up a Test Environment

アプリの品質評価には、テストのために適切なハードウエアもしくはエミュレータ環境を準備してください。

重用視されるフォームファクタ(画面解像度などの物理的条件)、一般顧客が通常入手できるハード/ソフトの組み合わせを代表する、少数の実機を含めたテスト環境が理想的です。市場に出ているあらゆるデバイスでテストを行う必要はありません。代表的なものを少数検査すればよく、フォームファクタごとに1~2台で十分です。

実際のデバイスをテスト用に準備するのが難しい場合は、最も広く用いられているフォームファクタやハード/ソフトの組み合わせの代表的な設定の エミュレータ(AVDs) を準備してください。

さらに高度なテストを行うためには、追加のテスト環境としてデバイスやフォームファクタを追加したり、ハードとソフトの新しい組み合わせを試すこともできます。ほかにも、テストや品質基準の検査数や複雑さを高めてもよいでしょう。

Test Procedures

これらのテストの手順は、あなたのアプリの多種多様の品質問題を発見するのに役に立ちます。あなた独自のテストプランでテストを組み合わせたり、テストのグループを統合することができます。上記のセクションで、特定の分野が特定のテストに関連する参考資料をご覧ください。


Type

Test

Description
Core Suite
CR-0

アプリのすべての箇所を操作します-すべての画面、ダイアログ、設定、およびすべてのユーザーフロー


  1. アプリケーションでコンテンツの編集および作成、ゲーム、またはメディア再生が可能な場合は、コンテンツを作成または変更するためのこれらのフローを必ず実施してください。
  2. アプリ使用中のネットワークの接続性、バッテリー機能、GPSまたは使用可能な場所、システム負荷など一時的な変更を実施してみてください。

CR-1
アプリの各画面から、デバイスの[ホーム]キーを押して、[すべてのアプリ]画面からアプリを再起動します。

CR-2
アプリの各画面から、ご使用中の別のアプリに切り替えて、[最新]のアプリ切り替えを使用してアプリをテスト状態に戻します。

CR-3
アプリの各画面(およびダイアログ)から、[戻る]ボタンを押します。

CR-5
アプリの各画面から、デバイスをランドスケープ(横)とポートレート(縦)の方向に最低3回回転させます。

CR-6
テストアプリをバックグラウンドに送るために別のアプリに切り替えます。[設定]に行き、バックグラウンドにいる間テストアプリにサービスが実行されているかどうかを確認します。Android 4.0 およびそれ以降では、[アプリ]画面に行き[実行中]タブでアプリを見つけます。それ以前のバージョンでは、[アプリケーションの管理]を使用して実行中のサービスをチェックします。

CR-7

電源ボタンを押してデバイスをスリープ状態にしてから、電源ボタンを再度押して画面を復帰させます。

CR-8

電源ボタンを押したときにロックするようにデバイスを設定します。電源ボタンを押してデバイスをスリープ状態にしてから、電源ボタンを再度押して画面を復帰させ、デバイスのロックを解除します。

CR-9

キーボードを引き出すデバイスでは、キーボードを最低1回引き出したり入れたりします。キーボードドックがあるデバイスでは、キーボードドックにデバイスを取り付けます。

CR-10

外部ディスプレイポートがあるデバイスでは、外部ディスプレイを差し込みます。

CR-11
ノーティフィケーション通知領域にアプリが表示できる全種類の通知を表示させて観察します。必要に応じて通知を展開し(Android 4.1 およびそれ以降) 、提供されたすべてのアクションをタップしてみます。

CR-12
[Settings > App Info] で、アプリより要求された許可を検討します。
Install on SD Card
SD-1

(アプリでサポートされている場合)本体のメモリや SD カード にインストールされたアプリのインストール先を移動させてみます。


SD カードにアプリを移動するには、[Settings > App Info > Move to SD Card]を使用します。

Hardware acceleration
HA-1

ハードウェアアクセラレーションが有効になった状態で中心となる機能を繰り返します。


ハードウェアアクセラレーションを有効にするには(デバイスによってサポートされている場合)、アプリの一覧とリコンパイル時に hardware-accelerated="true"<application> を加えます。

Performance Monitoring
PM-1

以下のように StrictMode プロファイリングが有効になった状態で基本的な機能を繰り返します。ガベージコレクションのタイミングとそのユーザ体験への影響によく注意してください。

Google Play
GP-1

あなたの開発者プロファイル、アプリの説明、スクリーンショット、特色グラフィック、マチュリティ設定、及びユーザのフィードバックを見るためには、Developer Console にサインインします。

GP-2

あなたの特色グラフィックとスクリーンショットをダウンロードし、それを標的としているデバイス及びフォームファクター上のディスプレイのサイズに適合するよう縮小します。

GP-3

すべてのグラフィック資料、メディア、テキスト、コードライブラリ、及びその他のアプリや拡張ファイルダウンロードに格納された内容を見ます。
Payments
GP-4

あなたのアプリのすべての画面へナビゲートし、すべてのアプリ内購買を確認します。

Testing with StrictMode

パフォーマンスのテストのためには、あなたのアプリで StrictMode を有効にし、パフォーマンス、ネットワーク接続、ファイルの読み込み/書き出し等に影響する可能性のあるメインスレッドやその他のスレッド上での作動を把握するために使用することをおすすめします。

StrictMode.ThreadPolicy.Builder を使ってスレッドごとにモニタリング・ポリシーを設定し、detectAll() を使って ThreadPolicy 内でサポートされた全てのモニタリングを有効にすることができます。 .

penaltyFlashScreen() を使って ThreadPolicy のためのポリシー違反の visual notification が有効であることを確かめてください。