Android Coding Standards Best Practices

This document states the coding standards to be taken care of while android development

• Use full English descriptors that accurately describe the variable/field/class/interface,etc., For example, use names like firstName, grandTotal, CorporateCustomer or MyInterface. Although names like x1, y1, or fn are easy to type because they are short, they do not provide any indication of what they represent and it results in the code, that is difficult to understand, maintain, and enhance

• Follow the naming conventions provided by java coding standards. Standard Naming conventions:
  • Class name, Interface – First letter capital other small, changing keyword capital and other small. E.g. ClientInfo, Customer, MyClas
  • Variable name, package name and function name should start with initial small letter and should have a capital letter when a changing keyword comes. A package name does not contain any capital letter. E.g.
    • myNote, myVariable => variable name conventions
    • com.application.xyz => package name conventions
    • myFunction() => function name conventions
  • A constant should be defined in all capital letters. It can contain _(underscore) for changing name if needed. e.g., MYCONSTANT or MY_CONSTANT, INTENT_VIEW_NOTE

• Each and every class should have comments at the top which clearly states the purpose of the class creation (i.e., class summary), author information, created date and last modification date on the top, so that one can come to know that when the class implementation was last changed.
  E.g.,
  
  /*
  
  * Purpose – Class summary.
  
  * @author 
  
  * Created on August 05, 2011
  
  * Modified on August 08, 2011
  
  */

• Each and every function should be commented properly so that one can easily understand why the function was created. Further, a function comment should have each and every parameter explanation and return type explanation used in it.

• A function, variable and/or constant should be defined when it needs to be used during the code implementation. There should not be any unused function, variable or Constants in the code as it unnecessarily occupies memory at compile time. It means that the objects or variables should be created as and when needed and should be destroyed explicitly after it is no longer to be used.

• Each block of code must be surrounded by try-catch block so that the application does not crash whenever any unexpected exception event occurs. Further, it should also have the finally block of code if anything needs to be executed irrespective of the block of code executes successfully or not. For ex, It is better to release memory in the finally block which is occupied in the block.

• In Android, any in-built function writes “// TODO Auto-generated” block which should be replaced by code implementation. i.e., there should not be any such default commented block unless and until there is some coding pending from developer side knowingly. This means that the block is given for let the developers know that the implementation of the block is pending.

• There has to be separate packages for Activities, Constant Data and Class Data Objects for the application. Also, it is a good practice to divide Activity classes based on the module they fall in.

• Each and every resource used in the application must be defined in the “res” folder of the application. E.g.
  • If we need to use a string value in the application, it should be defined in the “strings.xml” file of the “res/values” folder.
  • If we need to use any color to be used in the application, it should be defined in the “colors.xml” file in the “res/values” folder.
  • If we need to use static array to be used in the application, it should be defined in the “arrays.xml” file in the “res/values” folder.
  • If we need to use static dimension to be used in the application, it should be defined in the “dimens.xml” file in the “res/values” folder.
  • If we need to use specific style for controls used in the application, it should be defined in “styles.xml” and the corresponding control theme should be defined in “themes.xml” file in the “res/values” folder

• Progress Dialog should be used wherever there is some heavy processing or network operation running as it shows that there is process running currently and it would keep the user informed about the same.

• Use multithreading and Handler wherever required to keep the device processor memory managed. There is a replacement of thread concept with AsyncTask when there is some UI rendering operation to be performed before and/or after the heavy processing and the heavy processing business logic should be implemented in overridden doInBackground() method of AsyncTask.

• If the code is too long to be implemented or it is to be used for multiple times at different conditions in the Activity or application, it should be taken into a function for easy interpretation and understanding and compile time memory utilization.

• Release the memory explicitly in the “onDestroy()” method of an Activity by making each global variable null.

• If there is a base class whose functions are to be referred from other classes, The base class should extend Activity and other classes should extend the extended base class to provide direct access to the base class functions in the other classes.

• Icons and images must be managed properly in the ‘drawable-xxhdpi’,’drawable-xhdpi’, ‘drawable-hdpi’ and ‘drawable-mdpi’ folders of the “res” folders to make application UI look & feel consistent in all the available devices with different screen resolutions. Refer below given link for more information on the same. 

          http://developer.android.com/guide/practices/screens_support.html 

• For More UI interface guidelines refer to: 

          http://developer.android.com/guide/practices/ui_guidelines/index.html

• Use custom styles and themes to make the UI consistent throughout the application if the UI is made to be custom as per the client requirements. Creating styles and themes for the controls like TextView, EditText, ListView removes the overhead of defining the properties for the controls explicitly while using in the xml design file. i.e., by using styles and themes, developer do not require providing attributes like padding, size and face and type parameters for the controls in the xml UI file.

• Format code and xml file structure using “ctrl + shift + F” everywhere so that the code remains consistent and easy to understand. Also correct indentation of the implemented code using “ctrl + I”.

• Never use explicit padding or margin for separating controls and never provide blank space for provide spacing to a control from other controls while creating xml UI.

• Use as less variables and objects as possible and keep the coding as simple as possible. Adhere proper coding conventions and guidelines and make coding easily understandable using proper comments wherever required.

• Provide line level comments, wherever complex logic implementation is required.

• Always refer below given link before initiating any application in order to target maximum user audience depending on the current usage share of Android OS version.