diff options
Diffstat (limited to 'docs/html-intl/ja/training')
9 files changed, 1018 insertions, 0 deletions
diff --git a/docs/html-intl/ja/training/monitoring-device-state/battery-monitoring.jd b/docs/html-intl/ja/training/monitoring-device-state/battery-monitoring.jd new file mode 100644 index 0000000..c4aafe4 --- /dev/null +++ b/docs/html-intl/ja/training/monitoring-device-state/battery-monitoring.jd @@ -0,0 +1,120 @@ +page.title=電池残量と充電状態の監視 +parent.title=電池消費量の最適化 +parent.link=index.html + +trainingnavtop=true +next.title=ホルダーの装着状態とタイプの特定と監視 +next.link=docking-monitoring.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンの内容</h2> +<ol> + <li><a href="#DetermineChargeState">現在の充電状態を特定する</a></li> + <li><a href="#MonitorChargeState">充電状態の変化を監視する</a></li> + <li><a href="#CurrentLevel">現在の電池残量を特定する</a></li> + <li><a href="#MonitorLevel">電池残量の大きな変化を監視する</a></li> +</ol> + +<h2>関連項目</h2> +<ul> + <li><a href="{@docRoot}guide/components/intents-filters.html">インテントとインテント フィルタ</a> +</ul> + +</div> +</div> + +<p>バックグラウンド更新が電池消費量に及ぼす影響を抑えるために更新の頻度を変更するには、初めに現在の電池残量と充電状態を調べることをおすすめします。</p> + +<p>アプリの更新が電池消費量に及ぼす影響の度合いは、端末の電池残量と充電状態によって異なります。AC 電源から端末を充電しているときは、更新の実行による影響はごくわずかなので、ほとんどの場合は、端末が AC 電源に接続されている限り、更新頻度を最大にして差し支えありません。逆に、端末が電池で駆動しているときは、更新頻度を下げると電池消費量を抑えることができます。</p> + +<p>同様に、電池残量を調べると、残量がごくわずかであるときに更新頻度を下げたり、場合によっては停止させたりすることができます。</p> + + +<h2 id="DetermineChargeState">現在の充電状態を特定する</h2> + +<p>初めに、現在の充電状態を特定します。{@link android.os.BatteryManager} によって電池と充電状態に関するすべての詳細情報が sticky {@link android.content.Intent} としてブロードキャストされますが、この中に充電状態が格納されています。</p> + +<p>これは sticky インテントであるため、{@link android.content.BroadcastReceiver} を登録する必要はありません。{@code registerReceiver} を呼び出し、{@code null} をレシーバとして渡すだけで（次のコード例を参照）、現在の電池状態のインテントが返されます。ここで実際の {@link android.content.BroadcastReceiver} オブジェクトを渡すこともできますが、このレッスンでは後で更新についての処理を行うので、これは必要ありません。</p> + +<pre>IntentFilter ifilter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED); +Intent batteryStatus = context.registerReceiver(null, ifilter);</pre> + +<p>現在の充電状態に加えて、充電中の場合は USB 経由か AC 充電器経由かを調べることもできます。<p> + +<pre>// Are we charging / charged? +int status = batteryStatus.getIntExtra(BatteryManager.EXTRA_STATUS, -1); +boolean isCharging = status == BatteryManager.BATTERY_STATUS_CHARGING || + status == BatteryManager.BATTERY_STATUS_FULL; + +// How are we charging? +int chargePlug = battery.getIntExtra(BatteryManager.EXTRA_PLUGGED, -1); +boolean usbCharge = chargePlug == BATTERY_PLUGGED_USB; +boolean acCharge = chargePlug == BATTERY_PLUGGED_AC;</pre> + +<p>一般的には、端末が AC 充電器に接続されているときはバックグラウンド更新の頻度を最大にし、USB 経由で充電中のときは頻度を下げ、電池で駆動中のときはさらに頻度を下げます。</p> + + +<h2 id="MonitorChargeState">充電状態の変化を監視する</h2> + +<p>充電状態は、端末が充電器に接続されたときにすぐに変化するので、充電状態の変化を監視し、その変化に応じて更新の頻度を変更することが重要です。</p> + +<p>{@link android.os.BatteryManager} は、端末が電源に接続されたときや接続が解除されたときに、アクションをブロードキャストします。このようなイベントは、アプリが実行中でないときでも受信することが重要です。特にそのイベントが、アプリのバックグラウンド更新を開始するためにアプリを起動させる頻度に影響するものである場合です。したがって、{@link android.content.BroadcastReceiver} をアプリのマニフェスト内で登録し、両方のイベントを受信するために {@link android.content.Intent#ACTION_POWER_CONNECTED} と {@link android.content.Intent#ACTION_POWER_DISCONNECTED} をインテント フィルタ内で定義します。</p> + +<pre><receiver android:name=".PowerConnectionReceiver"> + <intent-filter> + <action android:name="android.intent.action.ACTION_POWER_CONNECTED"/> + <action android:name="android.intent.action.ACTION_POWER_DISCONNECTED"/> + </intent-filter> +</receiver></pre> + +<p>関連付けられている {@link android.content.BroadcastReceiver} 実装の中で、前のステップで説明したように、現在の充電状態と充電方法を抽出します。</p> + +<pre>public class PowerConnectionReceiver extends BroadcastReceiver { + @Override + public void onReceive(Context context, Intent intent) { + int status = intent.getIntExtra(BatteryManager.EXTRA_STATUS, -1); + boolean isCharging = status == BatteryManager.BATTERY_STATUS_CHARGING || + status == BatteryManager.BATTERY_STATUS_FULL; + + int chargePlug = intent.getIntExtra(BatteryManager.EXTRA_PLUGGED, -1); + boolean usbCharge = chargePlug == BATTERY_PLUGGED_USB; + boolean acCharge = chargePlug == BATTERY_PLUGGED_AC; + } +}</pre> + + +<h2 id="CurrentLevel">現在の電池残量を特定する</h2> + +<p>状況によっては、現在の電池残量がわかると便利なことがあります。たとえば、電池残量が所定のレベルを下回った場合にアプリのバックグラウンド更新の頻度を下げることができます。</p> + +<p>現在の電池残量を調べるには、次に示すように、電池状態のインテントから現在の電池残量と最大量を抽出します。</p> + +<pre>int level = battery.getIntExtra(BatteryManager.EXTRA_LEVEL, -1); +int scale = battery.getIntExtra(BatteryManager.EXTRA_SCALE, -1); + +float batteryPct = level / (float)scale;</pre> + + +<h2 id="MonitorLevel">電池残量の大きな変化を監視する</h2> + +<p>電池状態を継続的に監視することは簡単ではありませんが、その必要もありません。</p> + +<p>一般的に、電池残量を継続的に監視するほうが、電池への影響はアプリの通常の動作によるものよりも大きくなるため、電池残量の大きな変化のみを監視することをおすすめします。特に、端末が電池残量低下状態に入ったときや、その状態が解消されたときです。</p> + +<p>次に示すマニフェストの断片は、ブロードキャスト レシーバの中にあるインテント フィルタ要素からの抜粋です。このレシーバは、端末が電池残量低下状態に入ったときや、その状態が解消されたときに呼び出されます。そのために、{@link android.content.Intent#ACTION_BATTERY_LOW} と {@link android.content.Intent#ACTION_BATTERY_OKAY} を受信します。</p> + +<pre><receiver android:name=".BatteryLevelReceiver"> +<intent-filter> + <action android:name="android.intent.action.ACTION_BATTERY_LOW"/> + <action android:name="android.intent.action.ACTION_BATTERY_OKAY"/> + </intent-filter> +</receiver></pre> + +<p>一般的に、電池残量がごくわずかになったときはアプリのバックグラウンド更新をすべて停止することをおすすめします。データがいくら新しくても、端末自体の電源が切れてしまったのではデータを活用できません。</p> + +<p>多くの場合、端末の充電という動作が開始するのは、端末がホルダーにセットされるのと同時です。次のレッスンでは、現在のホルダーの状態を特定し、端末のホルダー装着状態の変化を監視する方法を紹介します。</p> + diff --git a/docs/html-intl/ja/training/monitoring-device-state/connectivity-monitoring.jd b/docs/html-intl/ja/training/monitoring-device-state/connectivity-monitoring.jd new file mode 100644 index 0000000..82b0c6b --- /dev/null +++ b/docs/html-intl/ja/training/monitoring-device-state/connectivity-monitoring.jd @@ -0,0 +1,70 @@ +page.title=接続状態の特定と監視 +parent.title=電池消費量の最適化 +parent.link=index.html + +trainingnavtop=true + +previous.title=ホルダーの装着状態とタイプの特定と監視 +previous.link=docking-monitoring.html +next.title=オンデマンドでのブロードキャスト レシーバ操作 +next.link=manifest-receivers.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンの内容</h2> +<ol> + <li><a href="#DetermineConnection">インターネット接続の有無を特定する</a></li> + <li><a href="#DetermineType">インターネット接続のタイプを特定する</a></li> + <li><a href="#MonitorChanges">接続状態の変化を監視する</a></li> +</ol> + + +<h2>関連項目</h2> +<ul> + <li><a href="{@docRoot}guide/components/intents-filters.html">インテントとインテント フィルタ</a> +</ul> + +</div> +</div> + +<p>反復アラームとバックグラウンド サービスの用途のうち代表的なものとしては、インターネット リソースからアプリのデータを定期的に更新するためのスケジュール設定や、データのキャッシュへの格納、長時間に及ぶダウンロードの実行などがあります。しかし、インターネットに接続されていないときや、速度が低すぎるためにダウンロードを完了できない場合にまで、更新をスケジューリングするために端末をスリープ状態から復帰させる必要があるでしょうか。</p> + +<p>{@link android.net.ConnectivityManager} を使用すると、端末が実際にインターネットに接続されているかどうかと、接続されている場合の接続タイプを調べることができます。</p> + + +<h2 id="DetermineConnection">インターネット接続の有無を特定する</h2> + +<p>端末がインターネットに接続されていない場合は、インターネット リソースに基づく更新をスケジューリングする必要性はありません。次のスニペットは、{@link android.net.ConnectivityManager} を使用してアクティブなネットワークを問い合わせて、インターネットに接続しているかどうかを特定する方法を示すものです。</p> + +<pre>ConnectivityManager cm = + (ConnectivityManager)context.getSystemService(Context.CONNECTIVITY_SERVICE); + +NetworkInfo activeNetwork = cm.getActiveNetworkInfo(); +boolean isConnected = activeNetwork.isConnectedOrConnecting();</pre> + + +<h2 id="DetermineType">インターネット接続のタイプを特定する</h2> + +<p>現在使用可能なインターネット接続のタイプも調べることができます。</p> + +<p>端末の接続のタイプとしては、モバイル データ、WiMAX、Wi-Fi、イーサネットがあります。次に示すように、アクティブなネットワークのタイプを問い合わせると、使用可能な帯域幅に合わせて更新頻度を変更することができます。</p> + +<pre>boolean isWiFi = activeNetwork.getType() == ConnectivityManager.TYPE_WIFI;</pre> + +<p>モバイル データ接続のコストは Wi-Fi 接続を大きく上回る傾向があるため、端末がモバイル接続しているときはアプリの更新頻度を下げるのが一般的です。同様に、大量のデータをダウンロードするときは、Wi-Fi 接続されるまで停止するとよいでしょう。</p> + +<p>更新を停止した場合は、接続状態の変化を受信することが重要です。インターネット接続が確立されたら更新を再開できるようにするためです。</p> + + +<h2 id="MonitorChanges">接続状態の変化を監視する</h2> + +<p>接続状態の詳細が変化すると、{@link android.net.ConnectivityManager} によって {@link android.net.ConnectivityManager#CONNECTIVITY_ACTION}（{@code "android.net.conn.CONNECTIVITY_CHANGE"}）アクションがブロードキャストされます。アプリのマニフェスト内でブロードキャスト レシーバを登録し、このような変化を検出することで、それに応じてアプリのバックグラウンド更新を再開（または停止）することができます。</p> + +<pre><action android:name="android.net.conn.CONNECTIVITY_CHANGE"/></pre> + +<p>端末の接続状態の変化は、きわめて頻繁になることもあります。このブロードキャストは、モバイル データ接続と Wi-Fi 接続とが切り替わるたびに発行されるからです。したがって、このブロードキャストの監視は、更新やダウンロードを停止した後に再開すべきかどうかを判断するために限って行うことをおすすめします。一般的には、更新を開始する前にインターネット接続の有無を調べれば十分です。インターネットに接続していない場合は、再び接続されるまでの間、更新を停止します。</p> + +<p>このようにするには、マニフェスト内で宣言したブロードキャスト レシーバのオンとオフを切り替える必要があります。これについて、次のレッスンで説明します。</p> diff --git a/docs/html-intl/ja/training/monitoring-device-state/docking-monitoring.jd b/docs/html-intl/ja/training/monitoring-device-state/docking-monitoring.jd new file mode 100644 index 0000000..9c0e054 --- /dev/null +++ b/docs/html-intl/ja/training/monitoring-device-state/docking-monitoring.jd @@ -0,0 +1,74 @@ +page.title=ホルダーの装着状態とタイプの特定と監視 +parent.title=電池消費量の最適化 +parent.link=index.html + +trainingnavtop=true +previous.title= 電池残量と充電状態の監視 +previous.link=battery-monitoring.html +next.title= 接続状態の特定と監視 +next.link=connectivity-monitoring.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンの内容</h2> +<ol> + <li><a href="#CurrentDockState">オーディオ フォーカスをリクエストする</a></li> + <li><a href="#DockType">現在のホルダーのタイプを特定する</a></li> + <li><a href="#MonitorDockState">ホルダーの装着状態またはタイプの変化を監視する</a></li> +</ol> + + +<h2>関連項目</h2> +<ul> + <li><a href="{@docRoot}guide/components/intents-filters.html">インテントとインテント フィルタ</a> +</ul> + +</div> +</div> + +<p>Android 搭載端末を装着できるホルダーの種類には、さまざまなものがあります。たとえば、車載用や家庭用のホルダーがあり、デジタルかアナログかという区別もあります。ホルダー装着状態は一般的に、充電状態と密接にリンクしています。多くのホルダーは、装着されている端末に電力を供給しているからです。</p> + +<p>端末のホルダー装着状態が更新の頻度にどのように影響するかは、アプリによって異なります。たとえば、スポーツ センター アプリなら、卓上ホルダー装着時には更新頻度を上げ、カー ホルダー装着時には更新を完全に停止するとよいでしょう。逆に、カー ホルダー装着時に更新頻度を最大にするケースとしては、バックグラウンド サービスによって道路交通状況を更新する場合が考えられます。</p> + +<p>ホルダー装着状態も sticky {@link android.content.Intent} としてブロードキャストされるので、端末がホルダーに装着されているかどうかと、装着されている場合のホルダーのタイプを問い合わせることができます。</p> + + +<h2 id="CurrentDockState">現在のホルダー装着状態を特定する</h2> + +<p>ホルダー装着状態の詳細は、{@link android.content.Intent#ACTION_DOCK_EVENT} アクションの sticky ブロードキャストにエクストラとして含まれています。これは sticky であるため、{@link android.content.BroadcastReceiver} を登録する必要はありません。次のコード例に示すように、{@link android.content.Context#registerReceiver registerReceiver()} を呼び出し、{@code null} をブロードキャスト レシーバとして渡します。</p> + +<pre>IntentFilter ifilter = new IntentFilter(Intent.ACTION_DOCK_EVENT); +Intent dockStatus = context.registerReceiver(null, ifilter);</pre> + +<p>現在のホルダー装着状態は、次のように {@code EXTRA_DOCK_STATE} エクストラから抽出します。<p> + +<pre>int dockState = battery.getIntExtra(EXTRA_DOCK_STATE, -1); +boolean isDocked = dockState != Intent.EXTRA_DOCK_STATE_UNDOCKED;</pre> + + +<h2 id="DockType">現在のホルダーのタイプを特定する</h2> + +<p>端末がホルダーに装着されている場合のホルダーのタイプは、次の 4 つのいずれかです。 +<ul><li>カー</li> +<li>卓上</li> +<li>ローエンド（アナログ）卓上</li> +<li>ハイエンド（デジタル）卓上</li></ul></p> + +<p>最後の 2 つは、Android API レベル 11 で追加されたものです。したがって、ホルダーのタイプだけがわかればよく、デジタルとアナログの区別は問わないという場合は、次のように 3 つすべてについて調べるとよいでしょう。</p> + +<pre>boolean isCar = dockState == EXTRA_DOCK_STATE_CAR; +boolean isDesk = dockState == EXTRA_DOCK_STATE_DESK || + dockState == EXTRA_DOCK_STATE_LE_DESK || + dockState == EXTRA_DOCK_STATE_HE_DESK;</pre> + + +<h2 id="MonitorDockState">ホルダーの装着状態またはタイプの変化を監視する</h2> + +<p>端末がホルダーに装着されたり、装着が解除されたりするたびに、{@link android.content.Intent#ACTION_DOCK_EVENT} アクションがブロードキャストされます。端末のホルダー装着状態の変化を監視するには、次のコード例に示すように、アプリのマニフェスト内でブロードキャスト レシーバを登録します。</p> + +<pre><action android:name="android.intent.action.ACTION_DOCK_EVENT"/></pre> + +<p>レシーバ実装の中でホルダーのタイプと状態を抽出する方法は、前のステップで使用したものと同じです。</p> diff --git a/docs/html-intl/ja/training/monitoring-device-state/index.jd b/docs/html-intl/ja/training/monitoring-device-state/index.jd new file mode 100644 index 0000000..07897b1 --- /dev/null +++ b/docs/html-intl/ja/training/monitoring-device-state/index.jd @@ -0,0 +1,49 @@ +page.title=電池消費量の最適化 + +trainingnavtop=true +startpage=true +next.title=電池残量と充電状態の監視 +next.link=battery-monitoring.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>依存関係と前提条件</h2> +<ul> + <li>Android 2.0（API レベル 5）以上</li> + <li>「<a href="{@docRoot}guide/components/intents-filters.html">インテントとインテント フィルタ</a>」を読み終えていること</li> +</ul> + +<h2>関連項目</h2> +<ul> + <li><a href="{@docRoot}guide/components/services.html">サービス</a> +</ul> + +</div> +</div> + +<p>アプリを開発するときは、ホスト端末の電池消費量への影響を抑えるよう心がける必要があります。このクラスを修了すると、開発するアプリの中でホスト端末の状態を監視し、それに基づいて機能や動作を変更することができるようになります。</p> + +<p>接続が失われたときはバックグラウンド サービスの更新を停止する、電池残量が低下したときは更新の頻度を下げるといった対策を講じることにより、ユーザー エクスペリエンスを損なうことなく、アプリが電池消費量に及ぼす影響を最小限に抑えることができます。</p> + +<h2>レッスン</h2> + +<!-- Create a list of the lessons in this class along with a short description of each lesson. +These should be short and to the point. It should be clear from reading the summary whether someone +will want to jump to a lesson or not.--> + +<dl> + <dt><b><a href="battery-monitoring.html">電池残量と充電状態の監視</a></b></dt> + <dd>アプリの更新頻度を変更するために現在の電池残量や充電状態の変化を特定および監視する方法を学習します。</dd> + + <dt><b><a href="docking-monitoring.html">ホルダーの装着状態とタイプの特定と監視</a></b></dt> + <dd>最適な更新頻度は、ホスト端末がどのように使用されているかによって異なります。ホルダーの装着状態とタイプに応じてアプリの動作を変更するために、これらを特定および監視する方法を学習します。</dd> + + <dt><b><a href="connectivity-monitoring.html">接続状態の特定と監視</a></b></dt> + <dd>インターネットに接続していないときは、オンライン ソースからアプリを更新することはできません。接続状態を調べ、それに応じてバックグラウンド更新の頻度を変更する方法を学習します。また、大量の帯域幅を消費する処理を開始する前に接続が Wi-Fi かモバイル データかを調べる方法も学習します。</dd> + + <dt><b><a href="manifest-receivers.html">オンデマンドでのブロードキャスト レシーバ操作</a></b></dt> + <dd>マニフェスト内で宣言したブロードキャスト レシーバのオンとオフを実行時に切り替えます。端末の状態に応じて、不要なレシーバを無効にすることができます。効率を上げるために、状態変化レシーバのオンとオフを切り替える方法や、端末が特定の状態になるまでアクションを延期する方法を学習します。</dd> +</dl>
\ No newline at end of file diff --git a/docs/html-intl/ja/training/monitoring-device-state/manifest-receivers.jd b/docs/html-intl/ja/training/monitoring-device-state/manifest-receivers.jd new file mode 100644 index 0000000..7635d9f --- /dev/null +++ b/docs/html-intl/ja/training/monitoring-device-state/manifest-receivers.jd @@ -0,0 +1,50 @@ +page.title=オンデマンドでのブロードキャスト レシーバ操作 +parent.title=電池消費量の最適化 +parent.link=index.html + +trainingnavtop=true + +previous.title=接続状態の特定と監視 +previous.link=connectivity-monitoring.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンの内容</h2> +<ol> + <li><a href="#ToggleReceivers">効率を上げるために状態変化レシーバのオンとオフを切り替える</a></li> +</ol> + + +<h2>関連項目</h2> +<ul> + <li><a href="{@docRoot}guide/components/intents-filters.html">インテントとインテント フィルタ</a> +</ul> + +</div> +</div> + +<p>端末の状態変化を監視する最も単純な方法は、監視対象とする状態ごとに {@link android.content.BroadcastReceiver} を作成し、それぞれをアプリのマニフェスト内で登録するというものです。これらの各レシーバ内で、端末の現在の状態に基づいて反復アラームのスケジュールを再設定します。</p> + +<p>この方法のデメリットは、これらのレシーバのいずれかがトリガされるたびに端末がスリープから復帰することですが、このことは必要以上に頻繁に発生する可能性があります。</p> + +<p>これよりも良い方法は、実行時にブロードキャスト レシーバをオンまたはオフにするというものです。このようにすれば、マニフェスト内で宣言したレシーバを受動的アラームとして使用できます。つまり、このアラームは、必要なときにだけシステム イベントによって呼び出されます。</p> + + +<h2 id="ToggleReceivers">効率を上げるために状態変化レシーバのオンとオフを切り替える </h2> + +<p>{@link android.content.pm.PackageManager} を使用すると、マニフェスト内で定義されているコンポーネントの有効化状態を切り替えることができます。このコンポーネントにはブロードキャスト レシーバも該当するので、次に示すようにオンとオフを切り替えることができます。</p> + +<pre>ComponentName receiver = new ComponentName(context, myReceiver.class); + +PackageManager pm = context.getPackageManager(); + +pm.setComponentEnabledSetting(receiver, + PackageManager.COMPONENT_ENABLED_STATE_ENABLED, + PackageManager.DONT_KILL_APP)</pre> + +<p>この手法を使用すれば、接続が失われたことが判明した場合に、接続状態変化レシーバ以外のレシーバをすべて無効にすることができます。逆に、接続が確立された後は、接続状態変化の受信を停止します。オンラインかどうかを調べるのは、更新を実行する直前や、反復更新アラームのスケジュール再設定の直前だけで十分です。</p> + +<p>同じ手法を使用して、大量の帯域幅を必要とするダウンロードを延期することもできます。それには、接続状態の変化をリッスンするブロードキャスト レシーバを有効にしておき、端末が Wi-Fi に接続されたらダウンロードを開始します。</p> diff --git a/docs/html-intl/ja/training/multiscreen/adaptui.jd b/docs/html-intl/ja/training/multiscreen/adaptui.jd new file mode 100644 index 0000000..8b1e6ac --- /dev/null +++ b/docs/html-intl/ja/training/multiscreen/adaptui.jd @@ -0,0 +1,212 @@ +page.title=順応性のある UI フローの実装 +parent.title=複数画面のデザイン +parent.link=index.html + +trainingnavtop=true +previous.title=さまざまな画面密度のサポート +previous.link=screendensities.html + +@jd:body + + +<!-- This is the training bar --> +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンでの学習内容</h2> + +<ol> + <li><a href="#TaskDetermineCurLayout">現在のレイアウトを判別する</a></li> + <li><a href="#TaskReactToLayout">現在のレイアウトに合わせて応答する</a></li> + <li><a href="#TaskReuseFrag">他のアクティビティのフラグメントを再利用する</a></li> + <li><a href="#TaskHandleConfigChanges">画面設定の変更を処理する</a></li> +</ol> + +<h2>関連ドキュメント</h2> + +<ul> + <li><a href="{@docRoot}guide/practices/tablets-and-handsets.html">タブレットと携帯端末のサポート</a></li> +</ul> + +<h2>試してみる</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/NewsReader.zip" class="button">サンプル アプリのダウンロード</a> +<p class="filename">NewsReader.zip</p> +</div> + + +</div> +</div> + +<p>アプリが現在表示しているレイアウトによって、UI フローが異なる可能性があります。たとえば、アプリがデュアルペイン モードであれば、左ペインのアイテムをクリックすると、単に右ペインにコンテンツが表示されるだけですが、シングルペイン モードであれば、コンテンツは（別のアクティビティ内の）コンテンツ専用のペインに表示される必要があります。</p> + + +<h2 id="TaskDetermineCurLayout">現在のレイアウトを判別する</h2> + +<p>レイアウトによって実装が多少異なるので、まず、ユーザーが現在どのようなレイアウトを表示しているかを判別する必要があります。たとえば、ユーザーが表示しているレイアウトが「シングルペイン」モードなのか、「デュアルペイン」モードなのかを確認する必要があります。それは、以下のようなコードで、ある特定のビューが存在し、かつ可視になっているかを照会することで可能です:</p> + +<pre class="prettyprint"> +public class NewsReaderActivity extends FragmentActivity { + boolean mIsDualPane; + + @Override + public void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + setContentView(R.layout.main_layout); + + View articleView = findViewById(R.id.article); + mIsDualPane = articleView != null && + articleView.getVisibility() == View.VISIBLE; + } +} +</pre> + +<p>このコードにおいて「article」ペインが使用可能かどうかを照会している点に注目してください。特定のレイアウトの照会をハードコーディングするよりもはるかに柔軟性があります。</p> + +<p>その他にも、さまざまなコンポーネントでも対応できる方法として、コンポーネントを操作する前に使用可能かどうかを確認する方法もあります。たとえば、News Reader サンプル アプリでは、メニューを開くボタンがありますが、このボタンは Android 3.0 よりも古いバージョンで動作しているときにしか表示されません（この機能は、API レベル 11 以上の <PH>{@link android.app.ActionBar}</PH> で提供されるため）。そこで、以下のようなコードを追加して、このボタンのイベント リスナーを追加します:</p> + +<pre class="prettyprint"> +Button catButton = (Button) findViewById(R.id.categorybutton); +OnClickListener listener = /* create your listener here */; +if (catButton != null) { + catButton.setOnClickListener(listener); +} +</pre> + + +<h2 id="TaskReactToLayout">現在のレイアウトに合わせて応答する</h2> + +<p>現在のレイアウトによって、一部のアクションの結果が異なる可能性があります。たとえば、News Reader サンプルでは、見出しリストで見出しをクリックしたとき、デュアルペイン モードの UI の場合は右ペインに記事が表示されますが、シングルペインの UI の場合は別のアクティビティが起動します:</p> + +<pre> +@Override +public void onHeadlineSelected(int index) { + mArtIndex = index; + if (mIsDualPane) { + /* display article on the right pane */ + mArticleFragment.displayArticle(mCurrentCat.getArticle(index)); + } else { + /* start a separate activity */ + Intent intent = new Intent(this, ArticleActivity.class); + intent.putExtra("catIndex", mCatIndex); + intent.putExtra("artIndex", index); + startActivity(intent); + } +} +</pre> + +<p>同様に、アプリがデュアルペイン モードの場合は、ナビ用タブでアクション バーを設定し、一方、シングルペイン モードの場合は、スピナー ウィジェットでナビを設定することになります。したがって、コードでは以下のようにどちらのケースが適切かを調べることも必要です:</p> + +<pre> +final String CATEGORIES[] = { "トップ ニュース 政治", "政治", "経済", "Technology" }; + +public void onCreate(Bundle savedInstanceState) { + .... + if (mIsDualPane) { + /* use tabs for navigation */ + actionBar.setNavigationMode(android.app.ActionBar.NAVIGATION_MODE_TABS); + int i; + for (i = 0; i < CATEGORIES.length; i++) { + actionBar.addTab(actionBar.newTab().setText( + CATEGORIES[i]).setTabListener(handler)); + } + actionBar.setSelectedNavigationItem(selTab); + } + else { + /* use list navigation (spinner) */ + actionBar.setNavigationMode(android.app.ActionBar.NAVIGATION_MODE_LIST); + SpinnerAdapter adap = new ArrayAdapter<String>(this, + R.layout.headline_item, CATEGORIES); + actionBar.setListNavigationCallbacks(adap, handler); + } +} +</pre> + + +<h2 id="TaskReuseFrag">他のアクティビティのフラグメントを再利用する</h2> + +<p>複数の画面に対応するように設計する場合、あるパターンが繰り返されますが、そうしたパターンは、ある画面設定ではペインとして、別の画面設定では別のアクティビティとして実装されるインターフェースの一部に存在します。たとえば、News Reader サンプルでは、ラージ画面の場合はニュース記事のテキストが右ペインに表示されますが、それよりも小さい画面の場合は別のアクティビティになります。</p> + +<p>このような場合、通常、複数のアクティビティで同じ <PH>{@link android.app.Fragment}</PH> サブクラスを再利用することでコードの重複を回避できます。たとえば、<code>ArticleFragment</code> は以下のようにデュアルペイン レイアウトで使用されます:</p> + +{@sample development/samples/training/multiscreen/newsreader/res/layout/twopanes.xml all} + +<p>また、より小さな画面向けのアクティビティ レイアウト内では（レイアウトを使用せずに）再利用されます（<code>ArticleActivity</code>）:</p> + +<pre> +ArticleFragment frag = new ArticleFragment(); +getSupportFragmentManager().beginTransaction().add(android.R.id.content, frag).commit(); +</pre> + +<p>当然、これは XML レイアウトでフラグメントを宣言するのと同じ効果がありますが、この場合は、XML レイアウトは必要ありません。このアクティビティのコンポーネントは記事フラグメントしかないからです。</p> + +<p>フラグメントを設計する際に注意すべき非常に重要なポイントの 1 つとして、特定のアクティビティに対して強い結合を作成しないことがあります。通常、これは、フラグメントが自分のホスト アクティビティとやり取りするのに必要なあらゆる手段を抽象化したインターフェースを定義し、さらに、そのインターフェースをホスト アクティビティに実装することで可能になります:</p> + +<p>たとえば、News Reader アプリの <code>HeadlinesFragment</code> は、まさにそのようになっています:</p> + +<pre> +public class HeadlinesFragment extends ListFragment { + ... + OnHeadlineSelectedListener mHeadlineSelectedListener = null; + + /* Must be implemented by host activity */ + public interface OnHeadlineSelectedListener { + public void onHeadlineSelected(int index); + } + ... + + public void setOnHeadlineSelectedListener(OnHeadlineSelectedListener listener) { + mHeadlineSelectedListener = listener; + } +} +</pre> + +<p>これにより、ユーザーが見出しを選択すると、フラグメントは以下のように（特定のハードコーディングされたアクティビティに通知するのではなく）ホスト アクティビティが指定したリスナーに通知します:</p> + +<pre> +public class HeadlinesFragment extends ListFragment { + ... + @Override + public void onItemClick(AdapterView<?> parent, + View view, int position, long id) { + if (null != mHeadlineSelectedListener) { + mHeadlineSelectedListener.onHeadlineSelected(position); + } + } + ... +} +</pre> + +<p>このテクニックについては、<a +href="{@docRoot}guide/practices/tablets-and-handsets.html">タブレットと携帯端末のサポート</a>で詳しく説明されています。</p> + + +<h2 id="TaskHandleConfigChanges">画面設定の変更を処理する</h2> + +<p>インターフェースの各パーツを実装するのに個別のアクティビティを使用している場合、インターフェースの一貫性を維持するために、（向きの変更などの）特定の設定変更に対応できるように注意する必要があります。</p> + +<p>たとえば、Android 3.0 以上が動作する一般的な 7 インチ タブレットでは、News Reader サンプルがニュース記事を表示する場合、縦表示では個別のアクティビティを使用しますが、横表示では 2 ペイン レイアウトを使用します。</p> + +<p>つまり、縦表示のときに記事閲覧用アクティビティが画面上にある場合、画面の向きが横方向に変わったことを検出したら、コンテンツを 2 ペイン レイアウトで表示するために、そのアクティビティを終了してメインのアクティビティに戻り、適切に応答しなければなりません:</p> + +<pre> +public class ArticleActivity extends FragmentActivity { + int mCatIndex, mArtIndex; + + @Override + protected void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + mCatIndex = getIntent().getExtras().getInt("catIndex", 0); + mArtIndex = getIntent().getExtras().getInt("artIndex", 0); + + // If should be in two-pane mode, finish to return to main activity + if (getResources().getBoolean(R.bool.has_two_panes)) { + finish(); + return; + } + ... +} +</pre> + + diff --git a/docs/html-intl/ja/training/multiscreen/index.jd b/docs/html-intl/ja/training/multiscreen/index.jd new file mode 100644 index 0000000..ff84f8a --- /dev/null +++ b/docs/html-intl/ja/training/multiscreen/index.jd @@ -0,0 +1,64 @@ +page.title=複数画面のデザイン + +trainingnavtop=true +startpage=true +next.title=さまざまな画面サイズのサポート +next.link=screensizes.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>必要な知識と前提条件</h2> + +<ul> + <li>Android 1.6 以上（サンプル アプリを使用するには 2.1 以上）</li> + <li><a +href="http://developer.android.com/guide/components/activities.html">アクティビティ</a>と<a href="http://developer.android.com/guide/components/fragments.html">フラグメント</a>の基礎知識</li> + <li>Android <a +href="http://developer.android.com/guide/topics/ui/index.html">ユーザー インターフェース</a>の開発経験</li> + <li><a +href="{@docRoot}tools/extras/support-library.html">サポート ライブラリ</a>の利用（一部の機能で必要）</li> +</ul> + +<h2>関連ドキュメント</h2> + +<ul> + <li><a href="{@docRoot}guide/practices/screens_support.html">複数画面のサポート</a></li> +</ul> + +<h2>試してみる</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/NewsReader.zip" class="button">サンプル アプリのダウンロード</a> +<p class="filename">NewsReader.zip</p> +</div> + +</div> +</div> + +<p>Android は、小さな携帯電話から大きなテレビまで、画面サイズも種類もさまざまなデバイスに搭載できます。そのため、できる限り多くのユーザーが使用できるように、すべての画面サイズに対応できるようアプリを設計することが重要になります。</p> + +<p>しかし、さまざまな種類のデバイスに対応できるだけでは十分ではありません。画面サイズによって、ユーザーが操作できることが決まってくるため、本当にユーザーを満足させてよい印象を持ってもらうためには、アプリが単に複数の画面をサポートするだけでは不十分です: 画面設定ごとにユーザー エクスペリエンスを最適化する必要があります。<em></em><em></em></p> + +<p>このクラスは、いくつかの画面設定に合わせて最適化されたユーザー インターフェースを実装する方法を提供します。</p> + +<p>各レッスンで紹介されているコードは、複数の画面に合わせて最適化する際、ベスト プラクティスとなるサンプル アプリから抜粋したものです。このサンプルを（右側から）ダウンロードして、再利用可能なコードのソースとしてご自分のアプリに使用することができます。</p> + +<p class="note"><strong>注:</strong> このクラスと関連サンプルでは、<a +href="{@docRoot}tools/extras/support-library.html">サポート ライブラリ</a>を使用します。理由は、Android 3.0 未満のバージョンで <PH>{@link android.app.Fragment}</PH> API を使用するためです。このクラスのすべての API を使用するには、ライブラリをダウンロードして、アプリに追加する必要があります。</p> + + +<h2>レッスン</h2> + +<dl> + <dt><b><a href="screensizes.html">さまざまな画面サイズのサポート</a></b></dt> + <dd>このレッスンでは、さまざまな画面サイズに適したレイアウトを（柔軟なビュー サイズ、 <PH>{@link android.widget.RelativeLayout}</PH>、画面サイズと画面の向きの修飾子、エイリアス フィルタ、ナインパッチ ビットマップを使用して）設計する方法について学習します。</dd> + + <dt><b><a href="screendensities.html">さまざまな画面密度のサポート</a></b></dt> + <dd>このレッスンでは、（密度非依存ピクセルを使用し、各密度に適したビットマップを提供して）ピクセル密度が異なる画面をサポートする方法について学習します。</dd> + + <dt><b><a href="adaptui.html">順応性のある UI フローの実装</a></b></dt> + <dd>このレッスンでは、いくつかの画面サイズ/密度の組み合わせに適した方法（実行時にアクティブなレイアウトを検出する方法、現在のレイアウトに合わせて応答する方法、画面設定の変更を処理する方法）で UI を実装する方法について学習します。</dd> +</dl> diff --git a/docs/html-intl/ja/training/multiscreen/screendensities.jd b/docs/html-intl/ja/training/multiscreen/screendensities.jd new file mode 100644 index 0000000..3482d5c --- /dev/null +++ b/docs/html-intl/ja/training/multiscreen/screendensities.jd @@ -0,0 +1,100 @@ +page.title=さまざまな画面密度のサポート +parent.title=複数画面のデザイン +parent.link=index.html + +trainingnavtop=true +previous.title=さまざまな画面サイズのサポート +previous.link=screensizes.html +next.title=順応性のある UI フローの実装 +next.link=adaptui.html + +@jd:body + + +<!-- This is the training bar --> +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンでの学習内容</h2> +<ol> + <li><a href="#TaskUseDP">密度非依存ピクセルを使用する</a></li> + <li><a href="#TaskProvideAltBmp">代替ビットマップを生成する</a></li> +</ol> + +<h2>関連ドキュメント</h2> + +<ul> + <li><a href="{@docRoot}guide/practices/screens_support.html">複数画面のサポート</a></li> + <li><a href="{@docRoot}guide/practices/ui_guidelines/icon_design.html">アイコン設計のガイドライン</a></li> +</ul> + +<h2>試してみる</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/NewsReader.zip" class="button">サンプル アプリのダウンロード</a> +<p class="filename">NewsReader.zip</p> +</div> + + +</div> +</div> + +<p>このレッスンでは、異なるリソースを生成し、かつ解像度非依存単位を使用して、異なる画面密度をサポートする方法について学習します。</p> + +<h2 id="TaskUseDP">密度非依存ピクセルを使用する</h2> + +<p>レイアウトを設計する際に回避すべきよくある落とし穴の 1 つとして、絶対ピクセルを使用して距離やサイズを定義することがあります。ピクセルを使用してレイアウトのサイズを定義すると、画面によってピクセル密度が異なるため、問題が起こります。したがって、同じピクセル数では、デバイスが異なる場合に物理サイズが異なる可能性があります。そのため、サイズを指定する場合は、常に <code>dp</code> 単位や <code>sp</code> 単位を使用します。<code>dp</code> とは、1 ピクセルの物理サイズが 160 dpi に相当する密度非依存ピクセルです。<code>sp</code> も基本単位は同じですが、ユーザーの優先テキスト サイズによってサイズが決まるので（スケール非依存ピクセル）、テキスト サイズを定義する際にはこの単位を使用する必要があります（ただし、レイアウト サイズには絶対に使用しないこと）。</p> + +<p>たとえば、2 つのビューの間にスペースを挿入する場合は、<code>px</code> ではなくて <code>dp</code> を使用します:</p> + +<pre> +<Button android:layout_width="wrap_content" + android:layout_height="wrap_content" + android:text="@string/clickme" + android:layout_marginTop="20dp" /> +</pre> + +<p>テキスト サイズを指定する場合は、常に <code>sp</code> を使用します:</p> + +<pre> +<TextView android:layout_width="match_parent" + android:layout_height="wrap_content" + android:textSize="20sp" /> +</pre> + + +<h2 id="TaskProvideAltBmp">代替ビットマップを生成する</h2> + +<p>Android は、画面密度がさまざまなデバイスで動作するため、それぞれの汎用密度バケット（低密度、中密度、高密度、超高密度）に合わせてビットマップ リソースを生成する必要があります。そうすることで、すべての画面密度で画質とパフォーマンスが向上します。</p> + +<p>これらの画像を生成するには、ベクター形式の未加工リソースから、次のサイズ スケールを使用して密度別に画像を生成する必要があります:</p> + +<p><ul> + <li><code>xhdpi</code>: 2.0 + <li><code>hdpi</code>: 1.5 + <li><code>mdpi</code>: 1.0（基準） + <li><code>ldpi</code>: 0.75 +</ul></p> + +<p>つまり、200×200 画像（<code>xhdpi</code> デバイス用）を生成する場合、同じリソースを 150×150 画像（<code>hdpi</code> デバイス用）、100×100 画像（<code>mdpi</code> デバイス用）、75×75（<code>ldpi</code> デバイス用）でも生成する必要があります。</p> + +<p>さらに、生成した画像を <code>res/</code> 下の適切なサブディレクトリに配置することで、アプリが動作するデバイスの画面密度に基づいて、自動的に適切な画像が表示されます:</p> + +<pre class="classic no-pretty-print"> +MyProject/ + res/ + drawable-xhdpi/ + awesomeimage.png + drawable-hdpi/ + awesomeimage.png + drawable-mdpi/ + awesomeimage.png + drawable-ldpi/ + awesomeimage.png +</pre> + +<p>また、<code>@drawable/awesomeimage</code> を参照する場合は常に画面の dpi に基づいて、適切なビットマップが選択されます。</p> + +<p>アプリ用のアイコン アセットを作成するためのヒントとガイドラインについては、<a +href="{@docRoot}guide/practices/ui_guidelines/icon_design.html">アイコン設計のガイドライン</a>をご覧ください。</p> + diff --git a/docs/html-intl/ja/training/multiscreen/screensizes.jd b/docs/html-intl/ja/training/multiscreen/screensizes.jd new file mode 100644 index 0000000..3655a33 --- /dev/null +++ b/docs/html-intl/ja/training/multiscreen/screensizes.jd @@ -0,0 +1,279 @@ +page.title=さまざまな画面サイズのサポート +parent.title=複数画面のデザイン +parent.link=index.html + +trainingnavtop=true +next.title=さまざまな画面密度のサポート +next.link=screendensities.html + +@jd:body + + +<!-- This is the training bar --> +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンでの学習内容</h2> +<ol> + <li><a href="#TaskUseWrapMatchPar">「wrap_content」と「match_parent」を使用する</a></li> + <li><a href="#TaskUseRelativeLayout">RelativeLayout を使用する</a></li> + <li><a href="#TaskUseSizeQuali">サイズ修飾子を使用する</a></li> + <li><a href="#TaskUseSWQuali">最小幅修飾子を使用する</a></li> + <li><a href="#TaskUseAliasFilters">レイアウト エイリアスを使用する</a></li> + <li><a href="#TaskUseOriQuali">画面の向きの修飾子を使用する</a></li> + <li><a href="#TaskUse9Patch">ナインパッチ ビットマップを使用する</a></li> +</ol> + +<h2>関連ドキュメント</h2> + +<ul> + <li><a href="{@docRoot}guide/practices/screens_support.html">複数画面のサポート</a></li> +</ul> + +<h2>試してみる</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/NewsReader.zip" class="button">サンプル アプリのダウンロード</a> +<p class="filename">NewsReader.zip</p> +</div> + +</div> +</div> + +<p>このレッスンでは、異なる画面サイズを以下のような方法でサポートする方法について学習します:</p> +<ul> + <li>画面に収まるようにレイアウト サイズを適切に変更する</li> + <li>画面設定に基づいて適切な UI レイアウトを表示する</li> + <li>適切な画面に適切なレイアウトを適用する</li> + <li>適切にサイズ調整したビットマップを表示する</li> +</ul> + + +<h2 id="TaskUseWrapMatchPar">「wrap_content」と「match_parent」を使用する</h2> + +<p>レイアウトをさまざまな画面サイズに柔軟に対応させるには、一部のビュー コンポーネントの幅と高さに <code>"wrap_content"</code> と <code>"match_parent"</code> を使用する必要があります。<code>"wrap_content"</code> を使用すると、ビューの幅や高さがそのビュー内にコンテンツが収まるのに必要な最小サイズに設定されます。一方、<code>"match_parent"</code>（API レベル 8 より前の名称は <code>"fill_parent"</code>）を使用すると、コンポーネントがその親ビューのサイズに一致するまで拡大されます。</p> + +<p>ハードコーディングされたサイズの代わりに <code>"wrap_content"</code> と <code>"match_parent"</code> を使用することで、ビューはそれぞれ、そのビューに必要なスペースだけを使用したり、空きスペースを埋めるまで拡大したりします。次に例を示します:</p> + +{@sample development/samples/training/multiscreen/newsreader/res/layout/onepane_with_bar.xml all} + +<p>このサンプルでは、特定のサイズではない <code>"wrap_content"</code> と <code>"match_parent"</code> をコンポーネント サイズにどのように使用しているかに注目してください。こうすることで、異なる画面のサイズと向きにレイアウトを正しく対応させることができます。</p> + +<p>たとえば、このレイアウトを縦表示と横表示で表示したときの見え方を以下に示します。コンポーネントのサイズが幅と高さに自動的に適合している点に注目してください:</p> + +<img src="{@docRoot}images/training/layout-hvga.png" /> +<p class="img-caption"><strong>図 1.</strong> News Reader サンプル アプリの縦表示（左）と横表示（右）</p> + + +<h2 id="TaskUseRelativeLayout">RelativeLayout を使用する</h2> + +<p>ネストされた <PH>{@link android.widget.LinearLayout} インスタンスや、</PH> <code>"wrap_content"</code> と <code>"match_parent"</code> のサイズの組み合わせを使用すると、かなり複雑なレイアウトを作成できます。しかし、 <PH>{@link android.widget.LinearLayout}</PH> では、子ビューの空間的な位置関係を正確に制御することはできません。 <PH>{@link android.widget.LinearLayout} のビューは、</PH> 単に一列に並ぶだけです。子ビューに対して直線以外のさまざまな配置を実現する必要がある場合は、 <PH>{@link android.widget.RelativeLayout}</PH>を使用することでうまくいくことがよくあります。たとえば、1 つの子ビューを画面の左側に配置し、もう 1 つの子ビューを右側に配置できます。</p> + +<p>次に例を示します:</p> + +<pre> +<?xml version="1.0" encoding="utf-8"?> +<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" + android:layout_width="match_parent" + android:layout_height="match_parent"> + <TextView + android:id="@+id/label" + android:layout_width="match_parent" + android:layout_height="wrap_content" + android:text="Type here:"/> + <EditText + android:id="@+id/entry" + android:layout_width="match_parent" + android:layout_height="wrap_content" + android:layout_below="@id/label"/> + <Button + android:id="@+id/ok" + android:layout_width="wrap_content" + android:layout_height="wrap_content" + android:layout_below="@id/entry" + android:layout_alignParentRight="true" + android:layout_marginLeft="10dp" + android:text="OK" /> + <Button + android:layout_width="wrap_content" + android:layout_height="wrap_content" + android:layout_toLeftOf="@id/ok" + android:layout_alignTop="@id/ok" + android:text="Cancel" /> +</RelativeLayout> +</pre> + +<p>図 2 は、このレイアウトの QVGA 画面での見え方を示しています。</p> + +<img src="{@docRoot}images/training/relativelayout1.png" /> +<p class="img-caption"><strong>図 2.</strong> QVGA 画面（スモール画面）のスクリーンショット</p> + +<p>図 3 は、このレイアウトのラージ画面での見え方を示しています。</p> + +<img src="{@docRoot}images/training/relativelayout2.png" /> +<p class="img-caption"><strong>図 3.</strong> WSVGA 画面（ラージ画面）のスクリーンショット</p> + +<p>コンポーネントのサイズが変更されても、 <PH>{@link android.widget.RelativeLayout.LayoutParams}</PH>で指定されたとおりに空間的な位置関係が維持されていることがわかります。</p> + + +<h2 id="TaskUseSizeQuali">サイズ修飾子を使用する</h2> + +<p>柔軟なレイアウトや相対的なレイアウトから得られる恩恵は、前のセクションで説明したことくらいです。これらのレイアウトはコンポーネントの内部や周囲のスペースを引き延ばすことでさまざまな画面に対応しますが、それぞれの画面サイズに合った最高のユーザー エクスペリエンスを実現していない可能性があります。したがって、アプリでは、柔軟なレイアウトの実装だけではなく、さまざまな画面設定に合わせた複数の代替レイアウトも必要になります。これは、<a href="http://developer.android.com/guide/practices/screens_support.html#qualifiers">設定修飾子</a>を使用することで実現可能です。設定修飾子により、ランタイムが現在のデバイスの設定に基づいて適切なリソース（画面サイズ別のレイアウト デザインなど）を自動的に選択できます。</p> + +<p>たとえば、多くのアプリでは、ラージ画面用に「2 ペイン」パターンを実装しています（一方のペインに項目リスト、もう一方のペインにそのコンテンツを表示することが可能です）。タブレットやテレビは両方のペインを同時に表示できるほど十分に大きい画面ですが、携帯端末の画面では 2 つのペインを別々に表示する必要があります。そのようなレイアウトを実装するには、次のようなファイルが必要になります:</p> + +<ul> + <li><code>res/layout/main.xml</code>、シングルペイン（デフォルト）レイアウト: + +{@sample development/samples/training/multiscreen/newsreader/res/layout/onepane.xml all} +</li> + <li><code>res/layout-large/main.xml</code>、2 ペイン レイアウト: + +{@sample development/samples/training/multiscreen/newsreader/res/layout/twopanes.xml all} +</li> +</ul> + +<p>2 番目のレイアウトのディレクトリ名の <code>large</code> 修飾子に注目してください。このレイアウトは、ラージ（7 インチ以上のタブレットなど）と分類された画面のデバイスで選択されます。それよりも小さいデバイスでは、その他のレイアウト（修飾子なし）が選択されます。</p> + + +<h2 id="TaskUseSWQuali">最小幅修飾子を使用する</h2> + +<p>Android 3.2 未満のデバイスでデベロッパーが抱えていた問題の 1 つに、Dell Streak、初代 Galaxy Tab、7 インチ タブレット全般を含む、「ラージ」画面サイズの分類があります。しかし、多くのアプリでは、すべて「ラージ」画面と見なされたとしても、このカテゴリ内のデバイスのサイズに合わせて異なるレイアウト（5 インチと 7 インチのデバイス用など）を表示したい場合があります。そこで、Android 3.2 では「最小幅」修飾子などが導入されました。</p> + +<p>最小幅修飾子を使用すると、dp で指定した特定の最小幅の画面を対象とすることができます。たとえば、一般的な 7 インチ タブレットは最小幅が 600 dp なので、これらの画面の UI で 2 つのペイン（ただし、それよりも小さい画面ではシングル リスト）を表示したい場合は、前のセクションで説明した 2 つのレイアウトをシングルペイン レイアウト用と 2 ペイン レイアウト用としてそのまま利用できます。ただし、<code>large</code> サイズ修飾子の代わりに、<code>sw600dp</code> を使用して、最小幅が 600 dp の画面では 2 ペイン レイアウトになるよう指定します:</p> + +<ul> + <li><code>res/layout/main.xml</code>、シングルペイン（デフォルト）レイアウト: + +{@sample development/samples/training/multiscreen/newsreader/res/layout/onepane.xml all} +</li> + <li><code>res/layout-sw600dp/main.xml</code>、2 ペイン レイアウト: + +{@sample development/samples/training/multiscreen/newsreader/res/layout/twopanes.xml all} +</li> +</ul> + +<p>つまり、最小幅が 600dp 以上のデバイスでは <code>layout-sw600dp/main.xml</code>（2 ペイン）レイアウトが選択され、それよりも小さい画面では <code>layout/main.xml</code>（シングルペイン）レイアウトが選択されるということです。</p> + +<p>ただし、Android 3.2 未満のデバイスではこの修飾子は機能しません。これは <code>sw600dp</code> をサイズ修飾子として認識できないためです。したがって、引き続き <code>large</code> 修飾子も使用する必要があります。そこで、<code>res/layout-sw600dp/main.xml</code> と同じ内容の <code>res/layout-large/main.xml</code> という名前のファイルも必要になります。次のセクションでは、このようにレイアウト ファイルの重複を避けるためのテクニックについて学習します。</p> + + +<h2 id="TaskUseAliasFilters">レイアウト エイリアスを使用する</h2> + +<p>最小幅修飾子は、Android 3.2 以上でしか利用できません。したがって、旧バージョンとの互換性を維持するために、あいまいなサイズ分類（small、normal、large、xlarge）も併用することが必要です。たとえば、携帯端末ではシングルペイン UI、7 インチ タブレットやテレビなどの大きなデバイスではマルチペイン UI を表示するよう UI を設計する場合、以下のようなファイルが必要になります:</p> + +<p><ul> +<li><code>res/layout/main.xml:</code> シングルペイン レイアウト</li> +<li><code>res/layout-large:</code> マルチペイン レイアウト</li> +<li><code>res/layout-sw600dp:</code> マルチペイン レイアウト</li> +</ul></p> + +<p>最後の 2 つのファイルは同じものです。一方は Android 3.2 デバイス用で、もう一方は旧バージョンの Android を搭載したタブレットとテレビ用です。</p> + +<p>このようにタブレット/テレビ用として同じファイルを使用することで起こる重複（さらに、その結果メンテナンスが困難になる状況）を避けるために、エイリアス ファイルを使用できます。たとえば、次のようなレイアウトを定義できます:</p> + +<ul> +<li><code>res/layout/main.xml</code>、シングルペイン レイアウト</li> +<li><code>res/layout/main_twopanes.xml</code>、2 ペイン レイアウト</li> +</ul> + +<p>さらに、次の 2 つのファイルを追加します:</p> + +<p><ul> +<li><code>res/values-large/layout.xml</code>: +<pre> +<resources> + <item name="main" type="layout">@layout/main_twopanes</item> +</resources> +</pre> +</li> + +<li><code>res/values-sw600dp/layout.xml</code>: +<pre> +<resources> + <item name="main" type="layout">@layout/main_twopanes</item> +</resources> +</pre> + +</li> +</ul></p> + +<p>最後の 2 つのファイルの内容は同じですが、実際のレイアウトは定義していません。これらのファイルは、単に <PH>{@code main}</PH> を <PH>{@code main_twopanes}</PH>へのエイリアスになるように設定しただけです。これらのファイルには <code>large</code> と <code>sw600dp</code> セレクタが含まれているので、Android のバージョンに関係なく（ +<PH>Android 3.2 未満のタブレット/テレビは {@code large} に一致し、</PH>Android 3.2 以上のタブレット/テレビは <code>sw600dp</code> に一致します）タブレット/テレビに適用されます。</p> + + +<h2 id="TaskUseOriQuali">画面の向きの修飾子を使用する</h2> + +<p>横表示と縦表示が両方とも正しく表示されるレイアウトもありますが、ほとんどのレイアウトは調整が必要になります。以下に、News Reader サンプル アプリの各画面のサイズと向きでレイアウトがどのように表示されるかを示します:</p> + +<p><ul> +<li><b>スモール画面、縦表示:</b> シングル ペイン、ロゴ付き</li> +<li><b>スモール画面、横表示:</b> シングル ペイン、ロゴ付き</li> +<li><b>7 インチ タブレット、縦表示:</b> シングル ペイン、アクション バー付き</li> +<li><b>7 インチ タブレット、横表示:</b> デュアル ペイン、ワイド、アクション バー付き</li> +<li><b>10 インチ タブレット、縦表示:</b> デュアル ペイン、ナロー、アクション バー付き</li> +<li><b>10 インチ タブレット、横表示:</b> デュアル ペイン、ワイド、アクション バー付き</li> +<li><b>テレビ、横表示:</b> デュアル ペイン、ワイド、アクション バー付き</li> +</ul></p> + +<p>これらの各レイアウトは、<code>res/layout/</code> ディレクトリ内の XML ファイルに定義されています。各レイアウトをさまざまな画面設定に割り当てるには、アプリでレイアウト エイリアスを使用して、各設定に対応付けます:</p> + +<p><code>res/layout/onepane.xml:</code></p> +{@sample development/samples/training/multiscreen/newsreader/res/layout/onepane.xml all} + +<p><code>res/layout/onepane_with_bar.xml:</code></p> +{@sample development/samples/training/multiscreen/newsreader/res/layout/onepane_with_bar.xml all} + +<p><code>res/layout/twopanes.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/layout/twopanes.xml all} + +<p><code>res/layout/twopanes_narrow.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/layout/twopanes_narrow.xml all} + +<p>これで、考えられるすべてのレイアウトが定義されました。あとは、設定修飾子を使用して、適切なレイアウトを各設定にマッピングするだけです。そのためには、以下のようなレイアウト エイリアス テクニックを使用することができます:</p> + +<p><code>res/values/layouts.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/values/layouts.xml all} + +<p><code>res/values-sw600dp-land/layouts.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/values-sw600dp-land/layouts.xml +all} + +<p><code>res/values-sw600dp-port/layouts.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/values-sw600dp-port/layouts.xml +all} + +<p><code>res/values-large-land/layouts.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/values-large-land/layouts.xml all} + +<p><code>res/values-large-port/layouts.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/values-large-port/layouts.xml all} + + + +<h2 id="TaskUse9Patch">ナインパッチ ビットマップを使用する</h2> + +<p>異なる画面サイズをサポートするには、画像リソースも異なるサイズに対応できないといけません。たとえば、ボタンの背景は、適用されるボタンの形状が異なってもサイズが合わなければいけません。</p> + +<p>サイズ変更可能なコンポーネントでシンプルな画像を使用すると、ランタイムによって画像が一様に拡大縮小されるので、いくぶん期待はずれの結果になることがすぐにわかります。これは、ナインパッチ ビットマップを使用することで解決します。ナインパッチ ビットマップとは、拡大可能な領域と拡大不可能な領域が指定された特殊なフォーマットの PNG ファイルです。</p> + +<p>そのため、サイズが変化するコンポーネントで使用するビットマップをデザインする場合は、常にナインパッチを使用してください。ビットマップをナインパッチに変換するには、まず、通常の画像を用意します（図 4: わかりやすく 4 倍に拡大しています）。</p> + +<img src="{@docRoot}images/training/button.png" /> +<p class="img-caption"><strong>図 4.</strong> <code>button.png</code></p> + +<p>次に、 <ode +href="{@docRoot}tools/help/draw9patch.html">SDK の <code>draw9patch</code></a> ユーティリティ（<code>tools/</code> ディレクトリにあります）からナインパッチを実行して、左境界線と上境界線上にピクセル（ドット）を描くことで拡大する領域にマークを付けます。また、右境界線と下境界線上にピクセルを描くことで、コンテンツを入れる領域をマークできます（図 5）。</p> + +<img src="{@docRoot}images/training/button_with_marks.png" /> +<p class="img-caption"><strong>図 5.</strong> <code>button.9.png</code></p> + +<p>境界線上に黒いピクセルがあることに注目してください。左境界線と上境界線上のものは画像を拡大できる領域で、右境界線と下境界線上のものはコンテンツを配置する領域を示しています。</p> + +<p>さらに、<code>.9.png</code> という拡張子にも注目してください。この拡張子は必ず使用してください。そうすることで、通常の PNG 画像ではなく、ナインパッチ画像であることがフレームワークによって検出されます。</p> + +<p>この背景を（<code>android:background="@drawable/button"</code> を設定して）コンポーネントに適用すると、ボタンのサイズに合わせて適切に画像が拡大します（図 6 のさまざまなサイズを参照）。</p> + +<img src="{@docRoot}images/training/buttons_stretched.png" /> +<p class="img-caption"><strong>図 6</strong><code>button.9.png</code> ナインパッチを使用したさまざまなサイズのボタン</p> + |