Android Project Refactoring Path: interface Chapter

In the previous article, "The Path of Android Project refactoring: Architecture", the project's architecture has been briefly explained, and the project is divided into four levels: Model layer, Interface layer, core layer, interface layer. Among them, the top interface, is the most frequent change of a level, but also the most complex and most prone to problems of a level, if the planning is not good, it is easy to do, and mess.

To plan the interface layer, you should at least follow a few basic principles:

1. To maintain the normative: define the development norms, including writing norms, naming norms, annotation specifications, and strict implementation according to the norms;
2. Maintain a single: layout only do the layout, content only do content, separate good, each method, each class, also do only one thing;
3. Stay concise: Keep the code and structure concise, each method, each class, each package, each file, do not plug too much code or resources, feel more should be split.

Normative

Everyone's coding habits and style are different, not to mention those who lack good coding habits of developers, even those who have developed good coding habits of people, many aspects will be different. such as indentation, some like 4 spaces, some like two spaces, such as variable names, and some like the beginning of M, such as Mvalue, some like directly named value. If you do not set a good specification, so that everyone according to their own habits and style to code, a long time certainly disorderly, especially when there is no good coding habits in the team of people, more prone to chaos. The so-called no rules inadequate surrounding area, if there is no standard, long will be chaotic. Define the specification to unify the style, to improve the readability of the code, but also improve the maintenance, but also reduce the opportunity to introduce bugs.

Development specifications do not have a unified standard, here, I just based on my experience on some points to provide a little advice, for reference only.

• Indent in

  A lot of people are used to tab indentation, whether it is the specification of 4 or 2 spaces, the Uniform set tab indentation size is good, so do not let everyone go to the space.

• Named

  A good name, a glance can see from the name of what it is, what to do, what type and so on. To give an example of ID naming, see some teams like to have some control abbreviations, such as textview abbreviation for tv,listview abbreviation for LV, this abbreviation is very concise, but can not see what it is, for unfamiliar people, who know what TV and LV is Ah, It's better to use text and list more clearly. I like the ID named structure: Control _ scope _ function, for example: Edit_login_password, this is a login page password input box.

• Unit

  Text size units should be unified with the SP, other elements with DP. Because these two units are device resolution independent, it is possible to solve the problem of displaying different effects on different resolution devices. In addition, in the SDK, the text size system by default is the SP unit, but the other elements units default is not DP, but PX, but also does not provide DP settings interface, so, it is necessary to write two DP and PX conversion method.

The most important thing is not how to define the norm, but the strict implementation of the norm. If the specification is well defined, but does not comply with it, then the specification is tantamount to a dummy, therefore, once the specification is set, it must be strictly enforced.

Single-Sex

As we all know, one of the basic principles of object-oriented design is the principle of single responsibility, which stipulates that a class should have only one reason for change. What is said here is that the uniqueness, not only the prescribed class, but also the method, package, even to the maximum level of layered architecture. Maintaining singleness is a key criterion for reducing coupling, and its purpose is to decouple the various aspects. The hierarchy on the architecture is the decoupling of the maximum level, and the single method is the least level decoupling.

• The single interface

  The interface of a single, first is the interface of the layout and interface of the data should be separated. This, Android has been decoupled with layout and activity, and we just need to make sure that layout files are lined up and the data is displayed in the activity. In addition, the interface data acquisition and display should also be separated. Many development teams are accustomed to the acquisition and presentation of data in activity or fragment, and there are people in the architecture that reflect the situation, requesting interfaces, fetching data, checking data, displaying Data update UI, all on the interface. In this case, when the data acquisition changes, such as to add the cache, the interface needs to be changed, when the data display also needs to be modified, such as a control to show other data, the interface also needs to be changed, that is, the interface has two changes in the cause, which violates the principle of single responsibility.
  The interface of a single, is to keep each dimension of the interface is well separated, from the layout of the interface, to data acquisition, data inspection, data display.

• Packages and classes of a single

  Before you define a package, you need to think about what its responsibilities are, define it clearly, and make sure it has only one responsibility. For example, com.keegan.activity, is the activity class package, there will be no other components, Com.keegan.adapter, is to store a variety of adapter packages; Com.keegan.util is the toolkit. Similarly, the definition of a class also needs to clarify its single function. Some people are used to writing adapter in the activity, because it feels that this adapter is only used in this activity, there is no need to separate it. I used to do the same thing, after doing this for a while, feel really bad, duplicate code can not be reused, the interface of a small demand adjustment, a lot of code needs to follow the adjustment. Later, a refactoring, all adapter independent, and abstracted out a adapter base class, since then, when the need to add adapter, the amount of code written greatly reduced, when the interface needs to adjust, the changes in the place is greatly reduced. So, don't let a class do too many things, separate the elements, and do only one simple thing for each element.

