技術部モバイル基盤グループの児山(@nein37)です。モバイル基盤グループではモバイルアプリの開発だけでなく、開発環境の整備や開発効率の向上も重要な目的の一つとしています。

昨年、開発効率向上の一環として行っているアプリのリソース整理の取り組みについてAndroidアプリのリソースを整理して開発効率を改善した話という記事で紹介させて頂きました。今回はそれから1年が経過してリソース整理の状況がどのように変わったか説明していきたいと思います。

前回のあらすじ

詳細は前回の記事に書いてありますが、大体以下のような取り組みを行いました。

未使用リソースの削除
Theme の定義
Style の整理
TextAppearance の定義

これらの作業により、無法地帯だったクックパッドアプリのリソースを整理し、開発効率を大幅に改善することができました。 (と、その当時は思っていました…)

その後発生した様々な問題

トップ画面の大規模変更

去年の9月ごろ行った更新により、アプリのトップ画面の構成が大きく変化しました。

変更前	変更後

この変更にあわせて、以下のようなリソース修正が行われました。

新しいトップ画面にあわせて Style や TextAppearance を追加した
新しいトップ画面に関する大量の Dimen 定義が追加された
元々の定義の一部が他の画面から利用されていたため消さずに残した

画面ごとの Style の乱立

アプリ全体で利用できる汎用的な Style や TextAppearance に関しては前回の作業で定義済みだったのですが、実際にアプリの更新をしていく上で汎用的なリソースでは表現できない様々なデザイン上の例外が追加されていきました。

この画面のこの場所は目立たせたいので 16sp にしたい
この場所は普通のグレーじゃなくて暖かみのあるグレーにしたい… などなど

この当時の命名規則が細かく定まっていなかったため、ある Style がどの画面用のものなのかわからなくなってしまうという問題も発生しました。 Style のスコープがわからないため元々ある Style を再利用しても良いのかどうか判断できず、似たような Style 定義がどんどん追加されていくだけの状態になっていました。

Style 定義の度に質問が飛んでくる

すでに説明してきたとおり、 Style を新規追加するときの命名規則が緩く、定義を追加するかどうか判断するためのフローもなかったため、以下のような質問が押し寄せてくることになりました。

この定義を追加したいんですが良いですか？
この Style のはこの名前で良いですか？
継承元これで良いですか？

などなど。それぞれ考えるとちゃんと答えは出るものの、毎回エンジニアもデザイナーも悩ませてしまい、単純な Style の追加作業に関して手間取らせてしまっていました。

改善に向けて

上記のように本当にいろいろな問題が出てきましたが、これまでのポリシーでも追加するときは既存の定義を真似して追加されていくので一定の秩序はありました。すくなくとも、去年までの無法地帯よりははるかにマシです。

そこで、これまでのポリシーをベースにしながら今回出てきた問題を踏まえてこれまでの運用で問題が出たところを見直し、新しいポリシーを整備することにしました。ここまでで出てきた反省点を改めてまとめると以下のようなものです。

汎用リソースだけではカバーできない部分が多い
- 例外の存在を前提にする必要があった
例外的なリソースを定義する方法が未定
- リソースの定義方法(命名規則、定義場所)を決める必要があった
- Style(TextAppearance) 以外のリソースでも決めておいたほうが良かった
あたらしくリソース定義をした場合、どれが汎用リソースでどれが例外リソースなのかわからない
- 命名規則や記述ファイルで区別可能にしておく必要があった

これらの反省点を踏まえ、以下のような方針でリソースの定義ポリシーを整えることにしました。

本当に汎用的に使える部分のみ汎用リソースとして定義する
- 汎用リソースは記述ファイル名、命名規則などで容易に判別可能にする
- 将来的に汎用にできるかも…などの曖昧な根拠で汎用リソースにしない
汎用リソースで表現できないものに関しては「画面ごとのリソース」として定義する
- 画面ごとのリソースは記述ファイル名、命名規則などで適用範囲を判別可能にする
- 他の「画面ごとのリソース」と同じ定義をしようとしている場合、そのリソースの汎用リソース化を検討する

