Posted by 山崎富美 Developer Relations Team

[この記事は Android Developers に掲載された "Improving App Quality After Launch" という記事を元に翻訳・再構成しています。詳しくは元記事をご覧ください。-山崎]

Google Play では毎週、何千ものアプリが新しく公開されています。その中でできるだけ知名度を高め、高い評価を得るためにできることを探ることが重要です。アプリがどんどん登場するエコシステムの中で、アプリの知名度を高める 1 つの方法は、ターゲットをうまく絞ったモバイル広告キャンペーンやクロス アプリ プロモーションを展開することです。これとは別に、インプレッション → インストール → ランキングのサイクルを活発化させる、長年の実績がある確実な方法があります。それは、「製品を改良すること」です。

アプリの質を高めることには多くの利点があります。品質の高いアプリはユーザー評価が高くなり、概してランキングも高く、ダウンロード数も多く、そして高いリテンション率(インストールされている期間の長さ)を誇ります。また、高品質のアプリは、Google Play でおすすめとして紹介されたり、ソーシャルメディアで話題になったりするなど、思いがけない形で、良い意味で注目を集める可能性も高くなります ...
Posted by 山崎富美 Developer Relations Team

[この記事は Android Developers に掲載された "Improving App Quality After Launch" という記事を元に翻訳・再構成しています。詳しくは元記事をご覧ください。-山崎]

Google Play では毎週、何千ものアプリが新しく公開されています。その中でできるだけ知名度を高め、高い評価を得るためにできることを探ることが重要です。アプリがどんどん登場するエコシステムの中で、アプリの知名度を高める 1 つの方法は、ターゲットをうまく絞ったモバイル広告キャンペーンやクロス アプリ プロモーションを展開することです。これとは別に、インプレッション → インストール → ランキングのサイクルを活発化させる、長年の実績がある確実な方法があります。それは、「製品を改良すること」です。

アプリの質を高めることには多くの利点があります。品質の高いアプリはユーザー評価が高くなり、概してランキングも高く、ダウンロード数も多く、そして高いリテンション率(インストールされている期間の長さ)を誇ります。また、高品質のアプリは、Google Play でおすすめとして紹介されたり、ソーシャルメディアで話題になったりするなど、思いがけない形で、良い意味で注目を集める可能性も高くなります。

アプリの品質を高めることで得られるメリットは明らかです。しかし、アプリをどうやって「よりよいもの」にすればよいのかは必ずしも明確ではありません。このドキュメントでは、アプリの品質上の重要な要素をいくつか取り上げるとともに、アプリを公開した後に時間をかけてアプリを改良していく方法を紹介します。

品質基準
 ユーザーの声に耳を傾ける
 安定性の向上とバグの除去
 UI のレスポンスを改善する
 操作性を高める
 プロフェッショナルな見た目と美しさ
 適切な機能群を提供する
 システムとサード パーティのアプリと統合する
 細部にも注意を払う

その他参考資料
 アプリ品質ガイドライン
 タブレット向けアプリ品質チェックリスト


ユーザーの声に耳を傾ける


アプリの「成功」を測る方法の多くは、ユーザーの行動に基づくものです。ダウンロード数やアクティブ インストール数の日計、リテンション率など、ユーザーに基づく評価基準の存在は、ユーザーの大切さを際立たせます。まだそういった観点から評価を行っていないのであれば、アプリの品質をユーザーの行動と関連づけて考えることから始めるとよいでしょう。

ユーザーの意見を聞く方法で最も分かりやすいのが、Google Play のアプリに対するコメントを読み、対処する方法です。コメントは必ずしも生産的、建設的ではありませんが、中にはアプリに関してそれまでに思いつきもしなかったような貴重な見識を与えてくれるものもあるでしょう。ユーザーには、アプリに対して下した評価やコメントをいくらでも変える機会が与えられていることを覚えておきましょう。

ユーザーと対話し、意見を出してもらうようにする 1 つの方法は、サポートや議論の場を独自に設けることです。Google グループなどのフォーラムをはじめ、総合的なカスタマー サポートを提供する製品や場など、ユーザーと直に接することができる優れたサポート ツールは数多く存在します。そういったツールを用意したときは、Google Play の製品詳細ページにサポート ツールへのリンクを加え、ユーザーがそこへ飛べるようにしましょう。

それ以外にも、公開ベータ版や、信頼性の高いテスターにアプリを使ってもらいユーザーの声を集める方法があります。Google Play へのリリースに先立ち、実際のユーザーによるテストをある程度実施することは非常に重要です。幸いなことに、ウェブを使えば、Google Play 以外の場所でユーザーにアプリを配布することが可能です。そのウェブサイトをログイン制にするか、一般公開にするかは皆さんの自由です。Google Play への公開に先立ち、このような方法で次に予定しているアップデートをアーリー アダプターのユーザーに公開してみてください。一般のユーザーによるテストの中から、細かいながらもインパクトのある改良点が数多く見出されることに皆さんもきっと驚くと思います。


安定性の向上とバグの除去


アプリの全体的な安定性が評価やユーザー満足度にもたらす影響は非常によく知られていることで、さまざまな端末やユーザー シナリオでアプリのテストやプロファイリングを実施するためのツールや手法が数多く存在します。

注目に値しながらも、まだ比較的あまり活用されていないツールで、クラッシュなどの安定性の問題をとらえる UI/Application Exerciser Monkey(通称「Monkey」)というツールがあります。Monkey では、アプリのアクティビティに UI イベントをランダムに送信し、ユーザー フローをトリガーさせることで安定性にかかわる問題を発見できます。

さらに、ほとんどの Android 端末に内蔵されている Google のエラー報告機能により、ユーザーからデベロッパーにアプリケーション クラッシュを報告できるようになっています。エラー報告は集計されて Google Play Developer Console に表示されます。こういった報告をこまめに読み、適切に対処するようにしましょう。

このほか、外部のバグ・機能要望トラッカーを設置し、ユーザーにこのトラッカーを見つける方法を教えてください。そうすることでユーザーは、自分にかかわる機能やバグを追うことで、より密接にアプリに関与できるようになります。アプリの問題に対するユーザーの不満は、こまめなバグの追跡とコミュニケーションによって効率よく対処できます。前項で挙げたコミュニティー サポート ツールの中には、バグ追跡機能を提供しているものもありますし、みなさんのプロジェクトがオープン ソースであれば、大手リポジトリ ホスティング サイトの多くでこういった機能を利用することができます。



UI のレスポンスを改善する


ユーザーを確実に失いたければ、遅くて反応の悪い UI を作ることです。デスクトップ、ウェブ、モバイルなど、どのようなインターフェースにおいても、スピードが重要であることは調査で証明されています。さらに、モバイル端末においては、ユーザーは出先で情報をすぐに必要とする場合が多いことから、スピードの重要性はさらに増します。

長時間実行している動作をメイン スレッドからワーカー スレッドへと移動させることで、アプリのUI のレスポンスを向上できます。Android は、メイン スレッド上でのアプリのパフォーマンスやアクティビティを分析する StrictMode などのデバッグ機能を内蔵しています。他の推奨事項ついては、Google I/O 2010 のデベロッパー向けセッション Writing Zippy Android Apps(軽快な Android アプリを作成するには)(動画)を参照してください。

UI のパフォーマンスを向上させる良い方法の 1 つは、レイアウトをできるだけシンプルにすることです。hierarchyviewer を開き、レイアウトの階層が 6 つ以上あるときは、レイアウトを簡素化したほうがよいでしょう。このような深い入れ子状態になった LinearLayouts(リニアレイアウト)は、RelativeLayout(相対レイアウト)へと組み直しを検討してみてください。というのも、View(ビュー)オブジェクトの影響は累積するからです。オブジェクト 1 つで 1~2 KB のメモリを使用しますので、大きなビュー階層ほど VM のガベージ コレクションが頻繁に生じ、メイン(UI)スレッドをブロックしてしまいます。詳しくは、Google I/O のセッションの World of ListView(ListView の世界)(動画)を参照してください。

