端末情報を調べるときに見るページ
au
auの開発者向けページは他キャリアの同様のページとくらべて非常にわかりやすい。 他がひどいのでわかりやすいというだけで高評価だ。
Android(TM) 技術情報 | 開発者向け技術情報 | au
端末スペックは細かく乗っていて一覧性が高い。 更新スピードも早くこの間発表された2015春モデルもすでに記載されている。 特にAndroidで重要な端末のdp設定(xhdpi,xxhdpi...)なども載っていて有用。
ディスプレイ | Android(TM) 技術情報 | au
docomo
docomoの開発者向けページは端末そのものの情報よりサービス推しが目立つ。
作ろうスマートフォンコンテンツ | サービス・機能 | NTTドコモ
端末情報は入り口が見つけにくい上に一度入ったら戻るためのリンクがない。 また、一覧表がない上に情報が機能別にページわけされていて階層が深いすぎる。 ピクセル密度という項目で実dpiは記載されているが、端末が使うdp設定は記載されていないのでdpの設定から推察する必要がある。
softbank
softbankの開発者ページにはコラムも連載されている。 ただしコンテンツ量はあまり多くなくページが細かく区切られていて読みづらい…。
Android[TM] 技術仕様情報 | SoftBank スマートフォン サービス開発支援サイト | ソフトバンク
端末情報は検索して一覧表にする形式だが、そもそもの情報量が少ない。更新も遅い。 wifiなどの機能は○/☓形式なのにグレーアウトされている機種もあったりして色々ひどい。 ディスプレイに至ってはdp設定どころか実dpiすら表示されないので自分で計算しなくてはいけない。
Android Develoeprsの歩き方
はじめに
この記事はAndroid Developersを便利に使うための方法が書いてあります。 前提としてAndroid Developersのページ構成などをある程度理解している必要があるので、まずは下記記事を参考にAndroid Developersの構造を把握してください。
拡張機能の導入
Chromeを利用している場合、Android SDK Searchを導入することでAndroid Developersの使い勝手がかなり上がります。
主な機能
- URL入力欄に
ad *keyword*
と入れることでAndroid Developersを検索してくれる - Android Developersのクラスリファレンスページにソースコードへのリンクを表示してくれる
特に後者はとても強力な機能です。 UserManager#isUserAGoat()ってどうやってヤギかどうかチェックしてるんだっけ?と思った時にすぐ実装を見ることができます。
Blogを読む
Android Developers Blogを購読しましょう。 このブログは単なる技術系ブログではなく、Android Developersからも検索対象になっているコンテンツのひとつです。 一部の記事はGoogle Developer Japan Blogで翻訳されていますが、このブログはAndroidに限定されたものではなくAndroid Developersの検索にも引っかからないため、なるべく本家の更新をチェックするようにしましょう。
特定のタイミングで更新されるページ
Dashboardsは毎月OSバージョンや画面サイズごとのシェアが報告されるページです。 このページは毎月一度はチェックしたほうが良いでしょう。 OSのバージョンアップが行われた場合、主に以下のページが変更されます。
- Android, the world's most popular mobile platform
- Patterns、特にNew in Android
- Samples > What's New(更新までに間があく場合があります)
API levelごとの差分を見る
API Differencesで確認することができます。 URLの数字を変更することで過去の差分もみていくことができます。 引数などが変わらず、挙動のみが変わってしまうメソッドはこの方法ではわからないため、検索を活用することで探します。 あまり効率はよくありませんが、As of LOLLIPOPで検索し、左側メニューでReferencesを選択することでjavadoc内のLOLLIPOPでの動作について言及している箇所を探すことができます。 As of KITKATなども同様に探せます。
Supportライブラリにバックポートされた機能を探す
Supportライブラリの主な機能はSupport Library Featuresにまとめられています。過去にこのページをみており、新規差分だけ把握したい場合はRevisionsを参照すると早いです。 ただし、これらのページには主な機能しか記述されていないので、他のバックポートされた機能探すために検索機能を活用します。Compatで検索し、左側メニューからReferenceを検索することでjavadoc内の文字列検索になります。Support Library Featuresには記載されていないLinearLayoutCompatなどもこの方法で検索できますが、ノイズが多いため効率はあまりよくありません。
このような機能は以下のパッケージに含まれていることが多いため、パッケージ単位のReferenceでクラス一覧を眺めてみるのも良いでしょう。
- android.support.v4.app
- android.support.v4.util
- android.support.v4.view
- android.support.v4.widget
- android.support.v7.widget
早見表
アイコンサイズや代替リソースの設定の一覧が書かれているページは覚えておくと便利です。
Android Developersでよく読むページ
Android Developersを読むときの注意点
どのページにも言えることですが、一見目次のように見えてもページ階層と関係ないリンク集だったりすることがあります。 たとえばBest Practicesというページの「BLOG ARTICLES」は一見このカテゴリの子ページリンクに見えますが、実際はこのカテゴリと関係があるブログ記事の一覧になっており子ページは「Supporting Multiple Screens」「Supporting Tablets and Handsets」「Verifying App Behavior on ART」の3つになります。 Android Developersのページ構成は左側ペインを参考にしましょう。
About
このページはトップページの「Learn More」か左上の「Developers」ロゴ右の矢印から展開するメニューからしか飛べないので気が付きにくいページです。 Androidのバージョンごとに追加された新機能などや変更点などが記載されています。 Android Wear、TV、Autoなどの概要ページも同じ階層にあります。 特にDashboardsはOSのバージョンや端末サイズごとのシェアが書かれており、毎月更新されるので定期的に確認しましょう。
http://developer.android.com/about/index.html
Design
Androidアプリのデザイン面で注意すべきことが書いてあるカテゴリです。
http://developer.android.com/design/index.html
Material Design
AndroidにおけるMaterial Designの概要について書いてあります。 デザイン面での詳細に関してはMaterial Designガイドラインを参照してください。
http://developer.android.com/design/material/index.html
Patterns
AndroidにおけるUIデザインパターンについて書かれています。 見た目だけでなくNavigation Drawer利用時の画面遷移の在り方や確認ダイアログを使うべきタイミングについても書かれているので、Androidアプリを実装する上で是非読んでおくべきです。
http://developer.android.com/design/patterns/index.html
Building Blocks
Androidで利用できる標準UI部品について書かれています。 執筆時点ではスクリーンショットなどがMaterialテーマに対応していませんが、どのような部品があるかは把握しておきましょう。 ActionBarタブなどすでに非推奨のものも載っているので、他のページ(特に最新のAPIにおける変更点)と合わせて読む必要があります。
http://developer.android.com/design/building-blocks/index.html
Downloads
ActionBarメニューで利用できるアイコンやフォントなどがダウンロードできます。 他のページからダウンロードできるものもこのページにまとめられているので便利です。
http://developer.android.com/design/downloads/index.html
Develop
Androidアプリ開発に直接関係するカテゴリです。 APIリファレンスやサンプルコードが含まれるのもここです。
http://developer.android.com/develop/index.html
Training
Trainingは名前の通りAndroidアプリ開発のための練習資料です。 中級者以上は用がないと思いがちですが、タブレット対応する際に考えるべきことやAndroid TVハードウェアの制限など引っかかりやすい部分も載っているので触ったことがない機能を実装するのであれば一読しておくべきです。
http://developer.android.com/training/index.html
API Guides
Android APIにどのような機能があってどう使うべきかがカテゴリごとにまとめられています。 DesignやTrainningからリンクされているページもあるので、これらのページとあわせて読むとより理解が深まります。
http://developer.android.com/guide/index.html
App Components
Androidの基本的なコンポーネントについて書いてあります。 特にIntents and Intent Filtersは全てのコンポーネントをつなぐIntent機能について説明されているので必ず読みましょう。
http://developer.android.com/guide/components/index.html
App Resources
Androidのリソース管理について書いてあります。 代替リソースの定義方法は複雑ですが、それぞれ関係するページにリンクが貼ってあるので利用する際はリンク先まで読みましょう。
http://developer.android.com/guide/topics/resources/index.html
User Interface
AndroidのUIについて網羅的に書かれています。 このページでは主に実装面について書かれているので、Designカテゴリとあわせて読むことで実際にどのような場面でどのようなUIを選択すべきかが理解できます。 Action Barの実装などは古い記述が残っているので最新のAPIと照らしながら読みましょう。
http://developer.android.com/guide/topics/ui/index.html
Best Practices
Androidアプリをより良くするための情報が書かれています。 特にSupporting Multiple Screensはアプリの表示崩れを防ぐ上で非常に重要な項目なので、必ず読みましょう。
http://developer.android.com/guide/practices/index.html
Reference
Android APIのリファレンスです。いわゆるJavadoc。 非常に有益な情報もあるので、普段使っているクラスでも一度は目を通しましょう。 例えば、Intentクラスのリファレンスでは「Standard Broadcast Actions」という形でよく使われれるブロードキャストアクションの一覧が載っています。
http://developer.android.com/reference/packages.html
Tools
開発ツールに関する情報が載っています。 Android StudioやADTだけでなくSupport Libraryに関する情報もここにまとめられています。
http://developer.android.com/sdk/index.html
Tools Help
Android SDKに付属しているツールについて説明されています。 Android Debug BridgeやDraw 9-patchはよく使うので目を通しましょう。
http://developer.android.com/tools/help/index.html
Support Library
Supportライブラリについて説明されています。 特に重要なのはFeaturesとRevisionsです。 前者はSupportライブラリがそれぞれどのような機能を実装しているかの概要、後者は各機能が実装されたリビジョンが記載されています。 実際にはFeaturesに記載されていない機能も多く含まれているので、Referenceを見ることも重要です。
http://developer.android.com/tools/support-library/index.html
Google Services
Google Servicesについて書かれています。 アプリで連携できるGoogleサービスの説明のほか、Google Play ServicesとそのサブページがGoogle Play Services SDKに関するリファレンスになっています。 アプリ内課金を行う場合はGoogle Play In-app Billingを参照しましょう。
http://developer.android.com/google/index.html
Samples
Androidの各APIやUIに関するサンプルプロジェクトが公開されています。 最近What's Newページが追加され、新しいサンプルがどれなのかわかるようになりました。 サンプルプロジェクトはSlidingTabsColorsなど有用なものもありますが、最新機能のサンプルなどはSDKに依存していてバックポートの方法などが全く書かれていないものが多いです。 Android Studio上で直接インポート可能なので、Android Developers上で参照することはあまりありません。
http://developer.android.com/samples/index.html
Distribute
作成したAndroidアプリをどのように配布するかの情報が書かれています。
http://developer.android.com/distribute/index.html
Google Play
Google Play上でアプリがどのように表示されるか、Developer Consoleをどのように設定すべきかが書かれています。
アプリ開発と直接関係ないと思いがちですが、アプリを成功させるための秘訣などの情報も含まれるため有益です。
http://developer.android.com/distribute/googleplay/index.html
Essentials
アプリを成功させるために必要なポイントがUIデザインやコーディング、テスト手法にわたって書かれています。 Core App QualityやTablet App Qualityは是非読んでおきましょう。 ただし、内容は古いものも含まれています。
http://developer.android.com/distribute/essentials/index.html
Stories
成功したアプリの事例が説明されています。 あまり更新されていませんが、Developer Stories: The Opportunity of Android Tabletsなどはタブレット対応が必要だと説明する際の資料として使えます。
Androidでよく使うdp指定まとめ
dpとは
dpの仕組みについては過去にまとめています。
本記事ではレイアウトを組んだり画像を用意する際によく使う数字をいくつか紹介したいと思います。 レイアウトの場合はそのままdp指定できますが、画像はdpサイズを元に各dpi用の画像を生成してください。 下記表の倍率をdpに掛けたものが画像サイズになります。
汎用密度 | 倍率 | dp | px |
---|---|---|---|
ldpi | x0.75 | 48dp | 32px |
mdpi | x1 | 48dp | 48px |
hdpi | x1.5 | 48dp | 72px |
xhdpi | x2 | 48dp | 96px |
xxhdpi | x3 | 48dp | 144px |
xxxhdpi | x4 | 48dp | 192px |
レイアウト系
Androidのレイアウトでよく利用されるdpサイズについて記述します。 Android Developersの記述とMaterial Designガイドラインでは一部のボタンサイズやパディングなどが異なりますが、Android Developersの記述はMaterial Designに限らずあらゆるデザインに利用できる指針として一度目を通したほうが良いでしょう。
8dp
Androidレイアウトにおいて、各部品の間隔は8dpが基本です。 この指定は48dpリズムに基づくものなので、詳しくは後述の48dpを参照してください。
http://developer.android.com/design/style/metrics-grids.html#48dp-rhythm
16dp
アイテムのステータス表示やアクションのための小さいアイコンサイズは16x16dpです。 ただし、実際に見える領域は余白を設けて中央12x12dpに収めることとされています。 48dpの章でも触れていますが、タッチ可能な部品は最低32dpとされているため、このアイコンが操作可能な場合はTouchDelegateやpaddingを利用して配置したほうが良いでしょう。
http://developer.android.com/design/style/iconography.html#small-contextual
24dp
通知に利用するアイコン(スモールアイコン)サイズは24x24dpです。 このアイコンは透明な背景に白単色で描画されている必要があります。
http://developer.android.com/design/style/iconography.html#notification
32dp
ActionBarのアイコンサイズは32x32dpです。 ただし、実際に見える領域は余白を設けて中央24x24dpに収めることとされています。
http://developer.android.com/design/style/iconography.html#action-bar
48dp
タッチ操作可能な部品は余白を含めて48dpを最小単位として配置すべきです。 一般的なAndroid端末において48dpは9mm前後で表示されるため、ユーザーは正確に狙った部品を操作することができます。 48dp内のpadding指定や部品間の間隔についても下記ページが参考になります。 デザイン上部品の表示領域を小さくする場合でもpaddingやTouchDelegateを利用してタッチ領域が32dpを下回らないようにしましょう。
http://developer.android.com/design/style/metrics-grids.html#48dp-rhythm
また、48dpはAndroidアプリのアイコンサイズでもあります。 アプリアイコンに関してはxxxhdpiまで提供することが推奨されています。
http://developer.android.com/design/style/iconography.html#launcher
64dp
Notificationの高さは64dpです。 ただし、BigPictureStyleなどのBig View Styleが指定されている場合、展開すると256dpで表示されます。 このため、BigPictureStyleで画像が実際に表示される領域は256-64=192dpとなります。
http://developer.android.com/guide/topics/ui/notifiers/notifications.html#CustomNotification
240dp
Navigation Drawerの幅は240〜320dpにすべきです。 ただし、320dpにした場合一部のスマートフォンではNavigationDrawerで埋まってしまいます。 コンテンツによりますが、SlidingPaneLayoutでもこの幅を利用したほうが良いかもしれません。
https://developer.android.com/design/patterns/navigation-drawer.html
文字サイズ
Androidフレームワークでは文字サイズは以下のようになっています。 特別な理由がない限りはこれに従ったほうが良いでしょう。
Material Design
Material Designガイドラインでも各要素のサイズやパディングなどが細かく指定されていますが、本来アニメーションやジェスチャなど全ての要素を含めてMaterial Designです。 ガイドラインから数字だけ抜き出して既存のレイアウトに当てはめても一見Material Design風になるだけで色々違和感が出てきてしまうので、ここでは個別の要素のdpについて説明はしません。
http://www.google.com/design/spec/layout/structure.html http://www.google.com/design/spec/layout/metrics-keylines.html
端末サイズ系
Androidにおけるdp解像度は画素密度と実解像度で計算されるため、端末の実サイズによって大体の範囲が決まっています。 フルHDのスマートフォンであってもハーフHDのタブレットであってもスマートフォン/タブレットでレイアウトを切り替えられるのは、このdp解像度のおかげです。 Androidでは端末の向きに左右されない短辺のdpを端末種別の判断に利用する場合が多いです。
320dp
Androidにおいて、一般的なスマートフォンの横幅は320-384dpとなっています。 Nexus6をスマートフォンに含める場合、Androidのスマートフォン向けレイアウトは横幅320-410dpの間で破綻がないことが求められます。 最近では横幅320dpの端末は少なくなっていますが、最低限確認だけはしておきましょう。
480dp
DELL Streakのようなごく一部の端末が短辺480dpとなっています。 480dp未満以上600dp未満という範囲に広げても端末数は多くなく、去年発売された端末ではXperia Z Ultraの540dpくらいです。 わざわざこれらの端末向けにレイアウトを構成するよりもスマートフォン用レイアウトが崩れないように努力したほうが良いでしょう。
600dp
7インチタブレットの大半は短辺が600dp、長辺が960dpとなっています。
そのため、7インチを含むタブレット向けリソースはsw600dp
で区別できます。
sw600dp
は幅や高さではなく短辺による指定のため、端末の向きに影響されないことに注意しましょう。
7インチ以上のタブレットで横向きだけ区別したい場合はsw600dp-land
またはw960dp
を利用します。
720dp
Android Developersでは10インチタブレットを判別する方法としてsw720dp
が挙げられています。
ただし、近年発売された10インチタブレット端末のほとんどは短辺800dpとなっているため、sw720dp
の境界テストは難しくなっています。
sw800dp
に引き上げようにもアスペクト比の異なるNexus9などが768dpとなっているため、なかなか変更できません。
10インチタブレット向けにはひとまずsw720dp
で設定し、768dpと800dpの2種類で確認したほうが良いでしょう。
10インチタブレットの横向きだけ区別ためにsw720dp-land
が利用できます。
タブレットUIアンチパターン
はじめに
Android Developersではいくつかのページに渡ってタブレット端末のUI設計について説明しています。 本記事ではそれらの説明を元に、タブレットでアプリを表示した際に問題となりやすいデザインアンチパターンについて説明します。
参考URL
- Supporting Tablets and Handsets
- Tablet App Quality
- Planning for Multiple Touchscreen Sizes
- Multi-pane Layouts
- Developer Stories: The Opportunity of Android Tablets
シングルペインレイアウト
Android Developersではタブレット向けUIとしてマルチペインレイアウトを推奨しています。 これはタブレットにおけるシングルペインレイアウトが以下のような様々な問題を生みやすいためです。
ListViewの全幅表示
タブレットの横向き画面でシングルペインレイアウトのListViewを全幅表示すると個々の要素の表示領域が大幅に拡大される上に表示可能なリスト要素数が減るため、デザイン上の問題が非常に多くなります。 Android Developersでも「ListViews and menus should not use the full screen width.」と明記されています。
ボタンの全幅表示
シングルペインレイアウトでButtonの幅をmatch_parentとしていた場合、タブレットではボタンの幅が広くなりすぎる場合があります。 このようなボタンは大抵幅のみが拡大されるため、Android Developersでは「10 x 0.5-inch buttons」と表現されています。
TextViewの全幅表示
シングルペインレイアウトでTextViewの幅をmatch_parentとしていた場合、タブレットでは表示文字数が多くなりすぎる場合があります。 Android Developersでは行あたりの文字数は50-75文字程度が最適であり、最大でも100文字程度とされています。 (ただし、これは英語圏の話なので日本語環境では最適な文字数は異なると思われます)
EditTextの全幅表示
シングルペインレイアウトでEditTextの幅をmatch_parentとしていた場合、タブレットでは表示文字数が多くなりすぎる場合があります。 特に一行のEditTextの場合、入力文字数制限よりもはるかに幅が大きくなってしまう場合があります。
シングルペインのまま解決する
マルチペインレイアウトにすることが推奨されていても、やはり導入が難しい場合もあります。 そのような場合のための解決方法をいくつか紹介します。
コンテンツの幅を制限し、画面全体を中央寄せしてしまうことで、シングルペインレイアウトの横幅に関する問題を緩和することができます。
画面内の要素を並び替え、マルチペインレイアウト風にみせる方法も有効です。 この方法では画面の表示単位をスマートフォンと分ける必要がないため、Master/Detailパターンのマルチペインレイアウトを導入するよりも簡単です。
リストコンテンツの場合、複数列ならべる(グリッド化する)ことで横方向への融通が効くようになります。 RecyclerViewを利用すると様々な表示に対応できます。
参考URL:
http://developer.android.com/distribute/essentials/quality/tablets.html#optimize-layouts http://developer.android.com/training/design-navigation/multiple-sizes.html#multi-pane-layouts
画面方向が固定されている
スマートフォンでは縦方向固定、タブレットでは横方向固定という仕様のアプリも見かけますが、できるだけ両方向に対応すべきです。 特にListViewを使った画面では縦方向で使えたほうが情報量が多くなって便利になります。 ただし、画面回転に関する注意点として、Android Developersでは画面は向きが変わっていても同一の機能を持つように努力すべきと書かれています。 つまり、マルチペインレイアウトの画面は回転させてもマルチペインレイアウトと同等の機能を提供するよう努力すべきということで、なかなか難しい問題です。 Android Developersではマルチペインレイアウトを回転させた場合のレイアウトパターンについてはいくつか提案されています。
参考URL:
http://developer.android.com/design/patterns/multi-pane-layouts.html http://developer.android.com/training/design-navigation/multiple-sizes.html#orientations
また、SlidingPaneLayoutを使うと回転にも対処しやすくなります。
ダイアログの多用
タブレットに限らずAndroidアプリ全般でダイアログの多用は非推奨となっていますが、特にマルチペインレイアウトとダイアログの組み合わせは画面のどの領域がダイアログの発生要因なのかわかりづらくなる場合があります。 ダイアログを利用すべきパターンについてはAndroid Developersに明確な指針があるため、これに従いましょう。
参考URL:
http://developer.android.com/design/patterns/confirming-acknowledging.html
特に、以下のようなダイアログはマルチペインレイアウトと相性が悪くなります。
読み込み中ダイアログ
Master/DetailパターンにおいてDetail領域の表示に読み込み中ダイアログを表示した場合、ダイアログが表示されている間はMaster領域も操作できなくなってしまいます。 このような場合はダイアログを利用せず、Detail領域内でProgressBarを表示したほうが良いでしょう。
入力エラー時のダイアログ
EditTextなどの入力チェックでダイアログを利用している場合も画面全体が操作不能になってしまい不便です。 入力部品にはsetErrorメソッドが用意されているので、これで代用可能かどうか検討しましょう。
ActionBarタブ・ドロップダウンリストの置き換え方法まとめ
はじめに
API level 21以降、NAVIGATION_MODE_LISTやNAVIGATION_MODE_TABSといったActionBarと連動したナビゲーション要素が非推奨となりました。 これらのUIの置き換え方法についてはAndroid Developersで該当定数のリファレンスに「Consider using other common navigation patterns instead.」と記述されており、リンク先のページの「Changing view within a screen」という項目では以下のような実装案が文字列でのみ提示されています。
Examples of such view changes are:
- Switching views using tabs and/or left-and-right swipes
- Switching views using a dropdown (aka collapsed tabs)
- Filtering a list
- Sorting a list
- Changing display characteristics (such as zooming)
具体的な置き換え例がないためか、いまでもそのまま利用しているアプリも多いですが、非推奨となってしまったからにはいつかは置き換える必要があります。 特にNAVIGATION_MODE_TABSはAPI level 21以降導入されたToolbarと共存できないため、できるだけ早く他の実装に置き換えるべきです。
ActionBar.NAVIGATION_MODE_TABS
ActionBar.NAVIGATION_MODE_TABSは名前の通りActionBarと一体化したタブUIを提供していましたが、API level 21以降非推奨となりました。 同様の機能を提供していたappcompat-v7版もr21以降非推奨となっています。
このタブUIはスマートフォンではActionBarの真下に表示される全幅のタブバーとして表示されますが、横画面(landscape)やタブレットではではActionBar内に格納され、さらに表示領域が足りない場合はドロップダウンリストになります。 さらにActionBarの一部だったためにNavigationDrawerよりも上のレイヤーに表示されてしまうなど、独特の扱いづらさがありました。
ActionBar.NAVIGATION_MODE_TABSの大半はViewPagerと組み合わせて利用されていたので、本項でもViewPagerとの組み合わせについて説明します。 また、Material DesignガイドラインにもタブUIの説明があるので、こちらも参照してください。
Tabs - Components - Google design guidelines
PagerTitleStrip/PagerTabStrip で置き換える
PagerTitleStripおよびPagerTabStripはViewPagerと合わせて実装されたViewPagerの上下にページ名を表示できるUIです。 ただし、これは見た目からもわかる通り現在表示中のページ名を表示するインジケータとしての役割が強く、ActionBarタブの置き換えにはあまり向いていません。 また、ViewPagerと密着したレイアウト構造のため、ActionBarと連動してアニメーションで非表示にするといったUIにしづらいこともデメリットになります。
PagerTitleStrip、PagerTabStripはViewPagerの見た目と違いは下記のブログ記事が詳しいです。
PagerTitleStripよりPagerTabStripのほうがいいと思う | made in kuluna
SlidingTabs で置き換える
SlidingTabsはAndroid Developersのサンプル(Apache License 2.0)に含まれているタブ実装になります。 「Sliding」という名の通り、ページ遷移時に現在ページを示すインジケータがスライドするアニメーションが入ることが特徴です。 SlidingTabsに関するサンプルは2種類用意されていますが、サンプルアプリの実装の違いなのであまり意識しなくても良いでしょう。
SlidingTabsBasic | Android Developers SlidingTabsColors | Android Developers
このサンプルアプリはレイアウトが標準的でない上あまり説明が親切でないため、実際に導入する際の手順を簡単に説明します。 前提条件として、appcompat-v7のToolbarをある程度実装してるプロジェクトを想定しています。
まず、サンプルアプリのviewクラス2つを自分のプロジェクトにコピーします。
SlidingTabLayout.java SlidingTabStrip.java
次に、レイアウトファイルでToolbarの真下にSlidingTabLayoutを配置します。 このとき、SlidingTabLayoutのbackgroundをcolorPrimaryにしておくとToolbarと並んだときに背景色が同色になります。
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" android:id="@+id/container" android:orientation="vertical" android:layout_width="match_parent" android:layout_height="match_parent"> <android.support.v7.widget.Toolbar android:id="@+id/tool_bar" android:layout_width="match_parent" android:layout_height="wrap_content" android:background="?attr/colorPrimary" android:minHeight="?attr/actionBarSize"> </android.support.v7.widget.Toolbar> <MY_PACKAGE.SlidingTabLayout android:background="?attr/colorPrimary" android:id="@+id/sliding_tabs" android:layout_width="match_parent" android:layout_height="wrap_content" /> <android.support.v4.view.ViewPager android:id="@+id/view_pager" android:layout_width="match_parent" android:layout_height="0px" android:layout_weight="1" /> </LinearLayout>
ソース側ではSlidingTabLayout#setViewPager
により対象のViewPagerを設定するだけでViewPagerの動きと連動するようになります。
@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity); Toolbar toolbar = (Toolbar) findViewById(R.id.tool_bar); setSupportActionBar(toolbar); ViewPager viewpager = (ViewPager) findViewById(R.id.view_pager); viewpager.setAdapter(new MyAdapter()); SlidingTabLayout slidingTabLayout = (SlidingTabLayout) findViewById(R.id.sliding_tabs); slidingTabLayout.setViewPager(viewpager); }
これだけでも動作するようになっていますが、SlidingTabLayout
はToolbarとの連携を意識したクラスになっていないため、選択中タブのフッターバーデフォルト色が固定値になっています。
SlidingTabLayout#setSelectedIndicatorColors
で色を指定することでも設定できますが、Toolbarと背景色をあわせるのであれば、フッターバーはアクセント色(colorAccent)を読み込むようにしたほうが良さそうです。
SlidingTabString.java
75行目の以下の文を置き換えます。
mDefaultTabColorizer.setIndicatorColors(DEFAULT_SELECTED_INDICATOR_COLOR);
このとき、appcompat-v7を利用している場合はR.attr.colorAccent
ではなくandroid.support.v7.appcompat.R.attr.colorAccent
を指定しないとうまく取得することができません。
TypedValue accentValue = new TypedValue(); context.getTheme().resolveAttribute(android.support.v7.appcompat.R.attr.colorAccent, accentValue, true); final int accentColor= accentValue.data; mDefaultTabColorizer.setIndicatorColors(accentColor);
以上で最低限の設定は完了です。 SlidingTabLayout/SlidingTabStripはあまり複雑な処理はしていないので、このようにデザインやアニメーションなどをカスタマイズしましょう。
PagerSlidingTabStrip で置き換える
PagerSlidingTabStripというMaterialDesignに対応したタブUIライブラリが提供されているようです。 カスタマイズに利用できるattr属性も多いようなので、SlidingTabsをカスタマイズするよりも簡単に好みのデザインにできそうです。
NAVIGATION_MODE_LIST
ActionBar.NAVIGATION_MODE_LISTはActionBarから呼び出せるドロップダウンリストのUIを提供していましたが、API level 21以降非推奨となりました。 同様の機能を提供していたappcompat-v7版もr21以降非推奨となっています。 NAVIGATION_MODE_TABSと異なり、現状はNAVIGATION_MODE_LISTはToolbarを利用した場合でも動作しますが、やはり早い段階で置き換えたほうが良いでしょう。
Material DesignsガイドラインのMenusコンポーネントのページに近いUIの説明があります。 Menus - Components - Google design guidelines
Spinner(with Toolbar) で置き換える
NAVIGATION_MODE_LISTはもともとSpinnerAdapterを利用するようになっており、UIもSpinnerとほぼ一緒です。 そのため、Toolbar内にSpinnerを配置し、元と同じAdapterをセットしてやるだけでほぼ同じ見た目のまま置き換えることができます。
元のNAVIGATION_MODE_LISTによる実装が以下のようになっていたとします。
@Override protected void onCreate(Bundle savedInstanceState) { // 略 getSupportActionBar().setNavigationMode(ActionBar.NAVIGATION_MODE_LIST); getSupportActionBar().setListNavigationCallbacks( ArrayAdapter.createFromResource(this, R.array.list_items, android.R.layout.simple_spinner_dropdown_item), new ActionBar.OnNavigationListener() { @Override public boolean onNavigationItemSelected(int i, long l) { // 処理 return true; } }); getSupportActionBar().setDisplayShowTitleEnabled(false); }
Spinnerに置き換えるため、Toolbarの中にSpinnerを配置します。 (下記レイアウトはToolbarと関係ない部分を省略しています)
<android.support.v7.widget.Toolbar android:id="@+id/tool_bar" android:layout_width="match_parent" android:layout_height="wrap_content" android:background="?attr/colorPrimary" android:minHeight="?attr/actionBarSize"> <Spinner android:id="@+id/tool_bar_spinner" android:layout_width="wrap_content" android:layout_height="wrap_content" /> </android.support.v7.widget.Toolbar>
次に、先述のActivityの実装を以下のように変更します。
@Override protected void onCreate(Bundle savedInstanceState) { // 略 Toolbar toolbar = (Toolbar) findViewById(R.id.tool_bar); setSupportActionBar(toolbar); Spinner spinner = (Spinner) toolbar.findViewById(R.id.tool_bar_spinner); spinner.setOnItemSelectedListener(new AdapterView.OnItemSelectedListener() { @Override public void onItemSelected(AdapterView<?> parent, View view, int position, long id) { // 処理 } @Override public void onNothingSelected(AdapterView<?> parent) { } }); spinner.setAdapter(ArrayAdapter.createFromResource(this, R.array.list_names, android.R.layout.simple_spinner_dropdown_item)); }
これでほぼ同じ見た目のままToolbar内のSpinnerに実装を置き換えることができました。
2014発売Android端末のdp解像度まとめ
はじめに
Android端末は機種数が多く、OSバージョンやハードウェアがそれぞれ異なるためにAndroidでアプリを作ることは大変だと言われています。 特にディスプレイについてはそれぞれが異なった画面サイズや解像度を持つため、Androidの画面設計は複雑だと思われがちです。
実際、OpenSignalのAndroid断片化調査の中でも以下のような画像とともに画面サイズの断片化について触れています。
しかし、Androidにはdp(密度非依存ピクセル)という実際の画面サイズ、解像度に依存しない形で画面を扱うための仕組みが用意されており、このdpを使うことでAndroidの画面サイズ断片化への対応コストは大幅に削減することができます。 dpの概要については過去に記事を書きましたので、そちらを参照してください。
断片化とdpについての基本的な説明は下記ブログに簡単な例と図入りでまとめられているので、ぜひ一読しておきましょう。
The Android Screen Fragmentation Myth | Rusty Rants
本題
最近のAndroid端末の画面サイズ断片化状況を把握するため、2014年に国内キャリアから発売された端末のdp解像度を調査しました。 デバイスの分類については、Android Developers上ではフォン(スマートフォン)とタブレットの2種類となっていますが、どちらにも含まれない端末があるため、 記事中ではそれらの端末を「ファブレット」として分類しました。
この記事の調査で作成した一覧表(Googleスプレッドシート)
スマートフォン
Android Developersの定義では、スマートフォン端末は320-384dpの横幅を持つとされています。 一部の端末は物理ボタンを持っており、ナビゲーションバーが表示されないためアプリを描画可能な範囲が広くなりますが、Kitkat以降ではナビゲーションバーの制御も可能になっているため今回の調査では物理ボタンの有無を区別していません。
スマートフォンのdp解像度
dp解像度 | 量子化密度 | 端末数 |
---|---|---|
360x640 | hdpi | 1 |
360x640 | xhdpi | 8 |
360x640 | xxhdpi | 22 |
360x640 | xxxhdpi | 5 |
320x569.3 | hdpi | 1 |
dp解像度の分類でみると、ほぼすべての端末が360x640dpとなっており、最近発売されたスマートフォンに対してはこのdp解像度を基準にデザイン設計を行えば良いことがわかります。 ただし横幅320dpの機種も1機種のみ発売されているため、320dpでも崩れないことを確認したほうが良いでしょう。
スマートフォンの一覧
スマートフォン端末の解像度とdpはそれぞれ以下のようになっています。 GALAXY Note Edgeのエッジスクリーン領域は除外しています。
機種名 | 対角線長 | W(px) | H(px) | dpi | 量子化密度 | W(dp) | H(dp) | 備考 |
---|---|---|---|---|---|---|---|---|
AQUOS PHONE SERIE mini SHL24 | 4.5 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
URBANO L02 | 4.7 | 720 | 1280 | 320 | xhdpi | 360 | 540 | 物理ボタン |
G Flex LGL23 | 6 | 720 | 1280 | 320 | xhdpi | 360 | 540 | |
HTC J butterfly HTL23 | 5 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
TORQUE G01 | 4.5 | 720 | 1280 | 320 | xhdpi | 360 | 640 | 物理ボタン |
URBANO L03 | 5 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | 物理ボタン |
AQUOS SERIE SHL25 | 5.2 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
GALAXY S5 SCL23 | 5.1 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | 物理ボタン |
Xperia ZL2 SOL25 | 5 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
isai FL LGL24 | 5.5 | 1440 | 2560 | 640 | xxxhdpi | 360 | 640 | |
isai VL LGV31 | 5.5 | 1440 | 2560 | 640 | xxxhdpi | 360 | 640 | |
URBANO V01 | 5 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | 物理ボタン |
Xperia Z3 SOL26 | 5.2 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
GALAXY Note Edge SCL24 | 5.6 | 1440 | 2560 | 640 | xxxhdpi | 360 | 640 | 物理ボタン・エッジスクリーン |
GALAXY S5 SC-04F | 5.1 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | 物理ボタン |
AQUOS ZETA SH-04F | 5.4 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
Disney Mobile on docomo SH-05F | 5 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
Xperia Z2 SO-03F | 5.2 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
Xperia A2 SO-04F | 4.3 | 720 | 1280 | 320 | xhdpi | 360 | 640 | |
ARROWS NX F-05F | 5 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
らくらくスマートフォン3 F-06F | 4.5 | 720 | 1280 | 320 | xhdpi | 360 | 640 | |
GALAXY Note Edge SC-01G | 5.6 | 1440 | 2560 | 640 | xxxhdpi | 360 | 640 | 物理ボタン・エッジスクリーン |
GALAXY S5 ACTIVE SC-02G | 5.1 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | 物理ボタン |
AQUOS ZETA SH-01G | 5.5 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
Disney Mobile on docomo SH-02G | 5.5 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
Xperia Z3 SO-01G | 5.2 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
Xperia Z3 Compact SO-02G | 4.6 | 720 | 1280 | 320 | xhdpi | 360 | 640 | |
ARROWS NX F-02G | 5.2 | 1440 | 2560 | 640 | xxxhdpi | 360 | 640 | |
AQUOS PHONE Xx mini 303SH | 4.5 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
AQUOS CRYSTAL 305SH | 5 | 720 | 1280 | 320 | xhdpi | 360 | 640 | |
AQUOS Xx 304SH | 5.2 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
シンプルスマホ2 401SH | 4.5 | 720 | 1280 | 320 | xhdpi | 360 | 640 | |
Xperia Z3 401SO | 5.2 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
CRYSTAL X 402SH | 5.5 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 | |
AQUOS PHONE ef WX05SH | 4 | 480 | 854 | 240 | hdpi | 320 | 569.3 | |
DIGNO T 302KC | 4.5 | 540 | 960 | 240 | hdpi | 360 | 640 | 物理ボタン |
DM016SH | 5.2 | 1080 | 1920 | 480 | xxhdpi | 360 | 640 |
ファブレット
ファブレットの定義はAndroid Developers上にはありません。 ただし、分類表で未分類の短辺が384dpより大きく、600dpよりも小さい端末はファブレットと呼べそうです。 この記事ではAndroid Developersに従い短辺が600dpのものはタブレット扱いとしましたが、これらの端末は7インチ前後のものが大半のようなので、今後ファブレットとして扱われるようになる可能性もあります。
ファブレットのdp解像度
今回の分類ではファブレット端末は2機種しか該当しません。
機種名 | 対角線長 | W(px) | H(px) | dpi | 量子化密度 | W(dp) | H(dp) |
---|---|---|---|---|---|---|---|
Xperia Z Ultra SOL24 | 6.4 | 1080 | 1920 | 320 | xhdpi | 540 | 960 |
Nexus 6 | 5.96 | 1440 | 2560 | 560 | 560dpi | 410 | 730 |
Xperia Z Ultraの540x960がタブレット最小dp解像度の短辺を60dp短くしただけなのに対して、Nexus6の410x730dpはかなり特殊です。 Nexus6が他のWQHD端末と同様のxxxhdpiであれば360x640dpの標準的なスマートフォンだったはずですが、わざわざ560dpiを定義して410x730dpとすることでこの数字を中心としたファブレットという枠組みを作ろうとしているのかもしれません。 今後のガイドラインの更新に期待しましょう。
タブレット
Android Developers上の分類ではタブレットは短辺600-800dp、長辺800-1280dpの端末を指します。 スマートフォンと違い、量子化密度が高い端末はあまり多くありません。 タブレットのみ、表中のW=長辺、H=短辺としています。
タブレットのdp解像度
dp解像度 | 量子化密度 | 端末数 |
---|---|---|
960x600 | xhdpi | 3 |
1024x768 | xhdpi | 1 |
1280x800 | mdpi | 1 |
1280x800 | hdpi | 2 |
1280x800 | xhdpi | 3 |
傾向としては、タブレット端末は最小の短辺600dpと最大の1280dpに集中しています。 それぞれ7インチと10インチの端末が多く、8インチでは混在しています。 この2つはアスペクト比も同じため、デザイン上それほど大きな問題にはならないでしょう。 問題はNexus9の1024x768で、アスペクト比が4:3のスクエアディスプレイ端末になります。 とはいえ、960x600dpに対応できていれば縦方向の拡大幅が大きいだけなので、縦スクロールの多いAndroidアプリでは極端な表示崩れとはならないはずです。
タブレットの一覧
機種名 | 対角線長 | W(px) | H(px) | dpi | 量子化密度 | W(dp) | H(dp) | 備考 |
---|---|---|---|---|---|---|---|---|
AQUOS PAD SHT22 | 7 | 1920 | 1200 | 320 | xhdpi | 960 | 600 | |
Xperia Z2 Tablet SOT21 | 10.1 | 1920 | 1200 | 240 | hdpi | 1280 | 800 | |
GALAXY Tab S SCT21 | 10.5 | 2560 | 1600 | 320 | xhdpi | 1280 | 800 | 物理ボタン |
ASUS MeMO Pad 8 AST21 | 8 | 1920 | 1200 | 320 | xhdpi | 960 | 600 | |
Xperia Z2 Tablet SO-05F | 10.1 | 1920 | 1200 | 240 | hdpi | 1280 | 800 | |
GALAXY Tab S 8.4 SC-03G | 8.4 | 2560 | 1600 | 320 | xhdpi | 1280 | 800 | 物理ボタン |
ARROWS Tab F-03G | 10.5 | 2560 | 1600 | 320 | xhdpi | 1280 | 800 | |
AQUOS PAD SH-06F | 7 | 1920 | 1200 | 320 | xhdpi | 960 | 600 | |
Nexus9 | 8.9 | 2048 | 1536 | 320 | xhdpi | 1024 | 768 | |
MediaPad M1 8.0 403HW | 8 | 1280 | 800 | 160 | mdpi | 1280 | 800 |
まとめ
スマートフォン、タブレットのどちらにも分類できない端末が出てきたことで、全体としては画面サイズの断片化が進んだ形になっています。 ただしスマートフォン、タブレットに該当する端末に関してはdp解像度が集中していること、サポート範囲が明確に示されていることから、カテゴリの中での断片化はほぼ免れているといっても良いでしょう。 ファブレットに関してはまだ機種が少ないこともありどのような形に落ち着くのか不明ですが、ひとまずNexus6の410dpまでサポートできるようにスマートフォン向けレイアウトを組んだほうが良いかもしれません。 横幅540dpのXperia Z Ultraの存在はAndroid Developersでタブレットの分類を「sw600dp」としているため対応が難しくなっています。タブレット判定用のsw600dpを変更することは難しいので、何かルールが決まるまでは対応端末としないか、多少使いづらくともスマートフォン向けレイアウトで対応するしかなさそうです。