いままでのポリシーとの違いは主に「アプリ全体で利用するリソースとある画面のみで利用するリソースを明確に区別できるようにする」「あるリソースを汎用リソースにするかどうかを決めるタイミングを明確化する」という2点です。

次項ではリソースの種類ごとに実際の命名規則について説明していきます。

実際の定義ポリシー

Color

Color リソースはその名前の通り色の定義を行うものです。前項と若干矛盾しますが、 Color リソースに関しては定義数が多くなく今後も一括管理可能な範囲に収まるという認識で画面ごとのスコープは設けていません。

クックパッドアプリでは Color リソースの定義に以下のような制約を持たせています。

実装上の制限がない限り、色の指定は Color リソースを参照させる
アプリ内で多用される基本的な色には orange 、 green などの汎用的な名前をつける
各色については用途別に名前をつける(2.で定義した色を参照しても良い)
ColorStateList 、gradient 用の色は名前を揃える(2.で定義した色を参照しても良い)

実際の定義は以下のようになります。

<!-- 2. で言及している基本的な色群 --><color name="green">#8bad00</color><color name="orange">#ff7f00</color><color name="red">#ef6074</color><!-- 3. で言及している用途別の色群 --><color name="recipe">@color/green</color><color name="ranking_arrow_up">@color/orange</color><color name="ranking_arrow_stay">#b8af93</color><color name="ranking_arrow_down">#32a9c0</color><!-- 4. で言及している用途別の色群 --><color name="button_background_primary">@color/orange</color><color name="button_background_primary_pressed">#da6e00</color><color name="button_background_primary_disabled">#ffc17d</color><color name="button_text_primary">@color/white</color><color name="button_text_primary_pressed">#d9d9d9</color><color name="button_text_primary_disabled">#ffe5c9</color>

Dimen

Dimen リソースはViewのサイズや文字サイズ、マージンなどを定義するためのものです。

こちらは画面ごとの定義が非常に多いため、画面ごとのスコープを導入し、以下のような制約を持たせています

実装上の制限がない限りサイズ指定は Dimen リソースを参照させる
アプリ全体で利用する Dimen の基本単位は dimens_base.xmlに記述する
- このとき定義するリソース名は dimen_xxdp とする
アプリ全体で利用する汎用的な定義は dimens_base.xmlに記述する
- このとき定義するリソース名は general_用途名とする
- 値の定義は可能な限り dimen_xxdp を参照する
画面ごとの定義は dimens.xmlに記述する
- このとき定義するリソース名は画面名_用途名とする
- 値の定義は可能な限り dimen_xxdp を参照する

dimens_base.xmlの定義は以下のようになります。

<!-- 2. で言及している Dimen の基本単位群 --><dimen name="dimen_2dp">2dp</dimen><dimen name="dimen_4dp">4dp</dimen><dimen name="dimen_8dp">8dp</dimen><dimen name="dimen_12dp">12dp</dimen><dimen name="dimen_16dp">16dp</dimen><dimen name="dimen_20dp">20dp</dimen><dimen name="dimen_24dp">24dp</dimen><dimen name="dimen_32dp">32dp</dimen><dimen name="dimen_48dp">48dp</dimen><dimen name="dimen_56dp">56dp</dimen><dimen name="dimen_64dp">64dp</dimen><!-- 3. で言及している汎用的な定義 --><dimen name="general_padding">@dimen/dimen_12dp</dimen><dimen name="general_text_padding">@dimen/dimen_12dp</dimen><dimen name="general_card_padding">@dimen/dimen_12dp</dimen><dimen name="general_text_drawable_padding">@dimen/dimen_8dp</dimen><dimen name="general_dialog_padding">@dimen/dimen_8dp</dimen>

dimens.xmlの定義は以下のようになります。