さらに、Google のブログ記事 Traceview War Story(Traceview 戦記)で指摘しているように、TraceviewDDMS といったツールはそれぞれ、メソッドのコールのプロファイリング、VM メモリ割り当てのモニタリングをしてくれるので、アプリの品質アップの頼もしい右腕となってくれるでしょう。

操作性を高める


操作性について、またアプリのデザインについてもそうですが、ユーザーの声にはよく耳を傾ける必要があります。身近な Android 端末ユーザー(友人や家族など)数人に頼んでアプリを試してもらい、彼らがどのように使うかを観察します。彼らが戸惑っているときや、進め方が分からないとき、何らかの動作に驚いているときがないかを確認してみてください。アプリ内のインタラクションの一部を見直し、こういったケースができるだけ少なくなるようにします。Google I/O で Android の UI チームが議論した Android UI patterns(Android UI のパターン)(動画)の一部が参考になるかもしれません。

これに関連して、Android ユーザー インターフェースで発生しがちな問題は、タップ ターゲットが小さい、フォントサイズが必要以上に小さい、という 2 つの問題です。これらの問題は多くの場合容易に解決でき、操作性やユーザー満足度に大きく影響することがあります。一般的に、使いやすさと読みやすさを考えて最適化する一方で、情報密度は最小限にする(少なくとも、慎重にバランスを取る)ようにします。
アプリの UI をデザイン・評価する際には、Android Design(Android デザイン)ガイドラインを読み、熟知するようにしてください。UI パターンやスタイル、構成要素の例を数多く取り上げているほか、デザイン プロセス用のツールも紹介しています。

このほか、現実世界のデータに基づいて操作性を徐々に向上させる方法として、アプリ全体にアナリティクスを実装して特定のセクションの利用状況を記録する方法があります。使用頻度が低いセクションは格下げしてアクション バーのオーバーフロー メニューに配置するか、すべて削除することを検討します。使用頻度が高いセクションや UI 要素は、アプリ UI 上でひと目見て分かるようにし、ユーザーが素早く使えるようにします。

最後になりましたが、操作性はトピックとして幅広く、扱っているドキュメントも数多く存在します。インターフェースのデザインや、認知科学、その他の分野とも密接に関連して語られるトピックですので、色々調べてみるのがよいでしょう。

プロフェッショナルな見た目と美しさ


プロのユーザー インターフェース デザイナー、つまり「モバイルと Android に精通し、さらに欲を言えばインタラクションとビジュアル デザインの両方をこなせる」人物はかけがえのない存在です。デザイナーを探す場所として有名なものには jobs.smashingmagazine.com があります。また、ソーシャル ネットワークの活用で優秀な人材が見つかることもあります。

UI デザイナーに仕事を頼む余裕がない場合は、自分でアプリの見た目をよくする方法がいくつかあります。まず、Adobe Photoshop や Adobe Fireworks などのラスター画像編集ツールの操作に慣れておきましょう。これらのアプリケーションを習得するには時間がかかりますが、インターフェースのデザイン全般を洗練させる上で非常に有益なスキルです。また、フレームワーク UI アセットやレイアウトを学び、こちらの関連資料を熟読して各種リソースのフレームワークをマスターしてください。9 パッチやリソース ディレクトリ修飾子などの手法は、いわば Android 独特の手法で、フレキシブルながらも美しい UI を構築する上で非常に重要です。

アプリのデザインやコードの作成作業を先へ進めてしまう前に、Android デザインのサイトにアクセスして、方針や構成要素、美しく魅力的なユーザー インターフェースをデザインするツールについて学んでください。

適切な機能群を提供する


アプリには適切な機能群を入れることが大事です。できるだけ多くの機能をアプリに盛り込もうとしてしまう、「フィーチャー クリープ」という落とし穴にはまってしまわないよう気をつけてください。モバイル端末では、その場で最も重要な情報、あるいは最も関連性の高い情報を即座に示すことが極めて重要です。ユーザーにとって情報過多は、情報不足と同じくらい、あるいはそれ以上にいらだたしいものです。

前述の通り、機能に対する要望を集めてそれに応えることで、ユーザーの声に耳を傾けるようにしてください。ただし、機能に対する要望を鵜呑みしないよう気を付けてください。集まった要望は、どのような機能を導入すべきかを考える上で参考になりますが、すべての要望を実現する必要はありません。

システムとサード パーティのアプリと統合する


快適なユーザー エクスペリエンスを提供する良い方法は、オペレーティング システムと密接に連携させることです。そういった点では、ホーム画面のウィジェット高度な通知グローバル検索の統合クイック コンタクトなどの機能は、手軽に実現できる機能です。

アプリのカテゴリによっては、ホーム画面ウィジェットなどの基本機能はあって当然という認識を持たれており、その機能が含まれていないと、それ以外の点で良いユーザー エクスペリエンスを提供していても、評価を落とすのは確実です。アプリの中には、Android の連絡先やアカウント、同期 API を利用してより密接な OS との連携を実現できるものもあります。

サード パーティとの統合によって、ユーザーにはさらなる快適さを提供できるうえ、端末としてのまとまり感を与えることもできます。また、他のアプリの機能を活用することで、コードを新たに書かなくてもアプリに機能を追加できる非常に優れた方法でもあります。例えば、カメラ アプリの場合、ユーザーが該当するサード パーティの編集アプリをインストールしていれば、写真をそのアプリで編集してから保管場所に保存するといったことも可能になります。このトピックに関する詳しい情報は、Android トレーニング クラスInteracting with Other Apps(他のアプリと連携する)を参照してください。

細部にも注意を払う


中でも注意すべきなのは、アプリのアイコンの品質と一貫性です。アプリのアイコン (特にランチャー アイコン) がどの解像度でも鮮明に表示されること、また、できる限りアイコンのガイドラインに従っていることを確認してください。アイコン作成で何かお困りの場合や自分でアイコンをデザインしようにもリソースがない場合は、アイコン一式を作成できる Android Asset Studio ツールの使用をご検討ください。

Posted by 山崎富美 Developer Relations Team

[この記事は Android Developers に掲載された "Tablet App Quality Checklist" という記事を元に翻訳・再構成しています。詳しくは元記事をご覧ください。-山崎]

アプリを Google Play に公開する前に、そのアプリが魅力的な機能と直感的で優れたデザインの UI を通じ、タブレット ユーザーの基本的な期待に応えているのかを確かめることが大切です。

タブレット端末は、Android 搭載製品の一角として成長しつつあり、新たな ユーザー エンゲージメントと収益を生みます。このドキュメントは、タブレット ユーザーを対象にしたアプリの成否を大きく左右する品質や機能セット、UI といった重要な側面に重点的に取り組む上で役立つはずです。それぞれの重要な分野についてチェックリスト項目を設け、細分化された作業内容やベスト プラクティスを記載しています ...
Posted by 山崎富美 Developer Relations Team

[この記事は Android Developers に掲載された "Tablet App Quality Checklist" という記事を元に翻訳・再構成しています。詳しくは元記事をご覧ください。-山崎]

アプリを Google Play に公開する前に、そのアプリが魅力的な機能と直感的で優れたデザインの UI を通じ、タブレット ユーザーの基本的な期待に応えているのかを確かめることが大切です。

タブレット端末は、Android 搭載製品の一角として成長しつつあり、新たなユーザー エンゲージメントと収益を生みます。このドキュメントは、タブレット ユーザーを対象にしたアプリの成否を大きく左右する品質や機能セット、UI といった重要な側面に重点的に取り組む上で役立つはずです。それぞれの重要な分野についてチェックリスト項目を設け、細分化された作業内容やベスト プラクティスを記載しています。

これ以降で示すチェックリストの作業項目には便宜的に番号を付けていますが、取り組む順番は問いません。また、ご自分のアプリにとって適切と思われる範囲で対応してください。ユーザーにできる限り最高のアプリを提供するという観点から、チェックリストの推奨事項にはできるだけ従うようにしてください。

チェックリスト内には、各作業で扱っているトピックに取り組む際に役立つ参考資料へのリンクを貼っていますのでぜひご参照ください。

