(Alpha) Let ' s technical Documentation (technical specification)

Technical Spec Sheet

Abstract

First of all, the concept of "abstraction" is an abstraction of the abstract principle. Abstract embodies a kind of generalization ability. Many of the objects we encounter in our lives have some similarities and even the same nature in some respects, and they recognize things by these traits rather than by the things themselves. In an article cited to the example is quite intuitive: "When you teach a child to know the cat, you will be a specific cat as an example to tell the child this is just a cat, so many times, when there are other different cats when the child can recognize that it is a cat." Each cat is different, but they share a common trait, which is a combination of a cat's definition and the abstraction of the concept of a cat. Thus, it can be seen that abstraction is a generalization of the nature of things. ”

For our app, during the design process, we use abstract ideas in the process of defining various entities as a core function of "strangers co-sponsoring and participating in activities". The two concepts we need to focus on are users and activities. The concept of user is relatively simple, we only need to obtain the user's identity information, to distinguish with other users, so that the user can be interactive recognition.

And the concept of activity is relatively complex, in the real world, there are a variety of activities: sightseeing, poetry fu, farming weaving, water-pouring garden. So here's the question: How do we generalize the concept of activity from this complex, endless form of activity, and choose the attributes that describe the activity that distinguishes it?

In view of this problem, our idea is: Starting from the user, from the perspective of the participants, put yourself in the context of participating in an activity need to understand and want to understand the information. The question is simple: what is the impulse to participate in an activity as a user?

In my opinion, the first is the form and content of this activity, which is the soul of an activity, if it meets the interests of more users, there will naturally be a lot of users want to join. Again, this is the time and place of the event: if the time conflict or location is not convenient, even if you want to participate, I am afraid it can only be deterred. Again, the other participants in the event, as a small partner to play together, especially in the case of people do not know each other, this can not be overlooked. Even if we can only learn some basic information of other users, I believe we should also be able to rely on this, the participation experience of the event has a rough estimate (it is plainly that the number of girls together).

After this analysis: our concept of activity abstracts the following attributes: ID (Master code), name, category, time, place, description of the activity that the initiator filled out when the event was initiated. For other users of the event, the database can be retrieved and displayed on the active interface.

cohesion/coupling/modularity

In the engineering implementation, the first thing we do is to implement the modular (modularization) processing of the code, and then design the details according to each module defined. In the implementation process, the cohesion (Cohesion) and coupling (coupling) Two criteria can be used to judge the degree of dependence between the various entities in the project. Among them, the cohesion is used to measure the degree of interdependence among the components within a single module, and coupling is used to measure the degree of dependency between different modules.

Among them, the cohesion according to the degree from low to high can be divided into the following several:

1. Gathered by chance. If there is no relationship between the components of a module, it is called accidental cohesion.
2. Logical cohesion. Several logically related functions are placed in the same module, which is called logical cohesion. such as a module to read the input of a variety of different types of peripherals. Although the logical cohesion is reasonable by chance, the components of the logically cohesive modules are not related to each other, even if the modification of local functions can sometimes affect the whole world, so the modification of these modules is also more difficult.
3. Time to gather. If a module completes a function that must be performed at the same time (such as system initialization), but these functions are only associated with time factors, they are called time-gathering.
4. In-process cohesion. If the processing components within a module are relevant and these processes must be performed in a specific order, it is called process cohesion.
5. Communication within the cluster. If all components of a module operate on the same dataset or generate the same data set, it is called communication cohesion.
6. In order to gather. If each component of a module is closely related to the same function, and the output of one component is an input to another component, it is called sequential cohesion.
7. function cohesion. All components of a module are required to complete a single function, called function cohesion.

During the design process, we refer to the Codecomplete of Steve Mccoonell, which, according to the definition of Section 5.2 in the book, can be divided according to the degree of coupling from low to high in the following ways:

1. Simple Data coupling
2. Simple Object coupling
3. Object parameter coupling
4. The semantic coupling

According to the idea of modularization, a system with high cohesion and low coupling degree is more ideal.

In this project, the macro on the two large modules are: Server-side module, the client module

Server-side module is divided into: Database module, File Service module, SMS Service module, message push module

Client module is divided into: User entity, activity entity, login Registration module, homepage module, launch activity module, Map Service module, Personal Center module.

The diagram is as follows:

The arrows in the diagram represent dependencies between the modules, and the module that the arrows point to depends on the module that emits the arrows.

Based on the above modules, the next step is to analyze the cohesion and coupling of each module:

1. Internal Poly
   • The design of the major modules to the majority of functional cohesion as the standard, such as the server-side database module responsible for user, activity information data storage and deletion and retrieval; The File Service module is responsible for the user image and other information access; The message push module is responsible for the message push.
   • For the client, each module can be regarded as a different function of the page, each page has different functions, so the cohesion of each module is a function of cohesion as standard. Two of these special entities, users, and activities are also the management functions of user classes and activity classes by assembling different properties of users and activities together.
   • According to the above analysis, because of the major functions of the positioning division are clear and obvious, so the cohesion of each module is strong.
2. Coupling
   • In the present design (regardless of the design of Android itself), there is only simple data coupling between the modules, so loosely coupled (Loose coupling) is implemented in the design. For example, between the server and the client, through protocol and data communication interdependence, while the map service and the initiating activity two modules, the map service is responsible for transmitting the specific address on the map to the initiating activity module.
   • Most of the data passing through the activity switching mechanism in Android, using the Putextra function to achieve the different modules (pages) between the information transfer, rather than the direct call method between classes passed. The system stability and security are further enhanced by the loose coupling between different modules by using the Android mechanism.

information hiding and encapsulation

The content is covered in the Code Complete book.

Excerpts from section 5.3 of the book are reproduced here: "Information hiding is part of the foundation of the both structured design and object-oriented design. In structured design, the notion of ' black boxes ' comes from information hiding. In object-oriented design, it gives rise to the concepts of encapsulation and modularity,and it's associated with the con Cept of abstraction. "

Information hiding and encapsulation are the basis of structured programming and object-oriented thinking. It produces the idea of black-box testing in structured programming, promotes the concept of encapsulation and modularity in object-oriented processes, and is related to abstract programming thinking.

In order to demonstrate this, the author uses the "Iceberg theory" as a description. Our code is consistent with the iceberg, and we need to hide most of what we don't care about, leaving the visible part to the people who really need it.

There are two factors to be aware of when adhering to this principle:

1. Hidden complexity: Features with high complexity need to be hidden in a separate package, one on the one hand to prevent the use of repeated writing, on the one hand to prevent external calls to increase program uncertainty.
2. Hide the source of change: Some of the global changes in the program often occur in the source needs to be hidden, such as counters, can be used in function encapsulation to accumulate, avoid directly to the count value operation. This can enhance code security and extensibility.

As for encapsulation, the interface encapsulated by a class is a high abstraction of the class responsibilities, roles, and an abstraction of the interaction, behavior, and functions within the class itself, between classes and classes, and to ensure that the dependencies between these abstractions are minimal.

In the project, the design reference to the above code Complete book requirements, our design is better to ensure the hidden and encapsulation of the principle requirements.

From the macroscopic point of view, there are mainly:

1. A data object is the data structure of each table in the database, which is designed for information hiding and encapsulation.
2. For each relatively independent and complete function, a separate activity is designed.

For the first type, our project, User.java, has completed the hiding of all data items in the user table, its access control keywords are private, and the interface that modifies its data items is encapsulated, and all operations related to the user data are done through this class. Enhanced security and extensibility of the code.