<!-- 4. で言及している画面ごとの定義 --><dimen name="user_registration_activity_top_margin">@dimen/dimen_24dp</dimen><dimen name="user_registration_activity_bottom_margin">@dimen/dimen_24dp</dimen><dimen name="user_registration_contents_margin_top">@dimen/dimen_12dp</dimen><dimen name="user_registration_paragraph_margin_top">@dimen/dimen_32dp</dimen><dimen name="user_registration_paragraph_margin_top_small">@dimen/dimen_24dp</dimen>

わざわざ dimen_xxdp という Dimen リソースを定義しているのが不思議に思えるかもしれませんが、これはデザイナーが画面設計をする際に値をなるべく選択肢の中から選ぶようにすることで統一感を出しやすくするための仕組みです。また、dimen_xxdp を参照していないリソースを「設定値からみても明らかに例外として定義されているもの」として判別することができるようになり、後のリソース整理でも役立てることができ(る予定になってい)ます。

Style

Styleリソースはある種類の View の属性をまとめて定義するためのものです。詳しい定義ポリシーに入る前に、 Style 特有の注意点についていくつか説明していこうと思います。

再利用性を高めるために

アプリデザインの統一感を保つ上で、 Style は非常に重要です。複数の画面で同一の Style を使いまわすことで View の見た目を揃えることができるため、 Style 定義においては定義内容の再利用性を高めることが重要になります。個人的に再利用性を高めるためになるべく Style に定義しないほうが良いと考えている属性は以下のようなものです。

layout_gravity
layout_weight
layout_above
layout_below(など、配置に関するもの全般)

これらの layout_*という属性は View ではなく LayoutParams の属性で、親Viewの種類や属性によっては機能しなかったり意図しない動作になったりします。 layout_width, layout_height, layout_margin あたりは大抵の ViewGroup で動作しますが、上に挙げたような属性は特定の ViewGroup でしか動作しません。 (このあたりは各 LayoutParams の継承を見るとわかりやすいです) Android ではレイアウトファイルの include による再利用もできるようになっているので、特定のView階層構造に依存している場合はincludeを活用するなど再利用性を高める工夫をしていくと良いと思います。

継承の仕組み

Style リソースは「 parent 指定による継承」と「名前による継承」の２つの仕組みを持っています。この2つを組み合わせることで様々な Style 定義を効率的に行うことができます。

parent 指定による継承

parent 指定による継承では親 Style を直接継承して派生 Style を作ることができます。これは主に Android やサポートライブラリの Style を継承する場合に利用します。

<!-- AppCompatのボタンStyle定義を継承してクックパッドのボタンStyle定義を行う例 --><style name="CookpadStyle.General.Button"parent="Widget.AppCompat.Button"><item name="android:background">@drawable/button_background_default</item><item name="android:textAppearance">@style/CookpadFont.General.Button.Text</item><item name="android:paddingTop">@dimen/button_padding_vertical</item><item name="android:paddingBottom">@dimen/button_padding_vertical</item><item name="android:paddingLeft">@dimen/button_padding_horizontal</item><item name="android:paddingRight">@dimen/button_padding_horizontal</item><item name="android:drawablePadding">@dimen/button_drawable_padding</item><item name="android:minWidth">@dimen/button_min_width</item><item name="android:minHeight">@dimen/button_min_height</item><item name="android:textColor">@color/button_text_state</item></style>

名前による継承

すでに存在する Style 名に .(ドット) で続けて別の名前を与えることでその Style を継承することができます。これは主に定義済みの Style のバリエーションを増やすために利用します。

<!-- CookpadStyle.General.Button を継承して Primaryボタン用のstyle定義を行う例 --><style name="CookpadStyle.General.Button.Primary"><item name="android:background">@drawable/button_background_primary</item><item name="android:textColor">@color/button_text_primary_state</item></style>

クックパッドにおける Style 定義のポリシー

以上の注意点を踏まえたクックパッドの Style 定義は以下のようになります。