チェックリスト
  1. コア アプリ品質のテスト
  2. レイアウトを最適化する
  3. 余っている画面領域を活用する
  4. タブレット画面用のアセットを使用する
  5. フォント サイズとタッチ ターゲットを調整する
  6. ホーム画面ウィジェットのサイズを調整する
  7. アプリの全機能セットを提供する
  8. ハードウェア機能を要求しない
  9. タブレット画面構成を宣言する
  10. Google Play のベスト プラクティスに従う
テスト

1. コア アプリ品質のテスト


優れたタブレット アプリを提供するための第一歩は、アプリの対象となる全端末と全フォーム ファクターにおいて、コア アプリ品質条件を満たしているかを確認することです。すべての条件については、Core App Quality Checklist(コア アプリ品質チェックリスト)を参照してください。

タブレット端末使用時のアプリ品質について、コア アプリ品質とタブレット アプリ品質の両面で評価するには、適切なハードウェアまたはエミュレーターを利用したテスト環境を整える必要があります。詳しくは、テスト環境を整えるのセクションを参照してください。
参考資料:

2. 大画面に合わせてレイアウトを最適化する


Android では、さまざまな種類の端末の画面サイズやフォーム ファクター上で動作するアプリの開発を容易に行うことができます。その幅広い適合性は、すべての対象端末に配布できる単一アプリの設計ができるという点で、開発者にとって有利に働きます。しかし、(特にタブレット ユーザーに対して)それぞれの画面構成に最適なユーザー エクスペリエンスを提供するには、対象の端末の画面構成ごとに、レイアウトや各種 UI コンポーネントを最適化する必要があります。タブレットでは、UI の最適化によって広い画面を活用できるというメリットを生かして、例えば新機能の提供や、新しいコンテンツの表示、その他のさまざまな方法によるエクスペリエンスの強化ができ、ユーザーのエンゲージメントを高めます。

携帯端末向けのアプリをすでに開発していて、それを新たにタブレットにも提供したいときは、まず、レイアウトやフォント、スペーシングを微調整することから始めます。場合によっては(7 インチのタブレットや、広々としたレイアウトのゲーム アプリなど)、これらを微調整するだけで見た目が整います。それ以外、例えばもっと大きなサイズのタブレットなどの場合は、UI の一部を設計し直すことで、「拡大されただけの UI」を効率の良いマルチペイン UI にしたり、ナビゲーションを行いやすくしたり、追加コンテンツへと変えたりすることができます。

「拡大されただけの UI」を解消する: タブレットの場合、単一ペイン レイアウトにすると不自然な余白が生じたり、一行が長くなりすぎたりします。パディングを使用して UI 要素の幅を狭くすると共に、マルチペイン レイアウトの使用も検討しましょう。

推奨事項は下記の通りです。

  • 必要に応じて large(大)および xlarge(特大)画面用のカスタムレイアウトを用意します。また、画面の最小寸法あるいは幅・高さの最小値に基づいてロードされるようなレイアウトを提供してもよいでしょう。
  • 大きめの画面については最低でもフォントサイズやマージン、間隔などの寸法をカスタマイズし、画面の使い方とコンテンツの読みやすさを改善します。
  • UI コントロールの位置を調整し、ユーザーがタブレットを手に持っているときに操作しやすい位置に配置します(横置きのときはサイドに配置するなど)。
  • UI 要素のパディングは通常、タブレットでは携帯端末の場合よりも大きくします。48dp 単位(グリッドは 16dp)にすることをお勧めします。
  • テキスト形式のコンテンツは、画面の端にぴったり沿った状態にならないよう適切にパディングを使用します。画面の端近辺では最低でも 16dp のパディングを使用してください。
特に、レイアウトが画面全体に「広がって」表示されないように注意します:
  • テキストの行は長くなりすぎないようにし、1 行あたり半角文字で最大 100 文字とし、1 行あたり50~75 文字に収めるのがベストです。
  • ListViews やメニューには画面の幅全体を使用しないでください。
  • パディングを使用してオンスクリーン要素の幅を管理したり、タブレット向けにマルチペイン UI に切り替えたり(次の項目を参照)します。
参考資料:

3. タブレット上の余っている画面領域を活用する


タブレット画面では、マルチペイン レイアウトにすることで見た目のバランスがよくなると同時に、実用性も読みさすさも向上します。

タブレット端末は携帯端末にくらべ、特に横向きにした場合、アプリで使える画面領域が大幅に増えます。中でも 10 インチのタブレットは特に画面領域が大きくなりますが、7 インチのタブレットでもコンテンツの表示やユーザーのために使えるスペースが増えます。

タブレット上で動作するときのアプリの UI を検討するときは、タブレット上の余っている画面領域を十分に活用しましょう。推奨事項は下記の通りです。
  • 追加のコンテンツを盛り込んだり、既存のコンテンツを別な形で扱ったりする方法を探ります。
  • タブレット画面では マルチペイン レイアウト(Multi-pane Layout)を使い、複数の単一ビューを 1 つの複合ビューにまとめます。こうすることで、増えた画面領域をより効率よく使用でき、ユーザーもアプリを操作しやすくなります。
  • 画面の向きが変わったときに複合ビューのパネルをどのように再配置するのかを考慮します。



複合ビューは、携帯端末用 UI(上)の複数の単一ビューを 1 つにまとめ、より充実した効率の良いタブレット用 UI にします(下)。

  • 1 つの画面は Activity サブクラスとして実装されますが、個々のコンテンツ パネルを Fragment サブクラスとして実装することを検討します。こうすることで、さまざまなフォーム ファクター全体で、またコンテンツを共有するすべての画面にわたって最大限にコードを再利用できます。
  • どの画面サイズでマルチペインUIを使用するかを決め、それぞれのレイアウトを適切な画面サイズ バケット(large/xlarge など)、あるいは最小画面幅(sw600dp/sw720 など)で提供します。
参考資料:

4. タブレット画面用に設計されているアイコンなどのアセットを使用する


アプリの見た目をよくするには、タブレット画面で使用されるピクセル密度用に作られているアイコンなどのビットマップ アセットを使用するようにします。具体的には、タブレットが通常サポートしている範囲のすべてのピクセル密度それぞれに対し、代替ビットマップ ドローワブルのセットを作成する必要があります。

表1. アイコンタイプ別の未加工のアセット サイズ
密度 ランチャー アクションバー 小型/コンテキストタイプ 通知
mdpi 48x48px 32x32px 16x16px 24x24px
hdpi 72x72px 48x48px 24x24px 36x36px
tvdpi (hdpi を使用) (hdpi を使用) (hdpi を使用) (hdpi を使用)
xhdpi 96x96px 64x64px 32x32px 48x48px

その他の検討事項:
  • アクションバーや通知、ランチャーのアイコンは、アイコンのデザイン ガイドラインに従ってデザインし、タブレット上でも携帯端末と同じ物理サイズにします。
  • ピクセル密度固有の リソース修飾子(resource qualifiers)を使用して、適切な代替リソース セットがロードされるようにします。
参考資料:

5. タブレット画面用にフォント サイズとタッチ ターゲットを調整する


タブレット上で使いやすいアプリにするには、アプリの対象としているすべての画面構成に合わせて、タブレット UI のフォント サイズとタッチ ターゲットを調整するための時間はしっかり取りましょう。フォントサイズの調整は、スタイル設定可能な属性(styleable attributes)または寸法のリソース(dimension resources)で行うことができます。また、タッチ ターゲットは前述したようにレイアウトとビットマップ ドローワブルで調整可能です。

