Company Android project specifications and Android project specifications

Company Android project specifications and Android project specifications

1: project code directory structure:

Here is the package structure of the entire project. The reason for confidentiality is not covered here.

 

2: naming rules:

2.1 naming rules for java code files:

A: Try to use English names. Words are not abbreviated. Do not splice them with underscores (_) and uppercase letters (_) are used for splicing.

B: Generally, the name of a java code file is suffixed with an inherited class name. For example, a file inherited from an Activity can be written as MainActivity. java. The inherited Adapter can be written as UserListAdapter. java.

C: some pure class names must be prefixed with the upper class and can be customized, such as InfoRank. java.

D: The first letter and multiple words. The first letter of each word must be uppercase. Do not use underscores to connect. For example, UserInfo. java. Do not write user_info.java.

E: The method names in the java class start with lowercase letters. If multiple words start with the first letter of the second word, for example, getUserList ().

F: for java class member variables, English words and lowercase letters must be used. Multiple words are separated from the second word and the first letter in uppercase. Do not splice them with underscores. For example, userMoney.

G: constants in the java class can only contain letters and _. All letters are uppercase and separated. For example, MAX_AGE.

 

2.2 layout File naming rules:

A: The name must be in lower case. The words are not abbreviated. Multiple words are separated by hyphens, for example, user_info_list.xml.

User_info_list_item.xml (a sub-layout file is used when listview is used ).

B: The layout file name can be referred to the code file name. Generally, a page contains an xml file and a java code. The corresponding java and xml names can be the same. If BetRecord. java corresponds to bet_record.xml

C: The names of controls in the layout file must start with the file name. For example, in bet_record.xml, Return key: @ + id/bet_record_back, list @ + id/bet_record_listview, OK key

@ + Id/bet_record_submit. Other controls must be named based on actual conditions. For example:

Bet_record_no, bet_record_money, make sure that the name of each control is unique throughout the project.

 

2.3 naming rules for image resource files:

A: The name is in lower case. The words are not abbreviated. Multiple words are separated by underscores.

B: The image name must be unique. The entire set of images are directly stored in the drawable-hdpi folder for classification.

C: The name of a button image is prefixed with "button", for example, "button_ OK" and "button_cancel.

D: The name of the background image is prefixed with bg. For example, bg_top and bg_listview.

E: The display class image is named with the view prefix.

F: display pictures are named with dis prefix, for example, slide playback.

G: Name tmp as the prefix.

H: names on other charts are prefixed with other.

 

3. Code specifications

A: All codes should be aligned and arranged neatly. If there is only one line of comment, try to use //; If there are multiple lines, use /**/. There must be blank lines between codes, but do not empty a large part. You should delete unnecessary code and annotations. If it is commented but may need to be used, it cannot be deleted. For the variables defined in each class, one line is required, and the specific meanings of the variables should be commented after the fields.

B: The parameters transmitted between the Activity and the Activity are minimized. Make each class relatively independent. In addition, the callback and asynchronous programs or others in each Activity can be independent as much as possible. It can be written as a class or a common method. This is also more in line with the java Object-oriented Thinking, making the code more concise and clear. Easy to maintain. Before each class, you need to comment out what functions and interfaces, and you need to receive those parameters (including names and meanings ).

C: If any method has been used in several classes (more than two times), it should be extracted and written as a common method for calling, instead of copying a copy in each class. Easy to maintain and reduce code duplication. For example, the countdown calculation method.

D: for values that need to be frequently obtained, you should obtain them once at the beginning and define a static variable. Instead of reading the method each time, you can call this variable, for example, you can obtain the mobile phone screen once at the beginning and save it to the static variable instead of getting the mobile phone screen every time.

E: For controls with the same style, the style should be extracted and uniformly defined into the style. in xml, for example, the Return key, after the purchase of the color button, and then define such a control, only one id is defined, you can call the style.

F: Do not reuse the handler of the parent class. The handler of the corresponding class should not be used by its subclass. Otherwise, the message. what conflict will occur.

G: Initialize all controls in an initUI () method in the activity, and set all monitoring events and views in the initListener () method. onClickListener processes all the listeners, But you can write a method for the specific service logic to call it in the listener.

H: verify the data. For example, if the numeric type is converted to the numeric type, the default value must be set if the conversion fails. Whether the server response data is valid. For example, if the returned code for a network request is "0000 ". All verifications are written as a validatae () method. Return a Boolean value to determine whether the verification is successful. Do not write it together with the business logic.

I: some buttons should be avoided. For example, if you click a network request, it will be disabled. Release after asynchronous processing.

J: sp is used for the font, dip is used for the height, width, indentation, and so on, and the screen must be adaptive for all layout, you can select different screens such as 3.2, 4.0, and 5.4 in Eclipse to check whether the layout is configured and deformed. Exception in sorting.

K: network loading, file processing, database processing, and other issues should not be put on the master site, but should be put on asynchronous operations.

L: Do not use asynchronous loading or hander combination. Generally, use asynchronous loading. Hander is used with threads. In general, the use of Asynchronization is resource-consuming, but the efficiency is high. Handler is relatively less resource-consuming, but less efficient. If both are used at the same time, resource-consuming and inefficient, we recommend that you do not use them together. Select either of them.

M: You must determine the usage of each object before using it, to avoid errors caused by data changes or no data. The method can refer to the following code:

1) Function. strNotNull (str) can be called for strings );

2) for the object if (obj! = Null)

3) for the set Function. listNotNull (list); Function. mapNotNull (map );

4) for array Function. arrayNotNull (array );

N: All static (static) immutable (final) constants are written into ConstantUtil. java.

All static and variable. All objects to be shared are written to VariateUtil. java. For example, the screen size;

All common functions and methods are written to FunctionUtil. java. Others can be expanded.

O: for variables defined as local variables, do not define them as global variables, which facilitates memory recovery. Do not use String for String concatenation, but use StringBuffer. For loops, do not define variables in them. This can also reduce the memory allocation. For example

Person person = null; // defined outside the loop

Int size = list. size (); // avoid repeated calls

For (int I; I <size; I ++ ){

Person = list. get (I );

// Use the person object again

}

P: for a List, if there are few fields used, you can define multiple lists <String>. However, if there are many fields used, you should define these fields as a Bean object, store the data to List <Bean>.

Q: Be careful when using static variables to share interfaces. Do not define static variables in each separate class.

 

...... To be supplemented .............