Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /home/3rd-i/www/3rdi-jp.com/wp-includes/pomo/plural-forms.php on line 210

Warning: Cannot modify header information - headers already sent by (output started at /home/3rd-i/www/3rdi-jp.com/wp-includes/pomo/plural-forms.php:210) in /home/3rd-i/www/3rdi-jp.com/wp-includes/feed-rss2.php on line 8
Tablet – mitsu site https://www.3rdi-jp.com あれこれ Tue, 16 Apr 2013 07:01:16 +0000 ja hourly 1 https://wordpress.org/?v=4.9.3 Androidタブレット用のクオリティチェックリスト https://www.3rdi-jp.com/android%e3%82%bf%e3%83%96%e3%83%ac%e3%83%83%e3%83%88%e7%94%a8%e3%81%ae%e3%82%af%e3%82%aa%e3%83%aa%e3%83%86%e3%82%a3%e3%83%81%e3%82%a7%e3%83%83%e3%82%af%e3%83%aa%e3%82%b9%e3%83%88/ https://www.3rdi-jp.com/android%e3%82%bf%e3%83%96%e3%83%ac%e3%83%83%e3%83%88%e7%94%a8%e3%81%ae%e3%82%af%e3%82%aa%e3%83%aa%e3%83%86%e3%82%a3%e3%83%81%e3%82%a7%e3%83%83%e3%82%af%e3%83%aa%e3%82%b9%e3%83%88/#respond Thu, 24 Jan 2013 08:04:20 +0000 http://www.3rdi-jp.com/?p=409 関連記事はありません ]]> Samsung –Google Unveils the Highest Resolution Tablet Nexus 10