推奨事項は下記の通りです。
  • テキストは、タブレットの画面サイズやピクセル密度で表示したときに大きすぎたり、小さすぎたりしないようにしましょう。ラベルは、該当する UI 要素に合わせて適正なサイズにし、またラベルやタイトルなどの各種要素が不適切な位置で改行されないようにします。
  • オンスクリーン要素については、タッチ ターゲットの推奨サイズは 48dp(最低でも 32dp)ですので、タブレット UI 用にいくつかの調整が必要かもしれません。ほとんどのユーザーを対象とした実装方法については、尺度とグリッド(Metrics and Grids)をお読みください。一部のユーザーのニーズに対応するには、大きめのタッチ ターゲットを使用するのが適切な場合があります。
  • 比較的小さなアイコンについては、TouchDelegate を使用するか、または透明ボタン内でアイコンをセンタリングすることで、タッチ可能な領域をできるだけ 48dp よりも大きくします。
参考資料:

6. タブレット画面用にホーム画面ウィジェットのサイズを調整する


アプリにホーム画面ウィジェットがある場合、タブレット画面での優れたユーザー エクスペリエンスを提供するため、下記に示す事項を検討してみてください。
  • ウィジェットのデフォルトの高さ・幅は、タブレット画面と最小/最大リサイズ高さ・幅に合わせて適切に設定します。
  • ウィジェットは 420dp 以上のサイズに変更できるようにし、垂直または正方形ウィジェットの場合はホーム画面の 5 行以上、水平または正方形ウィジェットの場合は 5 列以上にまたがるようにします。
  • 9 パッチ画像が正しくレンダリングされるようにします。
  • デフォルトのシステム マージンを使用します。
  • アプリの targetSdkVersion を 14 以上に設定します(可能な場合)。
参考資料:

7. アプリの全機能セットをタブレット ユーザーに提供する


タブレット ユーザーが、あなたのアプリの売りとなる機能をきちんと体験できるようにします。推奨事項は下記の通りです。
  • アプリは少なくとも携帯端末と同じ機能セットをタブレットにも提供するようにします。
  • 例外的なケースとして、ほとんどのタブレットにおいてハードウェア的に対応していない、あるいはユース ケース上対応していない一部の機能については、省くか他のものに置き換えても構いません。下記に例を示します。
    • 携帯端末では電話機能を使用しているが現在のタブレットでは電話機能を使用できない場合は、この機能を省くか、関連する機能に置き換えても構いません。
    • 多くのタブレットには GPS センサーが搭載されていますが、一般的なユーザーは、タブレットを持ってランニングをすることはまずありません。携帯端末向けアプリで、端末を身につけてランニングしたときに GPS で追跡し距離などを記録する機能を提供しているとしましょう。タブレットではそういったユース ケースの需要がないと思われるため、この機能をタブレット向けに提供する必要はないと考えられます。
  • タブレット UI から機能や性能を省くことになる場合は、ユーザーがそれらにアクセスできないようにするか、いわゆる「グレースフル デグラデーション」として代替機能を提供するようにします(ハードウェア機能については次のセクションも参照してください)。

8. タブレットに搭載されていない可能性があるハードウェア機能を要求しない


携帯端末とタブレットとでは一般的にセンサーやカメラ、電話機能など、各種機能のハードウェア サポートが異なっています。例えば、多くのタブレットは Wi-Fi 構成で利用できますが、電話機能には対応していません。

顧客ベース全体に対応する 1 つの APK を配布するためにも、タブレットでは一般的ではないハードウェア機能を要求するようなものがアプリに組み込まれていないことを確かめてください。
  • アプリのマニフェストには、android:required=”false” 属性で宣言されている場合を除き、タブレットで使用できない可能性のあるハードウェア機能や能力に対しては <uses-feature> 要素を含めないでください。例えば、アプリが次のような機能を要求しないようにします。
    • android.hardware.telephony
    • android.hardware.camera (バックカメラを参照)または
    • android.hardware.camera.front
  • 同様に、アプリのマニフェストには、タブレットでは適切でない可能性がある機能要件を暗示(imply feature requirements)する <permission> 要素は一切含めないでください。ただし、android:required=”false” 属性で宣言されている当該 <uses-feature> 要素を伴っている場合はこの限りではありません。
いずれの場合でも、アプリが使用するハードウェア機能が利用できないときもアプリは正常に動作し、必要に応じてグレースフル デグラデーションや代替機能を提供できなければなりません。例えば端末が GPS 未対応の場合は、アプリがユーザーに現在位置を手動で設定できるようにします。アプリは、必要なハードウェア性能についてランタイム チェックを実施し、適宜、処理を実施するようにします。
参考資料:

9. 対応しているタブレット画面構成を宣言する


幅広い種類のタブレットにアプリを配布できるようにするには、アプリが対応しているすべての画面サイズをマニフェストにて宣言します。
  • 必要に応じて、適切な属性を使い <supports-screens> 要素を宣言します。
  • マニフェスト内でアプリが <compatible-screens> 要素を宣言している場合は、その要素には、必ずアプリが対応しているタブレット画面のサイズ/ピクセル密度のすべての組み合わせを指定する属性が含まれていなければなりません。できれば、アプリでこの要素を使用するのは避けるようにしてください。
参考資料:

10. Google Play への公開に関するベスト プラクティスに従う


  • アプリは、すべての画面サイズ(携帯端末とタブレット)に対して 1 つの APK として公開し、Google Play への掲載は 1 つにします。その理由は、次の通りです。
    • ユーザーが検索やブラウズ操作、プロモーションからアプリを見つけやすい
    • ユーザーが新しい端末を入手したとき、アプリを復元しやすい
    • レーティングやダウンロード統計がすべての端末での合計になる
    • タブレット用アプリを別物として公開すると、ブランドとしてのレーティングが弱まる
  • 必要であれば複数の APK サポート(Multiple APK Support)を使いアプリを配布する選択肢もありますが、ほとんどの場合は 1 つの APK ですべての端末に対応することを強くお勧めします。
  • • 製品詳細のページにて、次のような方法でアプリのタブレット向け機能を目立たせます。
    • アプリがタブレット上で動作しているときのスクリーンショットを最低 1 枚は載せましょう。できれば横向きと縦向きそれぞれのスクリーンショットを 1 枚ずつ載せてください。こういったスクリーンショットを載せることで、アプリがタブレット向けにデザインされていることをユーザーに明確に示せると同時に、あなたがタブレット アプリをデザインする上で力を入れた点をアピールできます。
    • アプリの説明にタブレット対応であることを明記します。
    • アプリのリリース ノートや更新情報に、タブレット対応であることを盛り込みます。
    • アプリのプロモーション動画に、アプリがタブレット上で動作している様子を加えます。
  • アプリがきちんとタブレット端末へ配布されていることを確認します。Developer Console にて、アプリの対応端末リストをチェックし、対象のタブレット端末からアプリがフィルタリングされていないことを確かめます。
  • タブレット ユーザーにアプリの存在をアピールしましょう。タブレットでのアプリ使用を紹介するマーケティングや広告キャンペーンを企画します。
参考資料:

タブレット用テスト環境を整える


タブレット上でのアプリ品質(コア アプリ、タブレット アプリ両方の品質)を評価するには、適切なハードウェアまたはエミュレーターによるテスト環境を用意する必要があります。

テスト環境には、現在ユーザーに普及している主要なフォーム ファクター、ハードウェア/ソフトウェアの組み合わせのハードウェア実機をいくつか用意するのが理想的です。市場に出ているすべての端末をテストする必要はなく、1 つのフォーム ファクターにつき 1~2 台程度で、いくつかの代表的な端末を集中的にテストします。下の表に、テストに使う端末の概要を示しています。

テスト用に実機を入手できない場合は、代表的なフォーム ファクターとハードウェア/ソフトウェアの組み合わせのエミュレートした端末(emulated devices (AVDs))を準備します。使用するエミュレーターの推奨構成については、下表を参照してください。

基本的なテスト以上のテストを実施する場合は、テスト環境の端末やフォーム ファクターの数を増やす、他のハードウェア/ソフトウェアの組み合わせを使う、などが考えられます。例えば、中型サイズのタブレットや、ハードウェア/ソフトウェアの機能が多い(または少ない)タブレットなどを使用するのもよいでしょう。また、テストの項目数を増やしたり、複雑化したり、品質条件を増やしたりしても構いません。

