akkishinde · June 24, 2016 07:09
diff --git a/Android Best Practises b/Android Best Practises
 ```
 Coding Etiquette - pull requests without these will be rejected
 Indentation and spacing between code constructs must be consistent
 Use only space characters (no tab characters) for indentation
 Follow accepted naming conventions for your language/framework
 Follow accepted naming file and Directory structure for your language/framework
 Use namespaces
 No comments/Unused Code must ever be checked in
 All dev tasks like compile, run automated tests etc. must be automated as part of the build
 Runtime environment should be consistent with IDE environment - i.e there should be no difference in running a build or a spec from your IDE and from the command line
 Use .gitignore
 Ensure there is a up to date Readme.md that includes
 Problem Description
 Dev environment setup
 Build instructions
 Run instructions
 BDD/TDD is mandatory - code coverage should be > 95%
 BDD (this should show in clear pattern in the commit log - one spec, one code change per commit)
 Design Guidelines for object oriented codebases - pull requests must follow these, but implementation is open to discussion
 Have justifications for every design decision
 Use Simple English/Simple Diagram to Model designs
 Express Intent in every name (file, class, method, variable etc.)
 YAGNI - You aren’t going to need it
 DRY - Don’t repeat yourself
 KISS - Keep it simple and stupid
 Favour composition over inheritance
 Favour immutability over mutability
 Favour injection of dependencies
 No magic numbers/literals
 Exactly one authoritative source for any data
 SRP
 Tell, Don’t ask
 Job of the Class
 Law of Demeter
 OLID - https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
 Increase Cohesion - http://c2.com/cgi/wiki?CouplingAndCohesion
 Decrease Coupling
 Encapsulate what varies
 Defer decisions to the Last Responsible Moment (corollory of YAGNI)
 Design Guidelines for APIs
 Must be RESTful
 Must have comprehensive specs
 Must be versioned
 Must support json
 ```





 ```
 No Hungarian Notation (why?) http://jakewharton.com/just-say-no-to-hungarian-notation/
 Android Core Classes Conventions
 Activity classes end with `Activity` keyword
 Service classes ends with `Service` keyword
 Android specific variable and field names
 TextView = textName, textMessage, etc.
 EditText = inputName, inputEmail, etc.
 Button = buttonSend, buttonSave, etc.
 ViewPager = pagerDashboard etc.
 Android Resource Filenames
 Activity Names = <Project>DashboardActivity (e.g. FoodDashboardActivity) [1]
 Layout files = activity_<activity_name>.xml
 Item Layout files = item_<item_name>.xml
 Fragment = fragment_<fragment_name>.xml
 Image Files
 Icon Files = ic_<project>_
 Menu Icons = ic_menu_<project>_
 Status Bar Icons = ic_stat_<project>_
 Tab Icons = ic_tab_<project>_
 Android IDs
 Enclosing ViewGroup = container_
 ListView = list_
 RecyclerView = list_
 TextView = text_
 EditText = input_
 Button = button_
 Radio = radio_
 Checkbox = select_
 ImageView/ImageButton = img_
 ProgressBar = progress_ and wait_
 Intermediate Layouts = layout_
 ViewPager = pager_
 Intent Argument Key Constants
 Activity requiring arguments as part of Intent are required to declared the keys as constant. Each Activity will define an internal interface IntentKey which will declare these constants.
 DetailActivity.java
 public class DetailActivity extends AppCompatActivity {
    ...
    public interface IntentKey {
        public static final String ITEM_ID = "com.gojek.app.DetailActivity.ITEM_ID";
    }
 }
 
 References
 To avoid file name clashes for layout files. If GoFood and GoMart have MainActivity, both of their layout files will be called activity_main.xml, this will create conflict while building apk.

 ```
	```
	Coding Etiquette - pull requests without these will be rejected
	Indentation and spacing between code constructs must be consistent
	Use only space characters (no tab characters) for indentation
	Follow accepted naming conventions for your language/framework
	Follow accepted naming file and Directory structure for your language/framework
	Use namespaces
	No comments/Unused Code must ever be checked in
	All dev tasks like compile, run automated tests etc. must be automated as part of the build
	Runtime environment should be consistent with IDE environment - i.e there should be no difference in running a build or a spec from your IDE and from the command line
	Use .gitignore
	Ensure there is a up to date Readme.md that includes
	Problem Description
	Dev environment setup
	Build instructions
	Run instructions
	BDD/TDD is mandatory - code coverage should be > 95%
	BDD (this should show in clear pattern in the commit log - one spec, one code change per commit)
	Design Guidelines for object oriented codebases - pull requests must follow these, but implementation is open to discussion
	Have justifications for every design decision
	Use Simple English/Simple Diagram to Model designs
	Express Intent in every name (file, class, method, variable etc.)
	YAGNI - You aren’t going to need it
	DRY - Don’t repeat yourself
	KISS - Keep it simple and stupid
	Favour composition over inheritance
	Favour immutability over mutability
	Favour injection of dependencies
	No magic numbers/literals
	Exactly one authoritative source for any data
	SRP
	Tell, Don’t ask
	Job of the Class
	Law of Demeter
	OLID - https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
	Increase Cohesion - http://c2.com/cgi/wiki?CouplingAndCohesion
	Decrease Coupling
	Encapsulate what varies
	Defer decisions to the Last Responsible Moment (corollory of YAGNI)
	Design Guidelines for APIs
	Must be RESTful
	Must have comprehensive specs
	Must be versioned
	Must support json
	```





	```
	No Hungarian Notation (why?) http://jakewharton.com/just-say-no-to-hungarian-notation/
	Android Core Classes Conventions
	Activity classes end with `Activity` keyword
	Service classes ends with `Service` keyword
	Android specific variable and field names
	TextView = textName, textMessage, etc.
	EditText = inputName, inputEmail, etc.
	Button = buttonSend, buttonSave, etc.
	ViewPager = pagerDashboard etc.
	Android Resource Filenames
	Activity Names = <Project>DashboardActivity (e.g. FoodDashboardActivity) [1]
	Layout files = activity_<activity_name>.xml
	Item Layout files = item_<item_name>.xml
	Fragment = fragment_<fragment_name>.xml
	Image Files
	Icon Files = ic_<project>_
	Menu Icons = ic_menu_<project>_
	Status Bar Icons = ic_stat_<project>_
	Tab Icons = ic_tab_<project>_
	Android IDs
	Enclosing ViewGroup = container_
	ListView = list_
	RecyclerView = list_
	TextView = text_
	EditText = input_
	Button = button_
	Radio = radio_
	Checkbox = select_
	ImageView/ImageButton = img_
	ProgressBar = progress_ and wait_
	Intermediate Layouts = layout_
	ViewPager = pager_
	Intent Argument Key Constants
	Activity requiring arguments as part of Intent are required to declared the keys as constant. Each Activity will define an internal interface IntentKey which will declare these constants.
	DetailActivity.java
	public class DetailActivity extends AppCompatActivity {
	...
	public interface IntentKey {
	public static final String ITEM_ID = "com.gojek.app.DetailActivity.ITEM_ID";
	}
	}

	References
	To avoid file name clashes for layout files. If GoFood and GoMart have MainActivity, both of their layout files will be called activity_main.xml, this will create conflict while building apk.

	```
No results found