Android Development Experience Record

Source: Internet
Author: User

First, code specification

The main purpose of a specification is to keep the code written by different developers consistent and easy for others to see. In addition, for individuals, can also play a role to make themselves look comfortable.

1. Basic

* Using UTF-8 encoding

* Indent with Tab

* Attitude to old code: Many old code style is messy, we do not need to change all the time, only need to "by hand" to change, for example, you changed an old function, then by the way the code in the style are unified a good, I look comfortable

* Write curly braces in Java standard, that is, curly braces follow the rightmost side of the code instead of another line:

void FuncName () {     if(a = = 0)           {//...      }}

2. Naming

* All Java code uses the Hump naming method: Isfavorite, Activitymain

* All XML files, resource files are underlined, lowercase letters: activity_main.xml, ic_launcher.png

* All class names capitalized: Baseapi

* All methods First Letter lowercase: requestlist ()

* All variables are first letter lowercase, and member variables are recommended to start with small m: Mcontext

* All constants are all uppercase, use underline connection: Debug_print

3. Notes

* The role of annotations is to make it easy for others to understand our code, so annotations only need to appear where necessary, and more often, we should use a good name (function, class, variable, constant) to reduce the comment

* Note: The description of class, the description of the function provided by the class, the variables and constants provided by the class, and the/** notation should be used, so that the IDE can directly put the mouse up to see things

* In the Critical program section, you should add comments, such as a very awkward logic, should explain what it is to do, the comments should mainly explain the purpose rather than the process

* The comment of the function should indicate the function of each parameter, and the return value

* To develop the habit of doing good deeds, in the class you create, you should leave your name in the class description. If you add a function to someone else's class, you should leave your name in the function. Variables, constants are similar

4. About third-party libraries

* Attitude towards third-party libraries: third-party libraries can greatly reduce our workload, but improper use can also get us into a quagmire, generally following some simple rules to help you choose a third-party library:

* * Complexity: If a feature needs to consider a large number of exception handling and details, and is very common, then you should consider using a third-party library, the typical example is: Network access (volley), picture loading (Universalimageloader), JSON parsing (Fastjson, Gson)

* * Maturity: In general, we should try to choose a mature third-party library, judging by the criteria include: publishing place (for example, GitHub), whether continuous maintenance (see submit record), view rankings by search, view rankings through GitHub search

* * Revision Size: Some third-party libraries we don't use them directly, we may need to make some changes, and we need to be aware of them. If you need to modify the parts (or parts of the future that might need to be modified), then we probably need to think about writing for ourselves, because sometimes it takes more time to modify than to write, and in fact, countless lessons have been shown. Also, try not to modify third-party libraries, as many third-party libraries themselves are upgraded

* In addition, there are two ways of introducing third-party code:

* * Refer to third-party libraries as external libraries: that is, adding dependencies in Project attributes, the benefit of which is to maintain the independence of the project, the disadvantage is that there will be a lot of work in the environment, and if the dependency of the project, need clean to take effect.

* * Put the third-party library code directly into the main project: The advantage is that there will not be many external projects, but the disadvantage is that the resource files (res, etc.) are also added, if one day you want to delete the library, then the egg hurts.

In fact, the balance of the method is very simple, if the third-party library resource files are particularly many, then I suggest using external libraries, if the third-party library code files are relatively small, you can consider directly into the main project.

Second, multi-person collaboration

Many people need to pay attention to the problem is how to rational division of labor, while ensuring efficiency, reduce communication costs, have some basic experience:

* Partition module: Generally according to the interface partition is more reasonable, for the common data model and network access function, can be unified by a person to write, can also be responsible for an interface of the person responsible for the corresponding network functions;

* Do not repeat the wheel: Some interface controls are generic, do not repeat the write, some network access functions are generic, use a copy. To do this, the most important thing is to actively communicate, in the realization that others may need their own code to communicate as early as possible;

* Prevent SVN conflicts: Two people write the same file (especially the network access Class), prone to conflict, some tips:

* Put a file partition block that can be written by more than one person at a time, separated by multiple carriage returns, and then write the area with the comment.

* Try a file with only one person in charge ...

* Develop a good habit of constantly updating your code ...

Third, version released

In the release version, you need to follow a certain step, but also to note some of the SVN operation methods:

1, first, complete the development of each function, carry out self-test;

2, self-Test no problem, use Dealmoon under the Dealmoon.key to sign, the password in the code directory of the description document. Test the APK to the tester;

3, the test personnel to detect problems, the owner of each module to modify;

4, after several rounds of correction, basically no big bug, then you can release, the final version of the APK to the product manager to publish;

5, after determining the release version, use SVN, create a publishing branch, in the/branches/release_vx.x directory, where vx.x is the version number, used to back up the published version;

If the release version is slow to determine, and the mainline version does the next, you can create a publishing branch, and then, if there is a bug, publish the branch and modify it, then merge the changes to the main line. Note: Be sure to ensure that the merge is unidirectional, that is, merging only from the publishing branch to the trunk, not from the trunk merge to the release, then it will be a mess;

Android Development Experience Record

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.