表 1. 代表的なタブレット テスト環境には、下表の各行の端末(代表的なチップセット、プラットフォーム バージョン、ハードウェア機能構成を備えたもの)を 1~2 台準備するのがよいでしょう。
タイプ サイズ 密度 バージョン AVD スキン
7 インチ タブレット large または -sw600 hdpi,
tvdpi
Android 4.0+ WXGA800-7in
10 インチ タブレット xlarge または -sw800 mdpi,
hdpi
Android 3.2+ WXGA800


このチェックリストは Creative Commons Attributes 2.5(クリエイティブ・コモンズ 表示 2.5)ライセンスで公開しています。詳しい内容と制限事項については、コンテンツのライセンス(Content License)をご参照ください。

Posted by 山崎富美 Developer Relations Team

[「品質の高い Android アプリってなんだろう」と考えたことはありますか?Android Developers に掲載された "Core App Quality Guidelines" という記事で、それが解説されていたので翻訳しました。ぜひ参考にしてみてください。-山崎]

アプリの品質は、インストール数やユーザー評価、レビュー、エンゲージメント、ユーザー リテンションなどの面でアプリの長期的な成功に大きな影響を及ぼします。Android ユーザーは高品質なアプリを期待しますし、有料アプリであればなおのこと期待は高まります。

このドキュメントでは主要なアプリ品質基準と関連するテスト方法を簡潔にまとめて紹介し、アプリの基本的な品質を評価する上で役立つ内容になっています。すべての Android アプリは、ここに挙げる基準を満たす必要があります。

アプリを公開する前には、これらの基準に照らし合わせてアプリをテストし、アプリがさまざまな端末上で正常に機能すること、ナビゲーションやデザインに関する Android アプリとしての基準を満たしていること、そして Google Play ストアのプロモーション対象になるにふさわしいことを確認してください。みなさんが実際に行うテストは、ここで説明する内容よりもはるかに範囲が広くなるかと思います。このドキュメントは、基本な品質に欠かせない指針を明確に示すことで、それらをテスト プランの中に取り入れていただくことを目的にしています。

タブレット端末を対象にしているアプリの場合は、魅力的で充実した機能をタブレット ユーザーに提供するようにしてください。アプリをタブレット向けに最適化する際の推奨事項については ...
Posted by 山崎富美 Developer Relations Team

[「品質の高い Android アプリってなんだろう」と考えたことはありますか?Android Developers に掲載された "Core App Quality Guidelines" という記事で、それが解説されていたので翻訳しました。ぜひ参考にしてみてください。-山崎]

アプリの品質は、インストール数やユーザー評価、レビュー、エンゲージメント、ユーザー リテンションなどの面でアプリの長期的な成功に大きな影響を及ぼします。Android ユーザーは高品質なアプリを期待しますし、有料アプリであればなおのこと期待は高まります。

このドキュメントでは主要なアプリ品質基準と関連するテスト方法を簡潔にまとめて紹介し、アプリの基本的な品質を評価する上で役立つ内容になっています。すべての Android アプリは、ここに挙げる基準を満たす必要があります。

アプリを公開する前には、これらの基準に照らし合わせてアプリをテストし、アプリがさまざまな端末上で正常に機能すること、ナビゲーションやデザインに関する Android アプリとしての基準を満たしていること、そして Google Play ストアのプロモーション対象になるにふさわしいことを確認してください。みなさんが実際に行うテストは、ここで説明する内容よりもはるかに範囲が広くなるかと思います。このドキュメントは、基本な品質に欠かせない指針を明確に示すことで、それらをテスト プランの中に取り入れていただくことを目的にしています。

タブレット端末を対象にしているアプリの場合は、魅力的で充実した機能をタブレット ユーザーに提供するようにしてください。アプリをタブレット向けに最適化する際の推奨事項については、Tablet App Quality Checklist(タブレット向けアプリ品質チェックリスト)を参照してください。

品質基準
 視覚的デザインとユーザー インタラクション
 機能
 パフォーマンスと安定性
 Google Play

テスト
 テスト環境を整える
 テスト方法

その他参考資料
 タブレット向けアプリ品質チェックリスト
 公開後にアプリ品質を向上させる


視覚的デザインとユーザー インタラクション


一貫性のある直感的なユーザー エクスペリエンスを提供できるよう、アプリが必要に応じ、Android の標準的な視覚デザインとインタラクション パターンを使っていることを確認する基準です。

分野 ID 説明 テスト
標準デザイン UX-B1 アプリは、Android Design(Android デザイン) ガイドラインを順守し、共通の UI パターンとアイコンを使用する。
  1. システム アイコン(「Back」キーなど)に期待される機能の定義を変えないこと。
  2. 標準的 UI 動作を起動するシステム アイコンについては、これを全く別のアイコンに変えないこと。
  3. アプリが、標準システム アイコンをカスタマイズしたものを提供する場合、そのアイコンはシステム アイコンに極めて類似したものにし、標準的なシステム動作を起動すること。
  4. Android UI パターンの定義変更や誤った使い方(ユーザーに誤解や混乱を与えるアイコンや動作)をしないこと。
CR-all
ナビゲーション UX-N1 標準的なシステムである「Back」キー ナビゲーションをサポートし、オンスクリーンに独自の「Back」キー プロンプトは一切使用しないこと。 CR-3
UX-N2 すべてのダイアログは、「Back」キーで消すことができること。 CR-3
UX-N3 どの時点で「Home」キーを押しても、端末のホーム画面へ移動すること。 CR-1
通知 UX-S1 通知は、Android Design(Android デザイン)ガイドラインに従う。特に、以下の点に留意すること。
  1. 複数の通知は、可能であれば 1 つの通知オブジェクト内へスタックすること。
  2. 通知は、進行中のイベント(音楽再生や通話など)に関係している場合に限り、持続性を持たせることが可能。
  3. 通知には、ユーザーがオプト インしている場合を除き、アプリの基本機能に無関係な広告や内容を含めないようにすること。
CR-11
UX-S2 アプリは、以下の目的のために限り、通知を使用すること。
  1. ユーザーに個人的に関係するコンテキスト上の変化(メッセージ受信など)を通知するため。
  2. 進行中のイベント(音楽再生や通話など)に関連する情報/コントロールを表示するため。
CR-11
関連資料:

機能


アプリが適正な権限を持ち、期待される機能動作を提供しているかを確認する基準です。

分野 ID 説明 テスト
権限 FN-P1 基本機能をサポートするのに必要な最低限の権限しか要求しないこと。 CR-11
FN-P2 アプリの基本機能にかかわる場合を除き、機密性の高いデータ(連絡先やシステム ログなど)や、ユーザー側に支払いが発生するようなサービス(ダイヤラーや SMS など)にアクセスする権限を要求しないこと。
インストール場所 FN-L1 アプリは、SD カードにインストールされている場合でも正常に動作すること(アプリが対応している場合)。

サイズの大きいアプリ(10 MB 超)については、SD カードへのインストールをサポートすることが望ましい。どういったタイプのアプリのときに SD カードへのインストールをサポートすべきかについては、アプリのインストール場所に関するデベロッパー向けガイドを参照すること。
SD-1
オーディオ FN-A1 画面が消えているときは、オーディオは再生しないこと。ただし、それが基本機能の場合は除く(音楽プレーヤー アプリの場合など)。 CR-7
FN-A2 オーディオは、画面ロック中に再生しないこと。ただし、それが基本機能である場合は除く。 CR-8
FN-A3 オーディオは、ホーム画面または別のアプリ上では再生しないこと。ただし、それが基本機能の場合は除く。 CR-1,
CR-2
FN-A4 アプリがフォアグラウンドに復帰したときに、オーディオが再開する。もしくは、再生が一時停止の状態であることをユーザーに示すこと。 CR-1,
CR-8
UIとグラフィックス FN-U1 縦向き画面と横向き画面の両方をサポートすること(可能な場合)。

どちらの向きでもほぼ同じ特性と動作を備え、機能的同等性を維持すること。コンテンツや表示の軽微な変更は容認する。
CR-5
FN-U2 画面がどちらの向きでも画面全体を使用し、向きの変更に対応するのにレターボックスを用いないこと。