• Method of a single

  The single method, manifested as a method is the encapsulation of a behavior. However, one behavior can be broken into multiple steps, and each step is actually a finer behavior and can be encapsulated into a new method. Therefore, the method nesting method is a normal. The key to preserving the uniqueness of the method, then, is not how to define the behavior of the method, but how the behavior is split into finer behavior. For example, usually in the activity of the OnCreate method, the initialization of the data, the breakdown is divided into: the initialization of the control, the initialization of the logical variables, data loading and display. Data loading and presentation can be subdivided: loading data from the cache, loading data from the network, and presenting data. Each fine-grained behavior should be encapsulated as a separate method, so that it truly conforms to the uniqueness of the method.

• A single resource file

  Android provides a variety of resource files, Strings.xml is used to store strings, Arrays.xml is used to store string arrays, Colors.xml is used to store color values, Dimens.xml is used to store dimension values, and so on. A single resource file means that all relevant resource information is defined in the resource file and referenced in the code or layout file, rather than directly defined in the code or layout file. Many developers, in order to facilitate the diagram, the application interface appears in the string is often in the code or layout file directly defined, the size of the value is also, so the result is that when some strings need to be modified, such as to support internationalization, or some of the size values need to be modified, often many places have to be modified. Therefore, it is necessary to standardize, the application interface of the string unity in the Strings.xml definition, the color values are unified in the definition of colors.xml, dimension values are defined in Dimens.xml, the code or layout needs to refer to the corresponding fields of the resource file.

To maintain the uniqueness, it must be accompanied by emphasis on construction. There is always a change in demand, the code will always be expanded, and the expansion of the original single can be broken, so the need to refactor, again to maintain the uniqueness. Continue to expand, continue to reconstruct, so as to keep the good singleness.

Simplicity of

Code is most afraid of bloated, bloated code readability is poor, maintenance trouble, not to mention the expansion. No one would like to look at bloated code, to maintain more pain. I see bloated code, and I can't wait to refactor. Keeping the code simple makes people feel comfortable, at a glance, and easy to maintain and expand. The simple code, without even needing to write a comment, can only be seen from the code to see what it does. Brevity is not just about code, but the naming and organization of classes, packages, resource files, and so on, also need to be concise.

How to keep it simple? There is no standard answer to this question, but there is a simple standard for judging whether it is straightforward to read the code to understand the intent of the code, and if the intent is not obvious, it is not concise enough. Classes, packages, resource files, and so on, are the same criteria for judging. Here are some of the ways I find it useful to keep things simple.

• The organization of the package

  Subcontracting by component type instead of by Business module. The business may change, but the component type is fundamentally unchanged. In addition, the newly added developers are unfamiliar with the business, but the components are very clear, understand quickly, and start quickly.

• Naming of classes and interfaces

  The name of the component class adds the suffix of the component, for example: Activity class name add activity suffix, fragment class command add fragment suffix, adapter add adapter suffix, and so on. The entity class can add the suffix name of the Bo, the tool class adds the Util suffix, and the implementation class of the interface adds the Impl suffix. The name of the interface is the same, for example, in my project, the interface suffix of the interfaces layer with the API, the core layer of the interface suffix with action.

• Classification of resource files

  Strings.xml files are used to store all the strings in the app, including page headings, button text, label text, hint text, etc., and should be sorted and stored uniformly. Here is my recommended classification method, if a classification of the number of strings too much, you can also split out into a separate file, such as the page title, can be split into the Strings_title.xml file, other resource files can be processed in a similar way:

  • Page title, named Format: title_{page}
  • button text, named Format: btn_{button Event}
  • Label text, named format: label_{label text}
  • tab text, named Format: tab_{tab text}
  • message box text, named format: toast_{message}
  • edit box prompt text, named format: hint_{prompt Message}
  • Picture description text, named format: desc_{picture Text}
  • dialog box text, named format: dialog_{text}

Summarize

The three basic principles, which are normative, unitary and concise, complement each other. Singleness and conciseness are standard definitions, and they cannot be separated from these two principles to define a specification. And the strict implementation of the norms, it guarantees the effectiveness of the latter two principles.

All-in-one programmer Exchange QQ Group 290551701, gather a lot of Internet elite, technical director, architect, Project Manager! Open source technology research, Welcome to the industry, Daniel and beginners are interested in engaging in IT industry personnel to enter!

Android Project Refactoring Path: interface Chapter