汎用的な Style 定義は styles_widget.xmlに記述し、以下の要素をドットで繋いだリソース名とする
- CookpadStyle(prefix)
- General(汎用Style定義)
- View(対象Viewの種類)
- Variation(バリエーション、必須ではなく複数でも可)
汎用 Style 定義のうち、バリエーションが特に多いものに関しては View 種類ごとにファイルを切り出す
- styles_button.xmlなど
それ以外の Style 定義については styles.xmlに記述し、以下の要素をドットで繋いだリソース名とする
- CookpadStyle(prefix)
- Screen(画面)
- View(対象Viewの種類)
- Variation(バリエーション、必須ではなく複数でも可)

汎用 Style 定義の例

<!-- 汎用のボタンStyleのうち、最も基本的なもの --><style name="CookpadStyle.General.Button"parent="Widget.AppCompat.Button"><item name="android:background">@drawable/button_background_default</item><item name="android:textAppearance">@style/CookpadFont.General.Button.Text</item><item name="android:paddingTop">@dimen/button_padding_vertical</item><item name="android:paddingBottom">@dimen/button_padding_vertical</item><item name="android:paddingLeft">@dimen/button_padding_horizontal</item><item name="android:paddingRight">@dimen/button_padding_horizontal</item><item name="android:drawablePadding">@dimen/button_drawable_padding</item><item name="android:minWidth">@dimen/button_min_width</item><item name="android:minHeight">@dimen/button_min_height</item><item name="android:textColor">@color/button_text_state</item></style><!-- 汎用のレシピボタンStyle --><style name="CookpadStyle.General.Button.Recipe"><item name="android:background">@drawable/button_background_recipe</item><item name="android:textColor">@color/button_text_recipe_state</item></style><!-- 汎用のレシピボタンStyleにマージンを付与したもの --><style name="CookpadStyle.General.Button.Recipe.WithMargin"><item name="android:layout_marginTop">@dimen/button_margin_vertical</item><item name="android:layout_marginBottom">@dimen/button_margin_vertical</item><item name="android:layout_marginRight">@dimen/button_margin_horizontal</item><item name="android:layout_marginLeft">@dimen/button_margin_horizontal</item></style>

画面ごとの Style 定義の例

<!-- ユーザー登録画面用のEditText Style --><style name="CookpadStyle.UserRegistration.EditText"><item name="colorControlActivated">@color/orange</item><item name="android:textCursorDrawable">@drawable/edit_text_cursor_orange</item><item name="android:background">?android:attr/editTextBackground</item><item name="android:textColorHint">@color/extra_light_gray</item></style>

汎用 Style 定義と画面ごとの Style 定義を比べてみると、まず第2句が General かどうかで汎用 Style かどうか判別可能になっていることがわかると思います。 General であればアプリ全体に適用可能な汎用 Style 、そうでなければ画面ごとのスコープをもった Style です。また、第4句以降が存在している場合、元々存在する Style のバリエーションであることもわかり、 Style 名から定義内容を追う上で役立ちます。

TextAppearance

TextAppearance は文字表示に関する属性だけをまとめた Style のサブセットです。継承などの仕組みは Style に準じていますが、クックパッドアプリではStyleとの大きな違いとして Base TextAppearance という概念が導入されているので先にそちらを説明します。

Base TextAppearance の定義

前回のリソース整理記事でもちらっと触れていますが、クックパッドアプリでは基本的な文字サイズ・文字色・文字スタイルの組み合わせを Base TextAppearance として定義しています。これは dimen_xxdp 同様、デザイナーの新しい TextAppearance に制約を課すために使われています。