画面配置上のわずかな差分を相殺するために使用する若干のレターボックスは容認する。
CR-5
FN-U3 レンダリング上の問題を生じることなく、ディスプレイの向きの素早い遷移を正しく処理すること。 CR-5
ユーザー/アプリの状態 FN-S1 アプリは、バックグラウンドにあるときは、サービスを実行したままにしてはならない。ただし、アプリの基本機能にかかわる場合は除く。

例えば、通知のためのネットワーク接続の維持や、Bluetooth 接続の維持、GPS のパワー オン状態の維持といった目的のために、サービスを実行したままにしてはならない。
CR-6
FN-S2 ユーザーやアプリの状態を正しく保存し復旧すること。

アプリがフォアグラウンドから離れるときは、ユーザー/アプリの状態を保存し、バック ナビゲーションやその他の状態変化による偶発的なデータ損失を防止すること。アプリがフォアグラウンドに戻ったとき、保存した状態と、重要なステートフル トランザクション(編集可能フィールドへの変更やゲームの進捗、メニュー、動画、アプリやゲームのその他セクションなど)で保留中だったものがあればそれを復旧させること。
  1. 「最近使用したアプリ」スイッチャーからアプリを再開するときは、アプリは、最後に使用されたときの状態にユーザーを戻すこと。
  2. スリープ(ロック)状態から端末を復帰させたのちにアプリを再開するときは、最後に使用されたときの状態にユーザーを戻すこと。
  3. アプリをホームまたは「すべてのアプリ」から再度起動するときは、直前の状態にできるだけ近い状態で復旧させること。
  4. 「Back」キー押下時に、バック ナビゲーションで状態が失われる内容がある場合は、アプリ/ユーザーの状態を保存する選択肢を用意すること。
CR-1,
CR-3,
CR-5
関連資料:


パフォーマンスと安定性


ユーザーからより高い評価を得るには、対象とするすべての端末、フォーム ファクター、画面上で正常に機能し、応答性を維持することが求められます。ここでは、ユーザーが期待する基本的なパフォーマンスや安定性、レスポンスをアプリが提供していることを確認するための基準を挙げます。

分野 ID 説明 テスト
安定性 PS-S1 対象とする端末すべてにおいて、クラッシュ、強制終了、フリーズなどの異常な動作が起きないこと。 CR-all,
SD-1,
HA-1
パフォーマンス PS-P1 アプリは素早くロードされること。ロードに 2 秒以上かかるときは画面上にユーザーへのフィードバックを表示すること(進捗のインジケーターなど、手がかりになるものを表示)。 CR-all,
SD-1
PS-P2 StrictMode が有効なとき(後述する StrictMode でのテストを参照)、アプリの実行中(ゲームプレイやアニメーション、UI 遷移、その他アプリのあらゆる部分の実行中も含む)は、赤の点滅(StrictMode からのパフォーマンス警告)が表示されないこと。 PM-1
メディア PS-M1 音楽と動画の再生がスムーズで、通常のアプリ使用状況下および通常の負荷の状態では、途切れたり止まったりするなどのノイズが生じないこと。 CR-all,
SD-1, HA-1
視覚的品質 PS-V1 目立った変形やぼやけ、ピクセレーションを生じることなく、グラフィックやテキスト、画像、その他 UI 要素を表示すること。
  1. アプリは、対象とする画面サイズ、フォーム ファクター(タブレットなどの大画面の端末も含む)のすべてにおいて高品質のグラフィックスを表示すること。
  2. メニューやボタン、その他 UI 要素の端の部分にエイリアシングが生じないこと。
CR-all
PS-V2 テキストとテキスト ブロックを適切に表示すること。
  1. タブレットなどの画面が大きい端末も含め、対応する全てのフォーム ファクターにて構図が適正である。
  2. 切れている文字や単語がない。
  3. ボタンやアイコン内のテキストが不適切な位置で改行されていない。
  4. テキストとその周辺にある要素の間には十分なスペースがある。
関連資料:


Google Play


アプリを Google Play で公開し、評価を上げ、ストアのプロモーション活動の対象になるようにするには、下記の基準を満たしてください。

分野 ID 説明 テスト
ポリシー GP-P1 Google Play デベロッパー プログラム ポリシーの条項を厳守し、不適切なコンテンツを提供したり、他人の知的財産権や商標などを使用したりしないこと。 GP-all
GP-P2 アプリの成熟度がコンテンツのレーティングに関するガイドラインに基づいて適切に設定されていること。

特に、端末の位置情報の使用許可を求めるアプリの場合は、成熟度レベルの「全ユーザー対象」は設定できないことに注意する。
GP-1
アプリ詳細ページ GP-D1 アプリの宣伝用画像については、こちらのブログ記事に説明されているガイドラインに従う。以下の点を守ること。
  1. アプリの掲載情報には、高品質な宣伝用画像が含まれていること。
  2. 宣伝用画像には、最も小さい対象端末上で縮小表示されたときに読めないようなテキスト、端末の画像、スクリーンショットがでていないこと。
  3. 宣伝用画像は、広告のように見えないようにすること。
GP-1,
GP-2
GP-D2 アプリのスクリーンショットや動画では、Android 以外の端末を見せたり言及したりしないこと。 GP-1
GP-D3 アプリのスクリーンショットや動画では、アプリの内容やアプリで体験できることを、誤解を招く形で表現しない。
ユーザー サポート GP-X1 Google Play ページの「レビュー」タブで、ユーザーから報告された共通のバグについては、そのバグが再現可能で、多数の異なる端末で発生している場合は対処すること。少数の端末でしか発生していないバグの場合でも、それらの端末が特に普及している端末、あるいは新しい端末の場合にはそのバグに対処する必要がある。 GP-1
関連資料:


テスト環境を整える


アプリの品質を評価するには、テスト用に適切なハードウェアあるいはエミュレーター環境を用意する必要があります。

テスト環境には、現在ユーザーに普及している主要なフォーム ファクター、ハードウェア/ソフトウェアの組み合わせのハードウェア実機をいくつか用意するのが理想的です。市場に出ているすべての端末をテストする必要はなく、1 つのフォーム ファクターにつき 1、2 台程度で、いくつかの代表的な端末を集中的にテストします。

テスト用に実機を入手できない場合は、代表的なフォーム ファクターとハードウェア/ソフトウェアの組み合わせのエミュレーション用端末(AVD)を準備します。

基本的なテスト以上のテストを実施する場合は、テスト環境の端末やフォーム ファクターの数を増やす、他のハードウェア/ソフトウェアの組み合わせを使用する、などが考えられます。また、テストの項目数を増やしたり、複雑化したり、品質基準を増やしたりしても構いません。


テスト方法


アプリのさまざまな品質に関する問題の発見につながるテストの方法を以下に示します。皆さんのテストプランの中では、これらのテスト同士を組み合わせたり、複数のテストグループを 1 つにまとめたりしても構いません。一部のテストで、一定の基準があるものについては、これまでのセクションを参考にしてください。

タイプ テスト 説明
基本機能全般 CR-0 アプリのあらゆる部分(すべての画面やダイアログ、設定、すべてのユーザーフロー)のナビゲーションを確認する。
  1. 編集やコンテンツの作成、ゲームプレイ、メディア再生ができるアプリの場合は、コンテンツを作成・変更するフロー内も確認すること。
  2. アプリの実行中に、ネットワーク接続状態やバッテリー機能、GPS や位置取得状況、システム負荷などを一時的に変化させること。
