Resource naming in Android can get messy pretty quickly if you don't set good guidelines from the get go. Luckily it's pretty simple once you invest a little time to think about it. We're also here to help, let's cover some of the most important sub categories of resources.
Option 1: Suffix view type
Suppose we have a signup view. We have signup button, this would be named:
Suppose now we decide to add a button to allow signup via facebook:
Option 2: Prefix view type
If we take the above example we would have:
Option 2 advantages:
- Well structured - We go from something generic to something more specific as we move down the chain.
Code completion :)
- Typing in button.. will filter for only buttons and present you with buttons and due to the structure adding more information will further filter until you're easily able to get what you need.
Colors are particularly special since they, arguably more than anything, define your branding. Colors are essentially the core of your design.
Option 1: Name by value
Option 2: Name by function
Option 3: Name by function - keeping an internal palette
Let's examine this via an example:
<resources> <color name="black">#000000</color> <color name="dark_grey">#525F6B</color> <color name="darker_grey">#d4d7da</color> <color name="light_grey">#a8afb5</color> <color name="grey_40">#a8afb5</color> <color name="grey_50">#a8afb5</color> <color name="grey_60">#a8afb5</color> <color name="darker_than_light_grey">#7d8790</color> <color name="grey_seperator">#005691</color> <color name="grey_list_divider">#00639a</color> <color name="intermediate_grey">#78BE20</color> <color name="pearl_grey">#BFC0C2</color> <color name="soft_grey">#EFEFF0</color> <color name="light_blue">#008ECF</color> <color name="red">#E20015</color> <color name="turquoise">#00A8B0</color> <color name="white">#ffffff</color> </resources>
This is a small snippet using option 1 as its approach.
This does not scale. As the project grows and as more colors become necessary, how we use the same colors in different contexts for different views becomes more confusing and less traceable. Also, how do we name similar colors? Dark, dark grey, darker than dark grey?
Colors named in this way are not expressive - Asking what "blue" is will reap different results from person to person. What's intermediategrey? Also... darkerthanlightgrey?
When setting the color for a view element, e.g. for a button, it is pretty hard to keep in mind “What color was defined for my primary button? grey40, grey50, darkerthanlightgrey or darkgrey? Guess I have to take a look in my colors.xml and the designer guidelines“.
Instead this can be improved by naming colors in relation to their function/purpose. Furthermore, when doing this we should name from general function to more specific function (e.g. buttonprimary, buttonsecondary, buttonprimaryenabled, buttonprimarytext).
Let's consider setting the color for a button again, this time using the name-by-function approach. Two things happen:
- I think about the design use case “What type of button do I want to implement? A primary, a secondary or a ghost button? I want a primary button right here, so I need the ‘button_primary’ color!“.
- I start typing “button” for my color name, and code completion begins to give me a small list of potential options. Seeing as I know this is a primary button I will conveniently chose that.
Can we improve this? YES! Enter option 3.
The one problem with this approach is that we may end up with multiple color resources with the same value. This is where defining a palette for internal use comes in to save the day.
resources> <!-- Colors to apply in views --> <color name="button_primary">@color/stock_x_green</color> . . . <!-- Palette colors --> <!-- Colors for "internal use" only --> <!-- General palettes --> <color name="black">#000000</color> <color name="red">#34fgfj</color> <!-- Palette Green --> <color name="green_brand">#005691</color> <color name="green_dark">#00639a</color> <!-- Palette gray --> <color name="gray_athens">#EFEFF0</color> <color name="gray_chateau">#a8afb5</color> <color name="gray_iron">#d4d7da</color> <color name="gray_oslo">#7d8790</color> <color name="gray_shuttle">#525F6B</color> <color name="gray_silver_sand">#BFC0C2</color> </resources>
Naming internal colors is arguable, one approach is as follows:
Notice we have a palette for each color. Palette colors should be prefixed. Notice that any color with only has a single variation can be put in a general palette, and until necessary a prefix can be omitted.
Another is to name them as they are named in our UI kit / Design spec (i.e. how our designers named them). I think this is ideal since we maintain a common language between teams.
With dimensions we can treat them in pretty much the same you would colors.
Take the same approach of "name generic to concrete" and create "palettes" here too:
<!-- font sizes --> <dimen name="text_xs">10sp</dimen> <dimen name="text_s">12sp</dimen> <dimen name="text_m">14sp</dimen> <dimen name="text_l">18sp</dimen> <dimen name="text_xl">24sp</dimen> <!-- typical spacing (margins and padding) --> <dimen name="spacing_xs">4dp</dimen> <dimen name="spacing_s">10dp</dimen> <dimen name="spacing_m">14dp</dimen> <dimen name="spacing_l">24dp</dimen> <dimen name="spacing_xl">40dp</dimen> <!-- typical sizes of views --> <dimen name="button_primary_height">60dp</dimen> <dimen name="button_secondary_height">40dp</dimen>
The following was taken from: [https://github.com/futurice/android-best-practices#dimensxml](https://github.com/futurice/android-best-practices#dimensxml)
Name your strings with keys that resemble namespaces, and don't be afraid of repeating a value for two or more keys. Languages are complex, so namespaces are necessary to bring context and break ambiguity.
<string name="network_error">Network error</string> <string name="call_failed">Call failed</string> <string name="map_failed">Map loading failed</string>
<string name="error_message_network">Network error</string> <string name="error_message_call">Call failed</string> <string name="error_message_map">Map loading failed</string>
Don't write string values in all uppercase. Stick to normal text conventions (e.g., capitalize first character). If you need to display the string in all caps, then do that using for instance the attribute
[textAllCaps](http://developer.android.com/reference/android/widget/TextView.html#attr_android:textAllCaps) on a TextView.
<string name="error_message_call">CALL FAILED</string>
<string name="error_message_call">Call failed</string>
Most developers really don't put much time into thinking about simple stuff like resource naming. I have to sometimes force myself, particularly at early stages of a new project, to not say "I'll add this resource now and name it properly later." Because as the project grows I will always place other things as a higher priority. Having this structure set from the get go makes things a lot easier in the long run and is really low effort once you get into the habit.
- Name from "generic-to-specific"
- Name by function
- Maintain internal palettes
- Name String resources to resemble namespaces