Android Style Guide

Follow a standard coding style in android, it will be easier for you and also for others to understand your code easily.

We made this specifically for our organisation Greentech Apps Foundation

1. Package Structure

A feature based package structure:

• Clearer feature dependency and interface boundaries.
• Easier to understand the components that define the feature.
• Reduces risk of unknowingly modifying unrelated or shared code.
• Simpler navigation: most related classes will be in the one package.
• Easier to remove a feature.

The alternative approach of defining your packages by how a feature is built (by placing related Activities, Fragments, Adapters etc in separate packages) can lead to a fragmented code base with less implementation flexibility. Most importantly, it hinders your ability to comprehend your code base in terms of its primary role: to provide features for your app.

• com.client.app.feature - contain all feature packages
• com.client.app.db - contain all db related classes
• com.client.app.models - contain all models
• com.client.app.utils - contain utility/misc classes
• com.client.app.widgets - contain extended/custom views

2. Naming conventions

Layout Files

• activity_<ACTIVITY NAME>.xml - for all activities
• dialog_<DIALOG NAME>.xml - for all dialogs
• item_<LIST_NAME>.xml - for custom item for listview/recyclerview
• fragment_<FRAGMENT_NAME>.xml - for all fragments

strings.xml

Consider prefixing with layout name or sections, so that we know which sections it belong to

Use namespaces. Eg. global_ or error_, etc.

Bad

<string name="network_error">Network error</string>
<string name="call_failed">Call failed</string>
<string name="map_failed">Map loading failed</string>

Good

<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>

Write string values in normal conventions (do not capitalize all characters, use textAllCaps on a TextView).

Bad

<string name="error_message_call">CALL FAILED</string>

Good

<string name="error_message_call">Call failed</string>

colors.xml

• Treat colors.xml as palette of colors. Instead of defining color per elements, define a few color theme to be used in the application.

BAD:

<resources>
    <color name="button_foreground">#FFFFFF</color>
    <color name="button_background">#2A91BD</color>
</resources>

GOOD:

<resources>
    <!-- grayscale -->
    <color name="white">#FFFFFF</color>
   
    <!-- basic colors -->
    <color name="blue">#2A91BD</color>
</resources>

dimens.xml

• You should also define a “palette” of typical spacing and font sizes, for basically the same purposes as for colors. A good example of a dimens file:

<resources>
<!-- font sizes -->
    <dimen name="font_22sp">22sp</dimen>
    <dimen name="font_18sp">18sp</dimen>
    <dimen name="font_15sp">15sp</dimen>
    <dimen name="font_12sp">12sp</dimen>
<!-- typical spacing between two views -->
    <dimen name="spacing_40dp">40dp</dimen>
    <dimen name="spacing_24dp">24dp</dimen>
    <dimen name="spacing_14dp">14dp</dimen>
    <dimen name="spacing_10dp">10dp</dimen>
    <dimen name="spacing_4dp">4dp</dimen>
<!-- typical sizes of views -->
    <dimen name="btn_height_60dp">60dp</dimen>
    <dimen name="btn_height_40dp">40dp</dimen>
    <dimen name="btn_height_32dp">32dp</dimen>
</resources>

You should use the spacing_**** dimensions for layouting, in margins and paddings, instead of hard-coded values, much like strings are normally treated. This will give a consistent look-and-feel, while making it easier to organize and change styles and layouts.

Resource IDs

Use camelCase convention and preprend the viewType before the actual function

• Button — btn
• EditText — et
• TextView — tv
• Checkbox — cb
• RadioButton — rb
• ToggleButton — tb
• Spinner — spn
• Menu — mnu
• ListView — lv
• RecyclerView — rv
• LinearLayout -ll
• RelativeLayout — rl

Bad

<Button
id="@+id/submit_button"
/>
<Button
id="@+id/submit_btn"
/>
<Button
id="@+id/btn_sumbit"
/>

Good

<Button
id="@+id/btnSubmit"
/>

Drawable Files

Naming convention for Drawable files

Classes & Interfaces

Written in UpperCamelCase

BAD:

interface onClickListener

GOOD:

interface OnClickListener

Methods & Variables

Written in lowerCamelCase

BAD:

public void SetValue(){
}
public int mPublicFielD;
public int public_field;

GOOD:

public void setValue(){
}
public int publicField;

• Static final fields should be written in UPPERCASE, with an underscore separating words

public static final int THE_ANSWER = 42;

TODO comments

Use TODO temporary codes. Add a date.

GOOD:

// TODO: Remove this code after all production mixers understand.
// TODO: Change this to use a flag instead of a constant. 22 jun 18
// TODO: Remove this code after the UrlTable has been checked in. 22.10.18

Feel free to submit any type of suggestions for improving the coding standard

Happy Coding!!!

Feel free to check out all our apps at playstore