CR-1 アプリの各画面から、端末の「Home」キーを押したのち、「すべてのアプリ」画面からアプリを再度起動する。
CR-2 アプリの各画面から、実行中の別のアプリに切り替え、「最近使ったアプリ」スイッチャーを使ってテスト中のアプリに戻る。
CR-3 アプリの各画面(とダイアログ)から、「Back」キーを押す。
CR-5 アプリの各画面から、画面を回転させて縦向きと横向きを切り替える。最低 3 回は実施すること。
CR-6 別のアプリに切り替えて、テスト中のアプリをバックグラウンドへ移動させる。「設定」へ行き、テスト中のアプリがバックグラウンドで何らかのサービスを実行していないかをチェックする。Android 4.0 以降では、「アプリ」画面へ行くと、「実行中」タブにアプリが表示される。それ以前のバージョンの場合は、「アプリケーションの管理」で実行中のサービスがないかを確認する。
CR-7 電源ボタンを押して端末をスリープ モードにしたのち、電源ボタンを再度押して画面を復帰させる。
CR-8 電源ボタンを押したときにロックするよう端末を設定する。電源ボタンを押して端末をスリープ モードにしたのち、電源ボタンを再度押して画面を復帰させ、端末のロックを解除する。
CR-9 スライド式キーボードを搭載している端末では、キーボードの出し入れを最低 1 回は実施する。キーボード ドック付きの端末では、端末をドックに装着してみる。
CR-10 外部ディスプレイ ポート付きの端末では、外部ディスプレイを接続してみる。
CR-11 通知ドロワーに、アプリが表示できる全種類の通知を表示させて確認する。展開できる通知は展開し(Android 4.1以降)、提供されているアクションをすべてタップする。
CR-12 「設定」>「アプリ情報」で、アプリが要求する権限を確かめる。
SD カードへのインストール SD-1 端末 SD カード(アプリが対応している場合)にインストールしたアプリで、「基本機能全般」の項目を繰り返す。

アプリを SD カードに移動するには、「設定」>「アプリ情報」>「SD カードに移動」を選ぶ。
ハードウェア アクセラレーション HA-1 ハードウェア アクセラレーションを有効にした状態で、「基本機能全般」の項目を繰り返す。

ハードウェア アクセラレーションを強制的に有効にするには(端末が対応している場合)、アプリのマニフェストの <application>hardware-accelerated="true" を追加し、リコンパイルする。
パフォーマンス モニタリング PM-1 後述する StrictMode によるプロファイリングを有効にした状態で、「基本機能全般」の項目を繰り返す。

ガベージ コレクションや、それによるユーザー エクスペリエンスへの影響を注視する。
Google Play GP-1 Developer Console にサインインし、デベロッパーのプロフィールやアプリの説明、スクリーンショット、宣伝用画像、成熟度設定、ユーザーのフィードバックを確認する。
GP-2 宣伝用画像とスクリーンショットをダウンロードし、アプリの対象端末やフォーム ファクター上のディスプレイ サイズに合うようサイズを縮小する。
GP-3 すべての画像アセットや、メディア、テキスト、コード ライブラリーなど、アプリまたは拡張ファイル ダウンロードにパッケージとして含まれているコンテンツを確認する。
支払い GP-4 アプリのすべての画面のナビゲーションを確認し、また、アプリ内の購入フローの中も確認する。


StrictMode でのテスト


パフォーマンスのテストでは、アプリで StrictMode を有効にし、パフォーマンスやネットワーク アクセス、ファイルの読み書きなどに影響しそうなメイン スレッドとその他スレッド上の動作を捕捉することをおすすめします。

StrictMode.ThreadPolicy.Builder にてスレッドごとにモニタリング ポリシーを設定でき、detectAll() を使用すれば、ThreadPolicy にてサポートされているモニタリングをすべて有効にできます。

penaltyFlashScreen() を使い、ThreadPolicy に対するポリシー違反の視覚通知を有効にしてください。

Posted by 北村英志 Developer Relations Team

1 月 31 日(木)、Chrome Tech Talk Night #5 を開催します。

概要

今回は、Chrome Developer Advocate の Ilya Grigorik を迎え、SPDY導入方法を含むウェブアプリケーションの高速化やパフォーマンス向上の手法についてお話します。ご興味のある方はふるってご参加ください ...
Posted by 北村英志 Developer Relations Team

1 月 31 日(木)、Chrome Tech Talk Night #5 を開催します。

概要

今回は、Chrome Developer Advocate の Ilya Grigorik を迎え、SPDY導入方法を含むウェブアプリケーションの高速化やパフォーマンス向上の手法についてお話します。ご興味のある方はふるってご参加ください。


第 1 部:Making the Web Fast with PageSpeed

PageSpeed ​​は、サイト所有者が自身のサイトを最適化し、そのプロセスを自動化をする Google によるプロジェクト スイートです:Insights はお勧めを提案します。mod_pagespeed と ngx_pagespeed はサイトの最適化プロセスを自動化するオープンソースプロジェクトです。PageSpeed​ Service は、2013 年に提供開始を予定している Google の新しい最適化サービスです。本講演では、PageSpeed がどのように動き、どこに向かい、皆さんのサイトでどのように役立つかについて、詳しく見ていきます。

PageSpeed is a family of Google projects to help site owners optimize their sites, and to automate the optimization process: insights product delivers recommendations, mod_pagespeed and ngx_pagespeed are open-source projects which automate the site optimization process, and PageSpeed Service is a new Google hosted optimization service to be launched in 2013. In this talk we'll look under the hood of PageSpeed to see how it works, where it's heading, and how you can take advantage of it on your own site!

第 2 部:Wait, Chrome DevTools can do THAT?

皆さんが使われているブラウザは、(あなたがまだ気付かれていないだけで)最高の計測用の開発プラットフォームの 1 つです。もちろん、ソースコードを調べ、DOM を解析し、CSS をいじって、さらにいくつかの JavaScript の式を評価することができますが、できることはまだまだあります!本講演では、ウェブアプリケーションのパフォーマンスに関する問題を発見し、デバッグするのを手助けするヒントやトリック、隠れた機能をご紹介します。

Your browser is one of the most and best instrumented development platforms – you may just not realize it yet. Of course, you can inspect the source, walk the DOM, fiddle with the CSS, and even evaluate some Javascript expressions, but there is so much more! We'll take a look at a collection of tips, tricks, and hidden features in Chrome to help you find performance problems and debug your web applications!

<イベント内容>

名称:Chrome Tech Talk Night #5
日時:2013 年 1 月 31 日(木) 19:30 - 21:00 (受付 19:00 〜 19:30)
   ※ 終了後、懇親会(軽食付き)を行う予定です。
場所:Google 東京オフィス 六本木ヒルズ森タワー 30 階
会費:無料
主催:Google
内容:PageSpeed を利用したウェブアプリケーションのパフォーマンス向上の手法、Chrome Dev Tools を利用したパフォーマンス測定方法をご紹介します。

※ 英日逐次通訳あり
※ 当日はライブ配信を行う予定です (ただし、諸事情により実施しない場合があります)。

<申し込み方法>

申し込みフォーム よりお申し込みください。
定員に達しましたので、締め切りました。多数のご応募ありがとうございます。

先着順による受付です。定員は 80 名です。定員になり次第、受付を締め切ります。
なお、参加証は 1 月 28 日(月)までに順次ご登録いただいたメールアドレス宛にお送りする予定です。

多くの皆様のご参加をお待ちしております。

Posted by 山崎富美 Developer Relations Team

[本記事は YouTube API Team が YouTube API Blog に投稿した「No WebView required, with native YouTube Player API for Android」という記事を元に翻訳・作成しています。詳しくは元記事をご覧ください。-山崎]

Android アプリに、高画質の動画再生機能を追加しやすくなりました。新しい YouTube Android Player API ...
Posted by 山崎富美 Developer Relations Team

[本記事は YouTube API Team が YouTube API Blog に投稿した「No WebView required, with native YouTube Player API for Android」という記事を元に翻訳・作成しています。詳しくは元記事をご覧ください。-山崎]

Android アプリに、高画質の動画再生機能を追加しやすくなりました。新しい YouTube Android Player API を使うことで、アプリ内に Youtube の動画を埋め込んだり、アプリ内で動画を再生したりできるようになります。

この API は Google I/O 2012 でもプリアナウンスされたもので、以下のような利点があります。
この API はまだ試用段階ですが、インターフェースの大幅な変更は予定されていません。

限界を決めるのはあなたの想像力と利用規約だけ