Base TextAppearance は text_appearance_base.xmlに記述し、以下の要素をドットで繋いだリソース名とする
- CookpadFont.Base(prefix)
- 文字サイズ(5種類：ExtraLarge/Large/Default/Small/ExtraSmall)
- 文字色(7種類：未指定(Black)/Gray/LightGray/Green/Orange/Red/White)
- 文字スタイル(2種類：未指定(標準)/Bold)
上記の定義について、すべての組み合わせを定義する
Base TextAppearance はこれを継承した TextAppearance を定義する以外の目的で利用しない
- レイアウトファイル内などで直接参照しないこと

Base TextAppearance の定義例

<style name="CookpadFont.Base.ExtraLarge"><item name="android:textColor">@color/black</item><item name="android:textSize">@dimen/extraLargeTextSize</item></style>

...

<style name="CookpadFont.Base.ExtraLarge.Gray"><item name="android:textColor">@color/gray</item></style>

...

<style name="CookpadFont.Base.ExtraLarge.Gray.Bold"><item name="android:textStyle">bold</item></style>

という感じで名前による継承を使いつつ70種類を網羅しています。

TextAppearance の定義

TextAppearance は text_appearance.xmlに記述する
汎用的なTextAppearance 定義は以下の要素をドットで繋いだリソース名とする
- CookpadFont(prefix)
- General(汎用)
- Purpose(目的)
- Style(書体：Emphasis/Main/Sub/Weaken)
それ以外の TextAppearance 定義は以下の要素をドットで繋いだリソース名とする
- CookpadFont(prefix)
- Screen(画面)
- Purpose(目的)
- Style(書体：Emphasis/Main/Sub/Weaken)

Purpose(目的) はその TextAppearance を何の表示のために定義するかを書くところで、例えば「RecipeTitle」や「UserName」といったものが入ります。 Style(書体)はその TextAppearance が同一のスコープ、目的の中でどういう位置づけにあるかを示しています。このStyle(書体)の概念は Base TextAppearance の文字サイズや太字などとは無関係に定義されるもので、「このスコープ、目的に関してはこの組み合わせが Main 」「この組み合わせが Sub 」という定義をデザイナーが相談しながら決定しています。

TextAppearance の定義例

<!-- 汎用のレシピタイトル --><style name="CookpadFont.General.RecipeTitle.Main"parent="CookpadFont.Base.Large.Green.Bold" /><!-- 汎用のレシピタイトル(小) --><style name="CookpadFont.General.RecipeTitle.Sub"parent="CookpadFont.Base.Default.Green.Bold" /><!-- 汎用のレシピタイトル(強調) --><style name="CookpadFont.General.RecipeTitle.Emphasis"parent="CookpadFont.Base.ExtraLarge.Green.Bold" /><!-- レシピ一覧画面におけるレシピタイトル --><style name="CookpadFont.RecipeList.RecipeTitle.Main"parent="CookpadFont.Base.Small.Green.Bold" />

Styleと同様に、第2句の内容を見ることでその TextAppearance が汎用定義なのか画面ごとの定義なのかを知ることができるようになりました。 TextAppearance はすべての定義が Base TextAppearance を parent によって継承するため名前による継承が行われないので少しシンプルですね。

まとめ

これまで説明してきたようなリソースの定義ポリシーを策定したことで、各リソースのスコープや意味合いについて格段に管理がしやすくなりました。アプリの改修によってリソース自体が増殖していくという問題は引き続き発生しますが、画面スコープなどの導入によって今後無秩序な状態に陥ることはなくなったと思います。こういった Style や TextAppearance のルールづくりは非常に地味で面倒な作業ですが、長期的にはエンジニア・デザイナー双方の作業を効率化することができます。今回定義ポリシーを策定するにあたってはデザイナーとつきっきりで「どういう場合に例外リソースの定義が必要か」「例外はどういったスコープで捉えれば良いか」というような事について話しながら進めました。特に dimen_xxdp による制約や TextAppearance の文字サイズの定義と連動しない4段階の Style(書式) といった概念はデザイナーの提案から生まれたものです。こういった細かい部分にまでデザイナーの思想を反映していくことでエンジニア・デザイナーの意思疎通が少しでも簡単になればと思っています。