For the second type, a total of 11 activities are designed in the project, and each activity is responsible for a separate function. For example, initiateeventactivity is responsible for initiating the activity function, which encapsulates the method of perfecting the activity information, the function of interacting with the server database, and the operation of switching to other activities, that is, all the functions can be processed at the current activity. And these non-public processing functions are not exposed to the outside world (class outside). When the activity needs to switch between, the data passing through the activity switching mechanism in Android, using the Putextra function to implement different modules (pages) between the information transfer, rather than the direct call method between the classes passed. The system stability and security are further enhanced by the loose coupling between different modules by using the Android mechanism.

separation of interfaces and implementations

In the process of engineering design, the separation of interface and realization is mainly embodied in three parts: personnel allocation , development Progress and front-back coupling .

In the personnel allocation aspect, the developer mainly divides into the front-end UI and the backstage implementation two parts, the division of labor is more clear. The front-end developer is responsible for UI design, interface XML file writing, and the writing of a few control event codes, and developers behind the scenes implement event implementations based on the various control modules implemented at the front end.

In the development progress , always requires that the UI progress requires at least one step ahead of the background, that is, the background to start the implementation of feature one at least in the background of the development of functional two. This ensures that the background work is not constrained by the front end, and the backend has the need to change the front end to have the time remaining to modify.

In the front and back of the coupling, the first by the entire developer to determine the function of each page, determine the basic control requirements, and then by the front-end personnel on the layout of the various pages to complete the UI file. Thereafter, the background staff adds events and contacts for each control, and proposes changes to the front-end staff to further optimize the interface display and user experience.

Error Handling

There are three main ways we handle error handling in the project:

1. Direct return, upper processing
2. Take exception mechanism, throw exception
3. Rewrite the OnFailure () method in the Listener or onerror ()

In the process of actual coding, we tend to prefer the latter two methods, because the first way is to define a lengthy and complex list of error codes, and to have harsh requirements for the return type of the method, or to require the writer of the upper code to be aware of the entire process of the called function and the semantics of the return value. This is not conducive to our rapid team development work.

In the second approach, we define MyException, which contains the following definitions of the partial exception types:

Class Replicatephoneexception extends Exception {}class passwordnotequalexception extends Exception {}class Ver Ifycodefailexception extends Exception {}class nullitemexception extends Exception {public     Nullitemexception (String str) {        Super(str);}}     

The exception mechanism is used primarily for processing functions that do not exist with the listener mechanism or for errors that occur in functions that are called inside the listener. The advantage of the exception is that, as shown above, the exception type name can be quickly "words too literally", that is, as long as the members of the same team can see the exception thrown by this function to quickly understand what the error situation, they can handle the corresponding. For example, in a project, the listener of the button's onclick () event does not have the OnFailure () method, so our design is to call a function in it as follows:

public void OnClick (View v) {    try {        registerclick ();    } catch (Nullitemexception e) {        / /Todo    } catch (Passwordnotequalexception e) {        //Todo } catch (Verifycodefailexception e) {//TODO }}       

By such an exception handling mechanism, the corresponding error condition can be effectively processed under the appropriate situation.

The third method is more convenient and convenient, such as this code:

Query.findobjects (This, new findlistener<useractivity> () {...})

This is a scenario where a query is requested from the server database, and you can see that a new findlistener<t> () listener is created in the code and requires overriding the following two functions.

@Overridepublic void onsuccess () {    //TODO auto-generated method stub} @Overridepublic void onError () { c5/>//TODO auto-generated method stub}   

It is then convenient to handle possible error situations in the OnError () function.

Assumptions

Our project operating environment is set up with Android 4.4.2 and above platform.

If you're running on an Android system that's lower than 4.4.2, you'll be prompted with the error message "The current Android version is too low to install the app."

The main large modules are local modules and server-side modules. The local module is only required for the version of the system, so there is no other impact, but the server-side module code is based on an open source framework, security is fairly guaranteed, all errors are due to the local upload request or data does not conform to the appropriate format, this problem we all in the coding and debugging phase solved. After the above analysis, there is only one possible problem between these two modules is that the network communication failure, so we have the corresponding listener in the communication failure situation of the processing function. As a result, the program can run under any circumstances and in accordance with the operating environment and module logic that is assumed at development time.

There are two scenarios for the input and output assumptions. One is to judge the validity of the parameters before calling the module, and the other is to evaluate the parameters effectively after entering the module. In this project, our team agreed that all modules should be effective in determining the parameters passed in, and if invalid, throw an exception or display an error message. The reason for this agreement is that the developer of this module is more aware of the requirements of the parameters required by this module, so it is more effective and efficient for the developer of this module to judge and analyze.

flexibility to respond to change

1) Flexibility of the entity

The two major entities, users and activities involved in our project. In the design implementation, we correspond each of the two entities in the database table corresponding to the member variable one by one in the class, so that when you need to modify the entity properties later, simply add the corresponding columns to the database table and add the corresponding members in the code and the corresponding Get/set method.

2) Flexibility of interface display

Because there are many different types of pages in the app design, such as: Search for a message we need to return both the user set and the activity set, and click on a user who has already participated in an active interface to show a list of all the participating users, and to view the list of activities initiated/participated by the user. The home page can display a list of recommended activities and so on. In order to make the display of the page more flexible and to improve its generics for later function expansion, we implemented a generic adapter for the display list ListView in the implementation process, which adjusts the layout of the ListView for the different types of information that need to be presented. In the latter case, if you need to increase the type of display, you only need to design the layout mode of the type information, and provide this mode to adapter. All modifications require only one line of code to complete, greatly enhancing the flexibility of the display.

ability to handle large amounts of data

Our background database operation for this app uses a completely free cloud database provided by a Web site, and a visual cloud NoSQL data sheet design that supports up to 10 data types. Simple, free to complete the database configuration according to business requirements, easy to achieve cloud-to-end data interaction.

Referring to the operation of the data, it is natural to associate the data with the deletion and modification.

In the process of increasing the amount of data, the complexity of these operations will gradually increase, which is unavoidable. What we can do is to combine some of the features of the platform itself, so that the efficiency of the program is maintained on a relatively stable basis.

First, in response to the increase in data, we take the method of mobile phone verification, which in itself eliminates the malicious registration cache policy, and in the registration process need to send a verification code, for the same mobile phone number, only five verification code per day, which makes the malicious authentication is no longer possible.

In addition, the impact of data is more serious is the query function, if the data is large, the process of query will certainly take more time, which will make the user experience worse, for this point, we take the method is to add the cache function, when the user's device is offline, you can get data from the cache to display. Or when the application interface has just started, and the data obtained from the network has not yet obtained the result, the cache data is used to display it first. This allows the user to avoid tedious waits after a button is pressed.

And we have designed several different caching strategies to suit the needs of different scenarios. A cached query typically caches the results of a query on disk.

Ignore_cache : Only gets data from the network and does not cache the data locally, which is the default caching policy.

cache_only : Only read data from the cache, if the cache does not have data that results in a bmobexception, you can ignore this bmobexception.

network_only : Data is only fetched from the network, and data is cached locally.

Network_else_cache : The data is read from the network first, if not, and then fetched from the cache. Cache_else_network: The data is read from the cache first, if not, then from the network.

ache_then_network: The data is fetched from the cache first, regardless of how the result will be retrieved from the network again. That means 2 calls are generated.

It is important to note that cached data is cached to the local cache only if the condition of the cached query is identical.

This allows users to obtain the accuracy of the data are guaranteed.

In the process of analyzing this part of the problem, our main strategy is to fully combine the functional characteristics of the platform, as a means, from the user's needs and experience to start the process of optimization, so that the program can be in the case of large amounts of data still without losing efficiency.

(Alpha) Let ' s technical Documentation (technical specification)