YouTubeAndroidPlayerApi.jar クライアント ライブラリを Android アプリに組み込む方法については、こちらをご覧ください。このライブラリはAndroid 用 YouTube アプリのバージョン 4.2.16 以上が動作する Android デバイスに対応しています。

YouTubeApiServiceUtil クラスの isYouTubeApiServiceAvailable メソッドでデバイスが対応しているかどうか確認できます。

単純に動画を埋め込むだけなら、YouTubeStandalonePlayer を使ってください。より洗練されたユーザー インターフェースを作成したければ、YouTubePlayerViewYouTubePlayerFragment をお試しください。フラグメントを使って、Video Wall アプリの使用例のように魅力的なアプリをつくることもできます。

以下のアプリを使ってみましょう

ここでは興味深いアプリをいくつか紹介します。ぜひ参考にしてみてください。
  • Flipboard では、興味のあるニュースや人生の思い出深い場面など、あらゆる情報をまとめて閲覧できます。現在では、アプリを離れることなく Flipboard 内のどこからでも YouTube 動画を視聴できるようになっています。この機能によって、よりシームレスで一体感のある体験を実現しています。
  • BuzzFeed ではウェブ上の独創的な記事、スクープ、注目を集めているソーシャル コンテンツが配信されます。現在、Android ユーザーは YouTube 動画を使用した BuzzFeed 記事を BuzzFeed アプリ内で視聴したり、友だちと共有したりできるようになっています。
  • 9x9.tv は、厳選されたトピック別の動画を視聴できるアプリです。動画はテレビのようにいくつかのチャンネルに分かれています。開発元のブログには、API を使ってこのアプリを開発した際の体験談が掲載されています。
  • SoundTracking は携帯電話やタブレットを使って、音楽やお気に入りのジャム セッションを家族や友だちと共有できるアプリです。現在、ユーザーはミュージック タイムラインに現れる楽曲の YouTube ミュージック ビデオをアプリ内で再生できるようになっています。
  • Skimble の Fitness Flow では、プロのトレーナーによる高画質のエクササイズ ビデオを観ながらシェイプアップできます。このアプリでは YouTube のストリーム再生により、Android 携帯や Android タブレットでコンテンツを視聴できます。
紹介したアプリの画像です。Google Play から今すぐダウンロードすることもできます。

Flipboard BuzzFeed Fitness Flow by Skimble

さらに詳しく知るには…

YouTube Android Player API については、こちらにより詳しい説明が記載されています。また、役に立つと思われる動画をこちらにまとめております。最新の情報を確認するには、 YouTube for Developers チャンネルへの登録をお願いします。


サンプル コードを確認する

この新しい API の使い方を理解してもらうため、サンプルのコードをいくつか用意しました。サンプルは code.google.com に掲載されています。サンプルの説明はこちらから確認できます。なお、YouTube API に関するサポートは、先日より StackOverflow に移行しています。不明な点がある場合は、こちらをご利用ください。



-- Ross McIlroy, Anton Hansson, and Horia Ciurdar, YouTube Mobile Team

Posted by 山崎富美 Developer Relations Team

[Google 日本語入力チームのソフトウェアエンジニア、小松弘幸から Google 日本語入力の安定版のアップデートについての寄稿をもらいました。- 山崎]

新しい年になりました。今年も Google 日本語入力をよろしくお願いいたします。年末年始はいかがお過ごしでしたでしょうか?クリスマスやお正月が、もうずいぶんと前のことのように感じられます ...
Posted by 山崎富美 Developer Relations Team

[Google 日本語入力チームのソフトウェアエンジニア、小松弘幸から Google 日本語入力の安定版のアップデートについての寄稿をもらいました。- 山崎]

新しい年になりました。今年も Google 日本語入力をよろしくお願いいたします。年末年始はいかがお過ごしでしたでしょうか?クリスマスやお正月が、もうずいぶんと前のことのように感じられます。


さて、Google 日本語入力安定版 (Win, Mac) をアップデートしたことをお知らせします。既に Google 日本語入力安定版をお使いの場合は自動的に更新されますので、そのままお待ちください。

主な変更点は以下のようになります。

共通の変更点
  • Web から構築した辞書を更新しました。
  • 変換エンジンを 25% 高速化しました。
既知の不具合
  • Windows 8 環境での既知の不具合についてはプロダクト フォーラム内の特設スレッドをご覧ください。
ところで、Google 日本語入力では「ことし」から「2013 年」や「平成25年」に変換したり、「きょう」から今日の日付を変換することができます。この時期は、ついつい間違えそうになりますが、これでバッチリですね。


これからも、Google 日本語入力をよりよくしようと、チーム一同で開発を進めていきます。お気づきの点がありましたら、ぜひプロダクト フォーラムからお知らせください。みなさんのフィードバックがなによりの励みになります。

【2013年1月28日追記】 

細かいバグを修正したバージョン (安定版: 1.8.1310.x, 開発版: 1.8.1314.10x) をリリースしました。以前のバージョンでは、二番目以降の候補を取得するロジックに不具合があり、期待する候補が表示されない問題がありました。

Posted by 山崎富美 Developer Relations Team

1 月 23 日(水)に Google App Engine コミュニティの主催で、appengine ja night #23 が開催されます。

今回は Google 本社から来日している Developer Relations チームのメンバーがスピーカーとして参加し、Google App Engine や Google Compute Engine の最新情報をお伝えする予定です。ぜひご参加ください ...
Posted by 山崎富美 Developer Relations Team

1 月 23 日(水)に Google App Engine コミュニティの主催で、appengine ja night #23 が開催されます。

今回は Google 本社から来日している Developer Relations チームのメンバーがスピーカーとして参加し、Google App Engine や Google Compute Engine の最新情報をお伝えする予定です。ぜひご参加ください。

App Engine アプリの最適化と Appstats 
講演者:Johan Euphrosine (proppy), Developer Programs Engineer, Google Inc. 
App Engine アプリ設計や Datastore 利用におけるアンチパターンとベストプラクティスをはじめ、Appstats による最適化の方法を紹介します。
参考 URL: http://proppy-appstats.appspot.com/
※通訳あり、英語->日本語

Google Compute Engine 最新動向と App Engine 連携
講演者:Brian Dorsey, Developer Programs Engineer, Google Inc.
昨年の Google I/O 2012 で発表された IaaS サービス、Google Compute Engine の最新動向を紹介するほか、Google App Engine との連携のテクニックを日本語で解説します。

<イベント概要>
名称 : appengine ja night #23
日時 : 2013 年 1 月 23 日(水) 19:00〜21:00 (受付 18:30 - 19:30 )
          ※終了後、懇親会(ビールとピザの軽食つき)を行う予定です。
会場 : Google 東京オフィス
          東京都港区六本木 6 - 10 - 1 六本木ヒルズ森タワー 27F
主催 : appengine ja night
協力:Google
会費 : 無料 

※当日はライブ配信を行う予定です(ただし、諸事情により実施しない場合があります)。
※プログラムは変更する場合があります。

<申込方法>
申し込みフォームよりお申し込みください。 先着順による受付です。定員は 100 名です。本イベントは定員に達したため、受付を締め切りました。

なお、参加証は 1 月 18 日(金)より順次ご登録いただいたメール アドレス宛にお送りする予定です。

Posted by 山崎富美 Developer Relations Team

新年あけましておめでとうございます。

 昨年はたくさんの皆様に Google の Developer Relations の活動にご協力を頂き、まことにありがとうございました。本年もどうぞよろしくお願いします。 

さて、今年初のブログポストは、へび年にちなんだシンプルなゲーム「 Google 年賀状 2013」をお楽しみください ...
Posted by 山崎富美 Developer Relations Team

新年あけましておめでとうございます。

 昨年はたくさんの皆様に Google の Developer Relations の活動にご協力を頂き、まことにありがとうございました。本年もどうぞよろしくお願いします。 

さて、今年初のブログポストは、へび年にちなんだシンプルなゲーム「Google 年賀状 2013」をお楽しみください。