Androidタブレット用のアプリケーション開発って、どんな所に気をつけて作ればよいのか?の調査が必要となりましたので、色々と調べていたら、本家Googleが、Androidタブレット用のクオリティチェックリスト、「Tablet App Quality Checklist」を公開していました。
(http://developer.android.com/intl/ja/distribute/googleplay/quality/tablet.html)

英語のみの提供なので、ざっくり翻訳してみました。
Google翻訳をベースとしていますので、精度が低いかもしれませんが、お役に立てれば幸いです。

内容的におかしいところや間違いが有りましたらご指摘頂けると助かります。

以下内容です。

タブレットアプリクオリティチェックリスト

チェックリスト目次

  1. 基本的なアプリの品質に関するテストを行う。(http://developer.android.com/intl/ja/distribute/googleplay/quality/core.html)
  2. レイアウトをタブレット向けに最適化する。
  3. 拡大化された画面を有効活用する
  4. タブレット用にデザインされたパーツを利用する
  5. 文字やタッチアイテムの調整を行う
  6. ホームスクリーンウィジェットの調整を行う
  7. アプリのフル機能を提供する
  8. タブレットに無いハードウエア機能を利用しない
  9. 多くのスクリーンサイズに対応出来るようにする
  10.  効率的にGoogle Playに公開する

Google Playでアプリを公開する前に、アプリが魅力的な機能と直感的で良く設計されたUIを介してタブレットのユーザの基本的な期待を満たしていることを確認することが重要です。

Android端末の中で成長しているタブレットには、ユーザの関心と収益化のための新たな機会を提供しています。アプリがタブレットのユーザをターゲットにしている場合、このドキュメントに書かれている、重要な品質の側面、機能セット、UIに焦点を当てることで、アプリの成功に重大な影響を及ぼすことができます。いくつかの小さなタスクやベストプラクティスで構成される各項目は、チェックリストとして利用できます。

以下のリストには便宜上番号が付いていますが、開発するアプリにあった順番でチェックできます。よりよいアプリをユーザに提供するために、出来る限り以下のチェックリストに従って下さい。

1. 基本的なアプリの品質に関するテストを行う。

良いタブレットアプリのエクスペリエンスをユーザに提供する為に行う、最初のチェックポイントは、そのアプリがターゲット端末で基本的なアプリの品質を満たしているかどうかのチェックです。詳細は、基本的なアプリの品質チェックリスト(http://developer.android.com/intl/ja/distribute/googleplay/quality/core.html)を参照して下さい。

基本的なアプリの品質やタブレットアプリの品質の評価を行うために、適切なハードウエアを用意するかエミュレータ環境をセットアップする必要があります。詳細については、テスト環境のセットアップ方法(http://developer.android.com/intl/ja/distribute/googleplay/quality/tablet.html#test-environment)を参照して下さい。

関連ドキュメント:

2. レイアウトをタブレット向けに最適化する。

Androidは幅広い画面サイズや機能の異なる端末で動作するアプリを容易に開発出来ます。この汎用的な互換性は、一つのアプリで多様な端末への対応が行えるので、開発を容易にします。ただし、どんな画面サイズのユーザにも満足してもらえるように、タブレットでは特にレイアウトやUIコンポーネントを最適化する必要があります。タブレットでは、アプリのレイアウトやUIコンポーネントを最適化することで、新しい機能、新たな内容の提供、その他のユーザの満足度を上げるエクスペリエンスを提供する事が出来ます。

もし、すでにスマホ用のアプリを開発済みで、タブレット用に公開したい場合、レイアウト・フォント・余白の少しの調整から始めることが出来ます。このような、7インチタブレット用や大画面用のゲーム向けなどの場合、これらの変更がアプリの出来栄えを良くします。もう少し大きなタブレットの場合、一部のUIを、複数の段落を持ち簡易ナビゲーションと追加コンテンツからなる「ストレッチUI」にデザインし直すことができます。

以下、いくつかの方法です。

  • 専用のレイアウトを「large」スクリーンと「xlarge」スクリーン用に用意します。もちろん、最小画面サイズか最小の幅と高さによるデザインも用意します。
  • 最低でも、大きい画面用のフォントサイズ・文字間隔・余白を改善し、コンテンツの読みやすさなどをカスタマイズします。
  • 横向きでも縦向きでも容易に操作できるUIの調整を行います。
  • タブレット用にはスマホ用よりも広い余白を適用します。48dpの間隔(16dpのグリッド)が推奨されています。(48dpの説明 http://developer.android.com/intl/ja/design/style/metrics-grids.html#48dp-rhythm)
  • スクリーンの隅に直接沿ったテキストを配置しないようにする。最低でも16dpの余白をコンテンツの周りに確保する。

特に、レイアウトが画面の横幅を有効利用した「ストレッチ」ではない場合。

  • 行が長すぎないようにします。最大でも1行あたり100文字以内に設定します。50~75文字が最適な状態です。
  • ListViewやmenuが横幅いっぱいにならないようにします。
  • 画面要素の幅調整に余白を使うかタブレット用に2カラムレイアウトに変更します。(次の項目を参照して下さい。)

関連項目:

3.タブレットならではの画面領域を活用する

特に横向きの場合、タブレットは、アプリが利用できる画面領域を広く持てます。特に10インチのタブレットは多くの画面領域が利用できます。7インチであっても、ユーザがコンテンツにアクセスする画面領域を更に提供してくれます。アプリがタブレットで実行される時のUIについて考える時、タブレット特有の画面領域による利点を考慮します。

以下、いくつかの方法です。

  • 新たな追加コンテンツを含めるか、既存のコンテンツのタブレット向けの代替物を利用します。
  • 2カラムレイアウトを利用して、単一画面を複合画面にまとめます。この方法は、画面領域を有効に活用できますし、利用者はより簡単にアプリを操作可能となります。
  • スクリーンの向きが変わった時にどのように複合画面が構成されるかを再編成します。
  • 一つの画面は一つのActivityサブクラスとして実装されますが、Fragmentサブクラスとして、それぞれのパネルを実装することを考慮して下さい。この様にすることで、その共有コンテンツの異なる端末間や画面間でコードを最大限に再利用することができます。
  • 例えば、large/xlargeなどのスクリーンサイズによって、または、sw600dp/sw720などの最小幅によって、異なるレイアウトを提供するのかなど、どの画面サイズで2カラム画面を利用するのかを決定します。

関連項目:

●Multi-pane Layouts (http://developer.android.com/design/patterns/multi-pane-layouts.html) Androidのマルチカラムレイアウトのデザインガイドライン。タブレットUIに、メニューやより多くのコンテンツを追加する方法などの例も紹介されています。
●Planning for Multiple Touchscreen Sizes (http://developer.android.com/training/design-navigation/multiple-sizes.html) Androidトレーニングクラスでは、タブレットとその他端末用の直感的で効果的なナビゲーションの計画について学習出来ます。
●Designing for Multiple Screens (http://developer.android.com/training/multiscreen/index.html) Androidトレーニングクラスでは、タブレットとその他端末用の直感的で効果的なナビゲーションの計画について学習出来ます。

4. タブレット用にデザインされたアイコンやパーツを利用する

アプリの見栄えを良くするために、タブレット用に用意されたアイコンやその他のビットマップパーツを使用します。具体的には、一般的にタブレットでサポートされている範囲のそれぞれに対応した密度のビットマップセットを作る必要があります。

アイコンのタイプ別のサイズ

Density Launcher Action Bar Small/Contextual Notification
mdpi 48x48px 32x32px 16x16px 24x24px
hdpi 72x72px 48x48px 24x24px 36x36px
tvdpi (use hdpi) (use hdpi) (use hdpi) (use hdpi)
xhdpi 96x96px 64x64px 32x32px 48x48px

考慮すべき他のポイント:

  • ランチャー、ノティフィケーション、アクションバーのアイコンは、アイコンデザインガイドラインに従いデザインし、物理サイズをタブレットとスマホで同じにします。
  • それぞれ個別のリソースが読み込まれるように、密度固有のリソース修飾子を使います。

関連項目:

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

もし、アプリにウィジェット機能があるようなら、タブレット用に最適化するいくつかのポイントがあります。

  • ウィジェットの最小サイズと最大サイズを考慮し、ウィジェットのデフォルトの幅と高さをタブレットに最適化します。
  • ウィジェットは、5行がそれ以上(縦長か正方形の場合)または、5列かそれ以上(横長か正方形の場合)で、420dpかそれ以上の大きさにリサイズします。
  • 9パッチを利用している画像が正しく表示されているかどうかを確認します。
  • システムのデフォルト余白に設定します。
  • 可能であれば、SDKのターゲットバージョンを14以上に設定します。

関連項目:

7. タブレットにフル機能を対応させる

タブレット使用者にアプリのフル機能を提供します。以下、いくつかのポイントです。

  • 少なくとも、スマフォ版にある機能はタブレット版でも実装する。
  • 多くのタブレットで使用されていないかハードウエアの実装がない場合には、その機能を無くすか、その機能と同等の機能で代替します。以下その例です。
    • スマホでは通話機能がありますが、現在のところタブレットではサポートされておりませんので、機能を省くか他の機能に置き換えます。
    • ほとんどのタブレットはGPSを実装していますが、ほとんどのユーザはジョギングをする時にタブレットは携帯しません。もし、スマホ用アプリがGPSでジョギングのログを記録するようなものであった場合、タブレットで利用されるケースではないので、タブレット用にその機能を実装する必要はありません。
  • タブレットのUIから機能や能力を省く場合、ユーザにアクセスできないようにするか、他の代替機能を提供します。(ハードウエアの機能に関する事項も参照)

8. タブレットに無いハードウエア機能を利用しない

スマホとタブレットには、センサー、カメラ、通話機能などの多少異なる機能があります。例えば、タブレットはWi-Fiはサポートしますが、通話機能をサポートしません。

すべてのユーザに単一のAPKファイルでのアプリ提供を実現するために、アプリに通常タブレットに搭載されていないハードウエア機能が必要でないかを調査します。

  • 「android:required=”false”」属性が設定されている時を除いて、アプリのmanifestに、タブレットに存在しないハードウエア機能や能力の「<uses-feature>」要素を含まないようにする。
    以下の様な機能を含まないようにします。

    • android.hardware.telephony
    • android.hardware.camera (refers to back camera), or
    • android.hardware.camera.front
  • 同様に、「<uses-feature>」要素に「android:required=”false”」属性が設定されている時を除いて、タグレットに実装されていない機能について「<permission>」要素を指定しない。

全てのケースで、通常アプリはハードウエアの機能がなければ動きません、それに代わる機能が提供される必要があります。例えば、GPSがサポートされていない端末であれば、ユーザが手動で位置を設定する機能を提供します。アプリは、ハードウエアを実働させチェックを行います。

関連項目:

9. 多くのスクリーンサイズに対応出来るようにする

多くのタブレットにアプリを配布するためには、manifestで定義された画面サイズに対応します。

  • 必要に応じて、「<supports-screens>」要素に適切な属性を追加する。
  • 「<compatible-screens>」要素がmanifestに定義してあれば、その要素には、アプリがサポートする全てのサイズと密度の組み合わせに関して、属性の追加が必須です。もし可能であれば、この要素を利用しなくても構いません。

関連項目:

10. 効率的にGoogle Playに公開する

  • 全てのスクリーンサイズのスマホ・タブレットに対応するアプリを一つのAPKファイルで公開する。
    • ユーザがアプリを、検索・閲覧・プロモーションで見つけやすくする。
    • ユーザが新しい端末を購入した時にアプリを簡単に復元できる。
    • アプリのダウンロードステータスや順位が、すべての端末の情報を統合して集計される。
    • タブレット用のアプリを別に公開すると、ブランドの評価が分散されます。
  • もし必要であれば、代替案として「Multiple APK Support(http://developer.android.com/intl/ja/google/play/publishing/multiple-apks.html)」を使って公開する方法があります。もちろん、一つのAPKファイルでの配布をお勧めします。
  • アプリ紹介ページで、タブレットの機能を目立たせるようにします。
    • 少なくとも1つのタブレットアプリが動作している画面キャプチャを追加します。可能であれば、画面の向きが縦・横のキャプチャをそれぞれ1つ追加することをお勧めします。これらの画面キャプチャは、アプリがタブレットに最適化されていることを明確に伝えます。
    • アプリの説明にタブレットに対応していることを明記する。
    • アプリのリリース情報とアップデート情報にタブレット対応について追加する。
    • アプリのプロモーションビデオにタブレットの情報を追加する。
  • アプリを配布設定する時に、「Developer Console」のサポート端末一覧で、ターゲットにしている端末のチェックが外れていないかを確認します。
  • ユーザにアプリを知ってもらう為に、マーケティング・広告キャンペーンの計画を練ります。

関連項目:

photo by: samsungtomorrow
]]>
https://www.3rdi-jp.com/android%e3%82%bf%e3%83%96%e3%83%ac%e3%83%83%e3%83%88%e7%94%a8%e3%81%ae%e3%82%af%e3%82%aa%e3%83%aa%e3%83%86%e3%82%a3%e3%83%81%e3%82%a7%e3%83%83%e3%82%af%e3%83%aa%e3%82%b9%e3%83%88/feed/ 0