こんにちは、Habrahabr! 少し前、
マテリアルデザインコンテストの結果をまとめました。コメントでは、本当に人気のある美しいマテリアルアプリケーションを表示するように依頼されました。 さて、会いましょう:Sberbank Onlineの新しいモダンなインターフェース。 作成者自身からアプリケーションを作成するプロセスについて学ぶことはより興味深いです。
Sberbank Androidアプリケーションの開発チームに発言権を与え、モバイルバンククライアントのUIのような複雑なものを作成した経験について直接聞いていただけるようにします。 投稿のほとんどは
freeuserによって書かれた
ので 、彼に感謝します。 ;)
背景
Material Designに基づくAndroid 5は、1年半の間ユーザーに提供されています。 18か月はかなりの期間であり、ユーザーと開発者の両方がGoogleからの情報を提示するための視覚言語の哲学を好んだと自信を持って言うことができます。
本日は、拡張および開発チームでAndroid用
Sberbankオンラインアプリケーションからマテリアルデザインへの移行プロセスがどのように進行したかを説明し、関連する技術的側面を強調します。 インターフェイスを直接作成するプロセスについては、次の記事で詳しく説明します。
問題の声明
私たちの主なタスクは、使いやすく便利で理解しやすいアプリケーションを作成することです。 同時に、マテリアルデザインへの移行により、開発プロセスの質的改善が可能になります。 つまり、プログラマーとデザイナーは「プロセス」に気を取られず、結果に気を取られます。
Googleが開発した単一の視覚言語により、何をすべきかについて考えることが少なくなり、その方法の問題に集中することができました。 そして、以前の試み(Holo)がiOSとのインターフェースのトレースや自転車の発明を止めなかった場合、新しいシステム(MD)はデザインの喜びをほぼ完全に「殺し」ました。 アプリケーションは退屈でも単調でもなくなりましたが、より均一になりました。MDは、ユーザーと開発者の両方にとって便利なインターフェイスの連続性を維持しながら、視覚言語の利用可能なツールと機能を極めて自由に使用できます。 すべてのアプリケーションが同じように機能し、それらのさまざまなインターフェイス要素が同じように機能する場合、新しいアプリケーションに慣れる必要はありません。 取って使用します。
シンプルさ、使いやすさ、効率性は、新しいアプリケーションに取り組む際に私たちが始めた重要な概念です。
既存の問題
開発に関する一般的な問題はほとんど同じです:
- プログラマは常にレイアウトに注意を払っていません。
- デザイナーは、プログラマーにとって特定のレイアウトの実装がいかに面倒かを十分に認識していません。
- 1つのレイアウト(レイアウト)の変更は、他のレイアウトによって自動的にスケーリングされません。
これらの「一般的な」問題の根本にあるのは、非常に具体的な不幸であり、残念ながら解決するのは非常に困難です。 デザイナーとプログラマーはそれぞれの言語を話し、お互いを理解していません。 誤解とは何ですか?
- プログラマーは、デザイナーの思考をシミュレートすることはできません。そのため、レイアウトの最初から何をすべきかを確立できません。
- 設計者は、スケーラブルでレイアウトに正確に対応できるようにするために、プログラマにどのような情報を提供すべきかを知りません。
典型的なワークフローの特別なケースを考えてみましょう:
アプリケーション画面のレイアウトで、デザイナーはテキストのサイズと色、要素の幅と高さに注意する必要があります。 コミュニケーションがゼロであるため(結果として、お互いのニーズと能力をゼロで理解できる)、タスクは真っ先に解決されます。値はモックアップに直接縫い付けられます-サイズ、色。
さらに、レイアウト設計者は、値をマークアップにハードノックするか、新しいリソース(サイズ、色)を開始するか、既存のリソースを値で検索しようとします。
マークアップへの値のリジッドステッチングまたはリソースの体系化されていない確立は、同じ値を再利用できないことを伴います。DRY原則に違反し、一般にデザインとそのスタイルを分離する論理そのものです。 そのようなアプリケーションでの作業は、スタイル値の半分がdiv内で直接示されるWebページと同じくらい「楽しい」ものです。
情報セルのテキストの色を変更する必要がある場合は、各マークアップを実行する必要があります(この場合、ファイルをスキップする可能性はゼロではありません)。 「一貫して複数の色/インデントをチェックする」実験中に、操作のコストが何度も増加します。
最後に、体系的にリソースのエイリアスが開かれていない場合、おそらくその名前は新しい画面とは無関係であり、プログラマは完成したリソースを使用する代わりに新しいエンティティを作成します。
この混乱をすべて回避するには、作業チームに健全な雰囲気を確立する必要があります。
- プログラマーとデザイナーの間のコミュニケーションを確立する必要があります。お互いのニーズと能力を理解し、受け入れなければなりません。
- アプリケーションのユニバーサルでスケーラブルなレイアウトを構築するために必要なデータのリストは明確に修正する必要があります。したがって、プログラマーは必要なすべての値を取得し、デザイナーは新しい画面を構築するときに既存の値を構築できます。
正しい方法で行う
プログラマーとデザイナーの間のコミュニケーションを構築する一種の「最初の橋」は、
Google Material Guidelinesでした。 ガイドラインは、デザイナーの創造的な思考を妨げないほど柔軟であると同時に、プログラマーによるモデリングに便利なパターンを決定します。
OS Androidのスケーラブルレイアウトには、スタイルなどのツールが使用されます。 スタイルは、属性と値のペアのセットです。 属性値には、色、ColorStateList、Drawable、テキスト、サイズ、およびその他のスタイルを指定できます。
最新のプラットフォームとAppCompatライブラリのリソースを調べると、スタイルが次のグループに分類されていることがあります。
- TextAppearance-テキストフィールドの外観。 テキストとリンクの色、テキストフィールドのツールチップ、選択したテキストの背景、フォントスタイルと書体を決定します。
- ウィジェットスタイル-ビュースタイル。 特定のウィジェットに固有の属性(ProgressBarのprogressDrawableなど)を定義します。TextViewのウィジェットスタイルとその子孫は、使用されるTextAppearanceを示すことができます。
- テーマがテーマです。 テーマは一種の「スタイルのスタイル」、活動主義のスタイルです。 この画面に固有の主要な属性、ウィジェットスタイルを定義します。 テーマを適切に構成して、レイアウト内のウィジェットの色とスタイルへの直接リンクを回避し、アプリケーション内のビューの外観を統一します。
- ThemeOverlay-ウィジェットのスタイルとテーマの中間の位置を占めます。 通常のウィジェットスタイルが1つのビューのみに適用される場合、テーマは画面内のすべてのビューに適用され、ThemeOverlayはマークアップ内の特定のコンテナー(ViewGroup)に配置されます。 将来的には、正確にどこでどのように使用されるかを示します。
この場合、通常構築されるワークフローは次のようになります。
- Googleマテリアルガイドラインに基づいたプログラマーとデザイナーは、単一のリソーステーブルを作成します(記事の後半で説明します)。
- 各リソース(サイズ、スタイル、色)にはエイリアスが割り当てられます。
- レイアウトのデザイナーは、エイリアスを正確に示します。 このエイリアスによって、プログラマはリソース(サイズ、スタイル)を見つけ、マークアップでそれを示します。
スタイルのプロパティ
スタイルの設定に取りかかる前に、このツールのプロパティを詳しく見てみましょう。最大限の効率でこのツールを活用できます。
スタイルの継承
スタイルは、2つの方法で相互に継承できます。 これが最初のものです:
<style name="Theme"> <item name="android:isLightTheme">false</item> <item name="android:colorBackground">@color/bright_foreground_dark</item> </style> <style name="Theme.Material"> <item name="android:colorBackground">@color/foreground_material_dark</item> </style>
Theme.Materialは、親テーマテーマからisLightTheme属性の値を継承し、colorBackground値をオーバーライドします。
2番目の方法は、親を明示的に指定することです。
<style name="Theme.Material"> <item name="android:isLightTheme">false</item> </style> <style name="Theme.AppCompat.Light.NoActionBar"> <item name="android:isLightTheme">true</item> </style> <style name="Theme.Material.Sbrf" parent="Theme.AppCompat.Light.NoActionBar"> </style>
この場合、Theme.Material.Sbrfは、Theme.AppCompat.Light.NoActionBarのisLightTheme属性の値を継承します。
属性値の参照
低レベルのスタイル(TextAppearanceおよびWidgetスタイル)は、テーマで設定された属性の値を参照できます。
アプリケーションには、赤と黄色の2つのテーマがあるとします。 黄色のテーマの画面では、一部のTextAppearanceがTextViewを黄色の背景に設定し、赤色のテーマの画面-赤い背景に設定する必要があります。
<style name="TextAppearance.Example" parent="TextAppearance.AppCompat.Title"> <item name="android:textColor">?attr/colorPrimary</item> </style> <style name="Theme.Example" parent="Theme.AppCompat.Light.NoActionBar"> </style> <style name="Theme.Example.Red"> <item name="colorPrimary">@color/color_primary_red</item> <item name="colorPrimaryDark">@color/color_primary_red_dark</item> </style> <style name="Theme.Example.Yellow"> <item name="colorPrimary">@color/color_primary_yellow</item> <item name="colorPrimaryDark">@color/color_primary_yellow_dark</item> </style>
TextAppearance.ExampleにTextViewを配置させます。
<TextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_gravity="center" android:textAppearance="@style/TextAppearance.Example" android:text="Test Text"/>
次に、このウィジェットにTextAppearanceを適用すると、AndroidはtextColor値の代わりに、このトピックで規定されているcolorPrimary値をそのまま使用します。
スタイルとテーマをカスタマイズする
主なアプリケーションの色
アプリケーションの原色を示す属性を検討してください。
属性
| 予定
|
カラープライマリ
| アプリケーションのメイン色。 通常、AppBarにペイントされます
|
colorPrimaryDark
| メインカラーの暗いバージョン-ステータスバーに使用
|
カラーアクセント
| アクセントカラーアプリケーション。 ボタン、SeekBar、ProgressBarに間接的に使用されます
|
android:colorBackground
| 背景のデフォルト色
|
android:colorForeground
| 二次背景色の反対
|
android:colorForegroundInverse
| 二次背景色
|
水平の
| 水平分割色
|
縦型
| 垂直分割線の色
|
Sberbankにはブランド本があり、それに応じて、印刷物、オンライン広告、ウェブサイト、名刺、パッケージなど、すべてを作成する必要があります。 公式の色は規制されており、「最も近い類似物」も規制されています。 ブランドブックに従って、アプリケーションのメインカラー(colorPrimary)は緑になり、アクセント(colorAccent)-オレンジになりました。 さらに、colorPrimaryは肯定的なアクション(確認、購入)を指し、colorAccentは原則として否定的なアクション(キャンセル)を指します。
TextViewのスタイル設定
AppCompatライブラリが提供するテキストの色を扱うときです。 合計2つのテーマ(暗色と明色)があり、それぞれに標準と反転の2つの色のグループがあります。 暗いテーマ(Theme.AppCompatの相続人)の場合、明るい色合いが標準の暗い色合いになります。 ライトテーマ(Theme.AppCompatから値も継承する)の場合、それぞれ反対のことが当てはまります。
ライブラリによって設定される色には、独自の「名前」と機能的な目的があります。
- textColorPrimaryは、色の最も「ジューシーな」形式です。
- textColorSecondaryは、少し薄い色の形式です。
- textColorTertiaryはさらに薄い形式です。
- textColorHint-EditTextのツールチップの色。
- textColorLink-リンクの色。
- textColorHighlight-選択したテキストの背景色。
- textColorPrimaryActivated-通常の状態、textColorPrimaryと同じ、アクティブな状態-textColorPrimaryInverse
- textColorSecondaryActivated-textColorPrimaryActivatedに似ていますが、2次色のみがあります。
さらに、textColorPrimaryDisableOnly(CompoundButtonのテキストに使用されるラジオボタン、チェックボックス)、またはtextColorPrimaryNoDisable、textColorSecondaryDisableOnly、textColorSecondaryNoDisableが最後の3つのスタイルの検出に失敗したような「気味悪い」名前の色があります。
アプリケーションで使用される色のテーブルをコンパイルしました。 各属性にColorStateList値(利用可能な要素とアクセスできない要素の色のペア)を割り当てます。
属性
| 通常の色
| アクセスできない状態の色(無効な要素)
|
textColorPrimary
| #E6000000(90%黒)
| #44000000(26%黒)
|
textColorSecondary
| #CC000000(80%黒)
| #44000000(26%黒)
|
textColorTertiary
| #88000000(53%黒)
| #44000000(26%黒)
|
textColorHint
| #61000000(38%黒)
| #19000000(10%黒)
|
textColorPrimaryInverse
| #FFFFFFFF(100%ホワイト)
| #44FFFFFF(26%ホワイト)
|
textColorSecondaryInverse
| #E8FFFFFF(91%ホワイト)
| #44FFFFFF(26%ホワイト)
|
textColorTertiaryInverse
| #96FFFFFF(59%ホワイト)
| #44FFFFFF(26%ホワイト)
|
textColorHintInverse
| #61FFFFFF(38%ホワイト)
| #19FFFFFF(10%ホワイト)
|
テキスト情報を視覚的に表示するために、AppCompatは色だけでなく、フォントサイズとスタイルでも機能します。 このパラメーターのセットは、TextAppearanceと呼ばれます。
役職
| テキストの色
| フォントサイズ
| 書体
|
キャプション
| 二次
| 12sp
| レギュラー
|
Body1
| 一次
| 14sp
| レギュラー
|
Body2
| 一次
| 14sp
| 中
|
ボタン
| 一次
| 14sp
| 中
|
小見出し
| 一次
| 16sp
| レギュラー
|
メニュー
| 一次
| 16sp
| 中
|
役職
| 一次
| 20sp
| 中
|
見出し
| 一次
| 24sp
| レギュラー
|
ディスプレイ1
| 二次
| 34sp
| レギュラー
|
ディスプレイ2
| 二次
| 45sp
| レギュラー
|
ディスプレイ3
| 二次
| 56sp
| レギュラー
|
ディスプレイ4
| 二次
| 112sp
| 軽い
|
これは表には示されていませんが、タイトルとメニューの反転したテキストの外観も定義されています。
整形式のテキストの外観の良い例は
、 マテリアル の Googleマテリアルデザイン ガイドラインにあり
ます 。 これらのスタイルとガイドラインからの情報に基づいて、開発者はデザイナーとともに次のテキスト外観ファミリを作成しました。
役職
| テキストの色
| フォントサイズ
| 書体
|
キャプション
| 三次
| 12sp
| レギュラー
|
ヒント
| ヒント
| 14sp
| レギュラー
|
サブヘッダー
| 三次
| 14sp
| 中
|
ボタン
| 一次
| 14sp
| 中
|
ボディ0
| 三次
| 14sp
| レギュラー
|
Body1
| 二次
| 14sp
| レギュラー
|
Body2
| 一次
| 16sp
| レギュラー
|
Body3
| 二次
| 16sp
| 中
|
入力1
| 一次
| 20sp
| レギュラー
|
入力2
| 三次
| 20sp
| レギュラー
|
役職
| 一次
| 20sp
| 中
|
見出し
| 一次
| 24sp
| レギュラー
|
ディスプレイ1
| 一次
| 32sp
| レギュラー
|
ディスプレイ2
| 三次
| 32sp
| レギュラー
|
上記の各TextAppearance(Buttonを除く)から、Inverse、Primary、およびAccentバリアントを作成します(textColor * Inverse、colorPrimary、colorAccent属性値は、テキストの色に使用されます)。
デザイナーがレイアウトを提供するとき、テキストフィールド(TextView)の反対側では、略称「Title Default」がTextAppearance.Material.Sbrf.Titleに対応し、「Subheader Inverse」がTextAppearance.Material.Sbrf.Subheader.Inverseに対応することを示します。
EditTextのスタイリング
テキストの色とデザインを多かれ少なかれ理解し、すべてを整理する必要がある場所がもう1つありました。EditText要素とTextInputLayout要素についてです。 問題は、「デフォルトのテーマ」が乱雑に見え、風水でとかす必要があることです。 :)
不注意のために、私たちは説明する:
- EditText行は、焦点が合っておらず変形した状態では淡いはずです。
- フォーカスされた状態のEditText行は、黒オレンジではなく、緑一色(colorPrimary)でなければなりません。
- エラーは赤ではなく、オレンジ(colorAccent)で強調表示されます;。
- EditTextのフォントサイズは大きくする必要があります。
AppCompatライブラリ内で、マークアップからビューを作成するときに、AppCompatActivityが特定のウィジェットをAppCompat継承者に置き換えていることがわかりました。 これは明らかに、AppCompatテーマから背景の色付けとプルスタイルをサポートするために行われます。 特に、EditTextはAppCompatEditTextに置き換えられました。 (したがって、カスタムウィジェットが必要な場合は、EditTextから直接ではなく、AppCompatEditTextからサブクラスを作成する必要があります)。
AppCompatEditTextスタイルは、editTextStyle属性を介してテーマに設定されます。 デフォルトのスタイルはWidget.AppCompat.EditTextで、特定のTextAppearance、背景、およびテキストの色を定義します(つまり、TextAppearanceの色は無視されます)。
バージョン5.0のEditText背景のレイアウトを見てみましょう(古いバージョンの場合、背景は一般的に似ていますが、5.xのようにレイアウト自体、または以前のバージョンのウィジェットコンストラクターで、色付けが発生する唯一の違いがあります) )
<inset xmlns:android="http://schemas.android.com/apk/res/android" android:insetLeft="@dimen/edit_text_inset_horizontal_material" android:insetRight="@dimen/edit_text_inset_horizontal_material" android:insetTop="@dimen/edit_text_inset_top_material" android:insetBottom="@dimen/edit_text_inset_bottom_material"> <selector> <item android:state_enabled="false"> <nine-patch android:src="@drawable/textfield_default_mtrl_alpha" android:tint="?attr/colorControlNormal" android:alpha="?attr/disabledAlpha" /> </item> <item android:state_pressed="false" android:state_focused="false"> <nine-patch android:src="@drawable/textfield_default_mtrl_alpha" android:tint="?attr/colorControlNormal" /> </item> <item> <nine-patch android:src="@drawable/textfield_activated_mtrl_alpha" android:tint="?attr/colorControlActivated" /> </item> </selector> </inset>
そして、ここにリソースtextfield_default_mtrl_alphaとtextfield_activated_mtrl_alpha自体があります:
マークアップからわかるように、細い線がcolorControlNormal属性の値である色で色付けされています。 この色を置き換えます。
<color name="color_control_normal">#1A000000</color> <style name="Theme.Material.Sbrf" parent="@style/Theme.AppCompat.Light.NoActionBar"> <item name="colorControlNormal">@color/color_control_normal</item> </style>
ColorControlActivatedは、フォーカス状態(およびカーソルとテキスト選択ハンドルの色)を担当します-それも変更してみましょう。colorPrimaryと同じ意味を持ちます。
<style name="Theme.Material.Sbrf" parent="@style/Theme.AppCompat.Light.NoActionBar"> <item name="colorControlActivated">?attr/colorPrimary</item> </style>
EditTextフォントサイズ-TextAppearanceで設定します。
<style name="TextAppearance.Material.Sbrf.EditText" parent="@style/TextAppearance.Material.Sbrf.Input1"> </style> <style name="Widget.Material.Sbrf.EditText" parent="@style/Widget.AppCompat.EditText"> <item name="android:textAppearance">@style/TextAppearance.Material.Sbrf.EditText</item> </style> <style name="Theme.Material.Sbrf" parent="@style/Theme.AppCompat.Light.NoActionBar"> <item name="editTextStyle">@style/Widget.Material.Sbrf.EditText</item> </style>
結果:
EditTextのスタイリングが完了しました。 TextInputLayoutの時間です。 デフォルトでは、Widget.Design.TextInputLayoutスタイルをそれ自体に適用し、そこから次の属性を抽出します。
- hintTextAppearance-フォーカスされた状態のフローティングラベル(画面上では「ヒント」という言葉が表示されます)のTextAppearance。
- android:textColorHint-フォーカスされていない状態のフローティングラベルの色、EditTextのツールチップの色。 TextInputLayoutの属性値が指定されていない場合、EditTextの同じ属性の値が取得されます。
- android:hint-フローティングラベルの実際のテキストは、EditText自体のヘルプをオーバーロードします。
- hintAnimationEnabled-プロンプトをEditTextからフローティングラベルに「切り替える」ときにアニメーションを使用するかどうか。
- errorTextAppearance-エラーのあるラベルのTextAppearance。 この場合、EditText行は淡色表示されます。
- errorEnabled-TextInputLayoutのレンダリング時にエラーのあるラベルの下に場所を描画するかどうか。
- counterTextAppearance-テキスト長カウンターのTextAppearance。
- counterEnabled-TextInputLayoutをレンダリングするときにテキスト長カウンターをレンダリングするかどうか。
- counterMaxLength-最大許容テキスト長。
- counterOverflowTextAppearance-テキストエラーインジケーターの長さを超えるインジケーターのTextAppearance。
補助TextViewのTextAppearanceプロパティのテーブルを作成しましょう。 それらはすべてTextAppearance.AppCompat.Caption(textColorSecondary、12sp、レギュラー)を継承し、色のみが変更されます。
役職
| テキストの色
|
TextAppearance.Design.Hint
| ?attr / colorControlActivated
|
TextAppearance.Design.Error
| #FFDD2C00
|
TextAppearance.Design.Counter
| ?attr / colorControlActivated
|
TextAppearance.Design.Counter.Overflow
| #FFDD2C00
|
その後、すべてが簡単です。テキストの色をcolorAccentに置き換えます。
<style name="TextAppearance.Material.Sbrf.Error" parent="@style/TextAppearance.Material.Sbrf.Caption"> <item name="android:textColor">?attr/colorAccent</item> </style>
このTextAppearanceをTextInputLayoutスタイルに適用します。
<style name="Widget.Material.Sbrf.TextInputLayout" parent="@style/Widget.Design.TextInputLayout"> <item name="errorTextAppearance">@style/TextAppearance.Material.Sbrf.Error</item> </style>
新しく作成したスタイルをマークアップのTextInputLayoutに適用します。 取得したものは次のとおりです。
最後に、重要な改善を行います。 通常、各ウィジェットにはテーマ内に属性があり、そのコンストラクターに従って、テーマに関連するスタイルを取ることができます。 TextInputLayout(Designライブラリの他のウィジェットと同様)には、テーマにそのような属性はありません。 アプリケーション側で紹介します:
<declare-styleable name="Theme.Material.Sbrf"> <attr name="textInputLayoutStyle" format="reference"/> </declare-styleable>
トピックに紹介しましょう:
<style name="Theme.Material.Sbrf" parent="@style/Theme.AppCompat.Light.NoActionBar"> <item name="textInputLayoutStyle">@style/Widget.Material.Sbrf.TextInputLayout</item> </style>
これで、この属性を使用してマークアップでウィジェットスタイルを取得できます。
<android.support.design.widget.TextInputLayout style="?attr/textInputLayoutStyle" android:layout_width="match_parent" android:layout_height="wrap_content">
AppBarのスタイル設定
テキストフィールド、フォント、色で管理しました。 整理する必要がある重要な要素がまだ2つあります:AppBarとToolbarです。 典型的なアクティビティでは、マテリアルデザインを使用する場合、トップパネルのスタイルはアクティビティのコンテンツとは異なります。つまり、背景、テキストの色が異なります。 Googleは、このためにactionBarTheme属性を使用することを期待しています。 彼と一緒に働きます。
actionBarTheme属性は、個々のViewGroup、その子、その子などに適用される一種のミニテーマであるThemeOverlayを参照します。 ThemeOverlayを適用すると、アクティビティテーマの同じテーマ属性が新しい値を取得します。 より明確にするために、3つのスクリーンショットを検討します:最初はスタイルもThemeOverlayも上部のバーとウィジェットに適用されず、2番目は緑色のスタイルとThemeOverlayを白いテキストで使用し、3番目-白いスタイルとThemeOverlayが緑色のテキストを使用します。
AppBarLayoutの背景色。 デザインライブラリのリソースは、このウィジェットの背景がアプリケーションのプライマリカラー(colorPrimary)でペイントされていることを示しています。 AppBarLayoutのスタイルを作成します。
<style name="Widget.Material.Sbrf.AppBarLayout" parent="@style/Widget.Design.AppBarLayout"> </style> <style name="Widget.Material.Sbrf.AppBarLayout.Colored"> </style> <style name="Widget.Material.Sbrf.AppBarLayout.White"> <item name="android:background">?android:attr/colorForegroundInverse</item> </style>
TextInputLayoutと同様に、テーマにappBarLayoutStyle属性を作成し、マークアップで実際のウィジェットスタイルを取得します。
TabLayoutスタイル。 AppBarLayoutを使用したタスクと同様に解決されます。
ツールバーのアイコンの色は、 colorControlNormal属性を使用して設定されます。 ただし、対処する必要があるいくつかの問題があります。 フォーカスのない状態で、EditText行に色colorControlNormanを使用しました(確定的なProgressBarおよびSeekBarで塗りつぶされていない進行状況の色に自動的に使用される色)。 白いテキストを含むThemeOverlayは、colorControlNormalを#FFFFFF(白)としてオーバーライドします。 緑色のThemeOverlayは、colorControlNormal as?Attr / colorPrimaryをオーバーライドします(覚えているように、緑色があります)。
ThemeOverlayを定義します。
<style name="Theme.Material.Sbrf" parent="@style/Theme.AppCompat.Light.NoActionBar"> <item name="colorControlNormal">@color/color_control_normal</item> <item name="appBarLayoutStyle">@style/Widget.Material.Sbrf.AppBarLayout</item> </style> <style name="Theme.Material.Sbrf.Colored"> <i></i> <item name="actionBarTheme">@style/ThemeOverlay.Material.Sbrf.ActionBar.Colored</item> <item name="appBarLayoutStyle">@style/Widget.Material.Sbrf.AppBarLayout.Colored</item> </style> <style name="Theme.Material.Sbrf.WhiteActionBar"> <i></i> <item name="actionBarTheme">@style/ThemeOverlay.Material.Sbrf.ActionBar.White</item> <item name="appBarLayoutStyle">@style/Widget.Material.Sbrf.AppBarLayout.White</item> </style> <style name="ThemeOverlay.Material.Sbrf" parent="@style/ThemeOverlay.AppCompat.Light"> <item name="colorControlNormal">@color/color_control_normal</item> </style> <style name="ThemeOverlay.Material.Sbrf.ActionBar"> <i></i> <item name="searchViewStyle">@style/Widget.AppCompat.SearchView.ActionBar</item> </style> <style name="ThemeOverlay.Material.Sbrf.ActionBar.Colored"> <i></i> <item name="colorControlNormal">?android:attr/textColorPrimaryInverse</item> </style> <style name="ThemeOverlay.Material.Sbrf.ActionBar.White"> <i></i> <item name="android:colorForeground">@color/color_foreground</item> <item name="android:colorForegroundInverse">@color/color_foreground_inverse</item> <item name="colorControlNormal">?attr/colorPrimary</item> </style>
そしてそれらをマークアップに適用します:
<android.support.design.widget.AppBarLayout android:id="@+id/app_bar_layout" style="?attr/appBarLayoutStyle" android:layout_width="match_parent" android:layout_height="wrap_content" app:theme="?attr/actionBarTheme"> <android.support.v7.widget.Toolbar android:id="@+id/toolbar" android:layout_width="match_parent" android:layout_height="wrap_content"/> <i></i> <android.support.design.widget.TabLayout android:id="@+id/tab_layout" style="?attr/tabLayoutStyle" android:layout_width="match_parent" android:layout_height="wrap_content" android:clipToPadding="false" android:paddingLeft="0dp" app:tabMode="fixed"/> </android.support.design.widget.AppBarLayout>
左端からツールバーのテキストのインデント。 Googleマテリアルガイドラインでは、Upボタンがある場合は72dpに、そうでない場合は16dpに設定する必要があります。 あるいは、2つの異なるインデントを持つそのようなアクティビティの2つの異なるテーマに2つの異なるツールバースタイルを配置できます。 1つの重要でないパラメーターのためにスタイル全体を変更するのではなく、このパラメーター自体を変更することにしました。
トピックで新しい属性を取得しましょう:
<<b>declare-styleable name="Theme.Material.Sbrf"</b>> <<b>attr name="toolbarContentInsetStart" format="dimension"</b>/> </<b>declare-styleable</b>>
新しいツールバースタイルを定義します。
<style name="Widget.Material.Sbrf.Toolbar" parent="@style/Widget.AppCompat.Toolbar"> <item name="contentInsetLeft">?attr/toolbarContentInsetStart</item> <item name="contentInsetStart">?attr/toolbarContentInsetStart</item> </style>
2つのテーマで新しい属性を定義し、親テーマではツールバーのスタイルを再定義します。
<style name="Theme.Material.Sbrf" parent="@style/Theme.AppCompat.Light.NoActionBar"> <item name="toolbarContentInsetStart">72dp</item> <item name="toolbarStyle">@style/Widget.Material.Sbrf.Toolbar</item> </style> <style name="Theme.Material.Sbrf.Colored"> <i></i> </style> <style name="Theme.Material.Sbrf.Colored.IconlessList"> <i></i> <item name="toolbarContentInsetStart">16dp</item> </style>
これで、指定されたトピックに応じて、テキストは左端とは異なるインデントになります。 ガイドラインで何をする必要があったか。
ツールバーのテキストの色。 AppCompatスタイルは、テキストのデフォルトの色を設定します:textColorPrimary。 件名自体では、textColorPrimaryは90%黒として巻き上げられます。 緑のThemeOverlayは、textColorPrimaryを100%白としてオーバーライドします。 White ThemeOverlayは、Attr / colorPrimaryとして再定義します。
ThemeOverlayの制限。 AppBarLayout内にあるビューフラグメントには適用しないでください。
おわりに
このアプリケーションは先日、Google Playで利用可能になりました。それでは、改革について検討します。
アプリケーションの作成に必要な時間を大幅に短縮しました。統合されたTextAppearance、インデント、スタイルのおかげで、新しい画面の作成と古い画面の編集が迅速かつ効率的です。 インデントを手動で測定したり、ColorPickerで色を確認したり(そこから色のアルファチャネルを取得)するのに無駄な時間はもうありません:レイアウト内のリソースのエイリアスを見て、適切なリソースを選択してから、続行します。
プログラマーは、UXの問題を解決するとき、彼らが反発するものとデザイナーが意味することを理解しています。 ウィジェットをスタイリングする際に、これを考慮します。 たとえば、デザイナーがレイアウトに緑色のボタンを描いた場合、アプリケーションにはフェースレススタブブリックではなく、押すことに応答するボタンが必要です。 設計者は、Androidプラットフォームのどの要素がネイティブであり、どの要素に大幅な改良が必要で、保守が難しいかを認識しています。
プログラマと設計者の間で確立された理解により、結果をより速く、より信頼性の高いものにすることが可能になりました。 レイアウトの変更は、指をクリックするだけで行われます:緑のアプリバーを白のアプリバーに置き換えるには、費用がかかります(新しいAppBarLayoutスタイルと新しいThemeOverlayを追加し、それらを1つのテーマに結合して、プロジェクト全体のメインに割り当てるだけです)。
当然、いくつかのアイデアは失敗しました。 5つの最小セル高で十分であるという誤った仮定を立てました。 実際には、設計者は設計時にこの特性を使用せず、コンテンツから直接反発されることが判明しました。 インデントの命名システムは失敗し、視覚的ではありませんでした。
それにもかかわらず、採用された規則の大部分は実際には非常に効果的であることが証明されました。 新しいツールを使用して、マテリアルのスタイルで調和のとれたアプリケーションを作成しました。 すべての人を
Google Playに招待して、実際に作業の結果を評価できます。
次の号では、アプリケーションのインターフェースを作成するプロセスについてお話します。