WO2008025198A1

WO2008025198A1 - Method, system, and apparatus for communication between a terminal and a server

Info

Publication number: WO2008025198A1
Application number: PCT/CN2007/001120
Authority: WO
Inventors: Ting Wang
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-08-28
Filing date: 2007-04-06
Publication date: 2008-03-06
Also published as: CN100442897C; CN1937811A

Abstract

A method for communication between a terminal and a server in a single thread platform system includes: the terminal sends a request message to the server and locks the user interface; upon receiving the returned response message for said request message from the server, the terminal performs the process according to the preset callback method corresponding to said request message and unlocks the user interface. There are still an apparatus for communication between a terminal and a server by a single thread platform, a terminal, and a system for communication betwwen a terminal and a server. The asynchronous communication on a single threadplatform can be converted into a synchronous communication by the present invention.

Description

Method, system and device for communication between terminal and server

This application claims priority to Chinese Patent Application No. 200610111967.2, entitled "Methods, Systems and Apparatus for Terminal and Server Communication", filed on August 28, 2006, the entire contents of In this application.

Technical field

The present invention belongs to the field of communication technologies, and in particular, to a method, system and apparatus for communication between a terminal and a server.

Background technique

Support only single-threaded service platform, generally communication between applications and underlying application platform is asynchronous, Brew (Binary Runtime Environment for Wireless , the wireless binary runtime environment Xi ¹ J) is one such platform internet. However, in the process of implementing the present invention, the inventors have found that with the development of technology, there is a need to convert asynchronous communication into synchronous communication. The following is a detailed description of the Brew platform.

The Brew platform is the basic platform for developing and running value-added services. Inside the wireless terminal, the communication between the Brew platform-based application (Applet) and other applications or the underlying platform is asynchronous, that is, after the sender sends the data, the sender does not need to wait for the response to be sent back, and then sends the next packet. This method is suitable for stand-alone applications that do not require a server. However, the future communication network will be centered on data services and generally use Internet IP (Internet Protocol). The entire network will use the IP protocol as a unified communication protocol. The so-called Everything Over IP (all based on Internet Protocol), the network only plays the role of information transmission, all value-added services are completed by the terminal outside the network, therefore, the terminal application will become more and more complex, requiring the support of the business server. For example, an application (application server) is required for various applications in the IMS (IP Multi-media Sub-system) network. In order to adapt to this technology trend, the Brew wireless terminal also needs to support C/. S (Client/Server, Client/Server), B/S (Browser/Server, Browser/Server) application.

However, for complex C/S and B/S applications, there is often a limitation of the user operation sequence, that is, an operation server cannot perform the next operation before returning the result. Therefore, it is necessary to apply the terminal application based on the Brew platform to the server. Communication is converted to a synchronous mode. A simple example: Terminal application A needs to complete the function of deleting a server record (Funcl), if the server successfully deletes the record Record, the terminal application A continues to complete some other function (referred to as Func2); if the server fails to delete the record, the terminal application A completes some other function (called Func3). Since the Brew platform is asynchronous communication, the above requirements require different processing according to different processing results of the server, that is, the Func2 is successfully continued, and the Func3 is failed. Therefore, the terminal application must receive the response sent by the server before processing. The terminal application must perform synchronous conversion control on Funcl, that is, the terminal application A must wait for the server to return the processing result of Funcl before continuing other operations.

In the prior art, there is no solution for implementing asynchronous to synchronous control on a single-threaded platform such as Brew.

Summary of the invention

Embodiments of the present invention provide a method, system, and apparatus for communication between a terminal and a server, which can convert asynchronous communication on a single-thread platform into synchronous communication.

An embodiment of the present invention provides a method for a terminal to communicate with a server, which is used in a system for a single-threaded platform. The method includes: the terminal sends a strange request message to the server and locks the user interface; and the terminal receives the return from the server. When the response message of the request message is described, the user interface lock is processed and released according to the preset callback method corresponding to the request message.

The embodiment of the present invention further provides an apparatus for a terminal and a server to communicate through a single-threaded platform, where the apparatus includes: a storage unit, configured to store callback information, where the callback information includes at least a request message sent by the terminal. a callback processing unit, configured to: when the terminal sends the request message, lock the user interface, and when the terminal receives the response message of the request message returned by the server, invoke the corresponding request message stored in the storage unit The callback information is processed and the user interface is unlocked.

The embodiment of the present invention further provides a terminal, including an application unit, a single-thread platform, and a user interface, and further includes an blocking control, where: an application unit, configured to preset callback information to the blocking control, send a request message, and simultaneously start the blocking control. The preset callback information includes at least callback information corresponding to the request message, and an blocking control, configured to store callback information preset by the application unit and lock the user interface when the application unit sends the request message, and When receiving the response message of the request message returned by the server, the preset callback information corresponding to the request message is invoked for processing and the user interface is unlocked. The single-threaded platform is configured to forward the request message sent by the application unit to a server, and forward the message returned by the server to the blocking control used by the application unit. The embodiment of the invention further provides a system for communication between a terminal and a server, the system comprising a terminal and a server, the terminal comprising an blocking control, an application unit, a single-threaded platform and a user interface, wherein: the application unit is configured to block The control presets the callback information, sends a request message to the server, and starts the blocking control at the same time, the preset callback information includes at least the callback information corresponding to the clearing message; and the blocking control is configured to store the application unit to Setting the callback information and locking the user interface when the application unit sends the request message, and calling the preset callback information corresponding to the request message to be processed and released when receiving the response message of the request message returned by the server User interface is locked. a single-threaded platform, configured to forward the request message sent by the application unit to the server, and forward the message returned by the server to the blocking control used by the application unit; the server is configured to process the request message sent by the application unit, and Return messages to a single-threaded platform.

The embodiment of the present invention is based on the message mechanism of the single-threaded platform itself, and only needs to set a blocking control on the application unit, so that the UI is locked before a certain request sent by the user is not returned, so that the terminal does not process the request on the keyboard, the screen, the touchpad, and the like. Respond to achieve synchronization of messages on a single-threaded platform, providing a convenient method for synchronous communication for applications such as C/S and B/S on wireless terminals of single-threaded platforms. When the embodiment of the present invention is applied to the Brew platform, synchronous communication between the terminal and the server based on the Brew platform can be realized.

DRAWINGS

1 is a flow chart of an embodiment of a method for communicating between a terminal and a server according to the present invention;

2 is a flow chart of a specific embodiment of a method for communicating a terminal and a server according to the present invention; and FIG. 3 is a schematic structural diagram of a system for communicating between a terminal and a server according to the present invention.

detailed description

In order to better understand the embodiments of the present invention, the Brew platform is taken as an example and described with reference to the accompanying drawings.

First, let's explain the message mechanism of the existing Brew platform.

The Brew platform uses a layering mechanism, including an AEE (Application Execute Environment) layer, an OEM (Original Equipment Manufacturer) layer, a driver, and a system service layer. The embodiments of the present invention are mainly applied to the AEE layer. Brew AEE is a green software interface layer that supports the Brew API (Application Programming Interface) and runtime environment. At the same time, AEE also manages application execution and responds in time. Users and some emergency events, such as incoming calls and text messages, for example, when an incoming call comes in, a running Brew app can immediately pause and resume work automatically after the call is completed.

The basic organizational unit of Brew AEE's environment is the module, which is the basic unit of Brew application development and deployment. It contains two elements in the module: application (Applet) and class (Class), where:

Application: It is the basic execution unit of the Brew platform. Because Brew is single-threaded, no matter how many applications are in a module, only one application is activated at a time. One application can be launched by another application, but in this case, the current application is suspended and switched to another application. To illustrate the relationship between the application and the server, in the following, the application is represented by the terminal application.

Classes: Classes in AEE are the basic units that Brew can reuse, and the reuse scope of a class is not limited to the module it is in, but the entire AEE environment. The access point of a class (that is, a set of APIs that perform a specific function) is called an Interface. All of Brew's APIs are organized in classes that provide interfaces for functions such as display, file operations, address book access, etc. At the same time, Brew allows application developers to write their own classes.

The Brew platform's API is asynchronous, and callbacks are one of the most ingenious ways to implement asynchronous methods. Therefore, the Brew platform often uses callbacks for asynchronous communication. The callback can be implemented by a callback function. When an event occurs, the system or other function will automatically call a user-defined function, which is a callback. For example, using a callback to register an asynchronous message, the API requires the active object to log the callback before the service is requested. When the request is completed, the platform passes the returned callback method to the active object by calling the recorded callback method.

In the embodiment of the present invention, based on the existing message mechanism of the Brew platform, an blocking control is set to ensure that the UI (User Interface) is locked before the response message sent by the terminal application to the server is returned, and the keyboard and the screen are not responded. The processing of the touchpad, etc., thereby achieving the effect of requesting asynchronous analog conversion to synchronization.

First, the present invention provides an embodiment of a method for communicating between a terminal and a server. As shown in the flowchart of FIG. 1, the method in this embodiment includes:

Step 101: The terminal sends a request message to the server to lock the user interface.

Step 102: The terminal obtains a message returned by the server, and compares whether the identifier of the message is the same as the identifier of the request message, and if yes, processes the callback method corresponding to the preset request message. And unlock the user interface; otherwise, discard the message returned by the server. It should be noted that after the terminal obtains the message returned by the server, the purpose of comparing whether the identifier of the message is the same as the identifier of the request message is: determining whether the message returned by the server is a response message of the sent request message. Means for determining whether to receive a response message for a request message include, but are not limited to, an identification of the comparison message.

A specific implementation method of an embodiment of the present invention is described. Referring to FIG. 2, it is a flowchart of a specific implementation manner of a method for communicating a terminal with a server.

For example, the terminal application initiates a request to add a user record to the server because the service needs to be processed by the following steps:

Step 201: The terminal application registers the identifier of the request message with the blocking control. The Brew platform message is divided into two types: system message and application message. The message here refers to the application message. The application message identifier can be the message name or the message number. The specific rule can be customized by the user, for example, the terminal application adds a record message to the server. The number is 10001, then 10001 is registered to the blocking control, registration can be achieved by calling the corresponding API function.

Step 202: The terminal application registers the callback method (ie, callback information) after returning the message from the server, and the timeout control callback method (ie, callback information) when the message is timed out without returning to the blocking control.

Step 203: The terminal application sends a request message to the server to add a user record, and starts the blocking control to wait for the return of the response message, and the blocking control will lock the UI and start timing. When the UI is locked, the blocking control blocks all messages that are different from the identity of the sent request message, including keyboard response, screen processing, touchpad, soft keyboard, and dedicated keyboard. However, after the UI locks, the blocking control blocks only the UI-related messages, and does not block other system messages, such as alarm timing, network connection status change notifications, and so on. For example, before the UI is locked, when the user inputs a character through the keyboard, the Brew platform will send the button message to the output system, such as screen display; but when the UI is locked, the user performs the same operation, although the Brew platform still The received button message is processed, but since the UI is locked at this time, the message displayed on the screen is blocked by the application, so the screen does not display the information input by the user.

Step 204: The request message is transmitted to the terminal communication module through the Brew AEE framework.

Step 205: The terminal communication module transmits a request message to the service server through the wireless network.

Step 206: The service server determines the operation by using the parameter of the identifier of the request message. Therefore, corresponding processing is performed. For example, when the message number is 10001, the server completes an operation of adding a user record, and sends the return message to the terminal communication module through the wireless network.

Step 207: The terminal communication module transmits a return message to the Brew AEE framework where the terminal is located. Step 208: The Brew AEE framework sends a return message to the terminal application.

Step 209: The blocking control used by the terminal application receives the return message. Because the UI is locked, only the blocking control is active at this time, so only the blocking control can receive the response.

Step 210: The blocking control determines whether the return message times out. If the preset time is exceeded, step 211 is performed; otherwise, step 212 is performed. The timeout is a request failure, such as a connection timeout, the service is terminated, or the user chooses to re-initiate the request.

Step 211: The blocking control processes the return message according to the registered timeout control callback method, and unloads the blocking control to release the UI lock. In addition, it should be noted that if the terminal does not receive any message returned by the server when the preset time exceeds the preset time, it is also processed according to the registered timeout control callback method.

Step 212: The blocking control determines whether the identifier of the received message is the same as the identifier of the request message, such as the message number. If yes, step 213 is performed; if no, step 214 is performed. Since the identity of the request message has been previously registered to the blocking control, the identity of the returned message and the registered request message identifier can be directly compared.

Step 213: The blocking control processes the return message according to the registered request message callback method, and uninstalls the blocking control to release the UI lock. After the message is returned, the message callback method call returns the parameters in the message, decodes the parameter, and associates the sent message with a specific application to perform the corresponding service.

Step 214: The blocking control discards the message, that is, blocks all messages that are different from the identifier of the request message. Of course, the blocking control may not discard the message, as long as the blocking control receives the response message of the request message at the terminal (or The user interface is unlocked when the preset time is exceeded, and the user interface is locked for the rest of the time.

The above steps implement the communication mode in which the terminal application continues to perform corresponding processing according to the result returned by the server after the request of the terminal is initiated, that is, the synchronization mode, thereby realizing the synchronous communication between the terminal and the server on the Brew platform.

The method in which the terminal application registers the request message with the blocking control, the callback method of the message, and the timeout control callback method in the step 201 to the step 202, that is, the request message and the callback method are pre-saved. Correspondence between the two.

It should be noted that the preset timeout control callback method in this embodiment is an alternative. Since the real-time performance of the network transmission is limited by the communication conditions, in this embodiment, in order to prevent the user from falling into an infinite loop and failing to respond to the system message in time and possibly causing a mandatory restart of the wireless terminal, the blocking control is set. A timer initializes a timeout control callback method and calls this callback method after the timer expires.

Of course, you can also set the timeout control callback method, such as whether the user chooses to wait or not, and performs the corresponding manual operation. The timeout control callback method used in this embodiment can also be implemented by the system counting method.

Whether it is a registered request message callback method or a timeout control callback method, the blocking control is uninstalled to unlock the UI and release system resources.

When the terminal application initiates a request to delete/modify a record for the service server, the process is the same as that in the foregoing embodiment, and only the correspondence between the request message identifier and the message callback method is preset, and then sent to the server. Requesting a message, simultaneously locking the UI, the server completes the operation of deleting/modifying a record, and the blocking control compares the return message with the identifier of the request message. If the same, the method is processed according to the callback method corresponding to the preset request message, and the UI lock is released. ; Otherwise, the return message is discarded. The timeout control callback method can also be preset. If the response message is not received after the timeout, the preset timeout control callback method is called, and the UI lock is released.

The embodiment of the invention provides a system for communication between a terminal and a server. The system provides an blocking control on the existing Brew platform for the asynchronous communication mode of the terminal application, and the message sent by the blocking application in the terminal application is not returned. The UI is always locked before the corresponding response, and after the server returns a response, the processing of the service is continued, thereby converting the asynchronous communication mode of the terminal application into the synchronous communication mode.

As shown in FIG. 3, the system includes: an application unit 301, a blocking control 302, a Brew platform 303, and a server 400 inside the wireless terminal 300, wherein:

The application unit 301 is configured to preset a callback method corresponding to the request message to the blocking control 302. When the request message is sent, the blocking control 302 is started to lock the UI, where the callback method corresponding to the preset request message can be identified by the registration request message. And the callback method corresponding to the request message is implemented.

The blocking control 302 is configured to receive and save the corresponding message corresponding to the request message preset by the application unit 301. The method, such as saving the identifier of the request message and the corresponding callback method, and receiving the return message forwarded by the Brew platform 303, comparing whether the identifier of the returned message is the same as the identifier of the request message, and if so, the call has been The callback method corresponding to the registered request message is processed, and the blocking control is uninstalled to release the UI lock;

The Brew platform 303 is configured to forward the request message sent by the application unit 301 to the server 400, and send the response message returned by the server 400 to the blocking control 302 used by the application unit 301. The server 400 is configured to receive the sending by the application unit 301. The request message is processed accordingly and a response message is sent back.

In order to provide a more friendly human-computer interaction interface for the user, avoiding an infinite loop and failing to respond to the system message in time to cause a mandatory restart of the wireless terminal, a timer is set in the blocking control 302, and is initialized by the application unit 301. Registering the timeout control callback method with the blocking control 302, and simultaneously starting the blocking control 302, and then, when the timer exceeds the preset time, if the response message of the request message has not been received, the blocking control 302 is called. The registered timeout controls the callback method and unloads the blocking control to unlock the UI.

In the system, the Brew platform sends a request message to the terminal communication module, and the terminal communication module transmits the message to the server through the wireless network, and the message returned by the server is first transmitted to the terminal communication module through the wireless network, and is sent by the terminal communication module to the terminal. Brew platform.

The embodiment of the present invention further provides a device for communicating between a terminal and a server through a single-thread platform, that is, an blocking control 302, as shown in FIG. 3, to convert the asynchronous communication mode of the terminal application into a synchronous communication mode. The blocking control 302 includes a storage unit 3021, a comparison unit 3022, and an execution unit 3023, where:

The storage unit 3021 is configured to save a callback method corresponding to the request message sent by the application unit 301, such as saving the identifier of the clear request message and a callback method corresponding to the message (ie, callback information); and comparing unit 3022, The message returned by the server 400 forwarded by the Brew platform 303 is compared with the identifier of the request message sent by the application unit 301, and the comparison result is sent to the execution unit 3023; since the request message sent by the application unit 301 has been saved in the storage unit 3021. The identifier, so the identifier of the return message can be directly compared with the identifier of the request message held in the storage unit 3021.

The executing unit 3023 is configured to lock the UI, and invoke the phase according to the result sent by the comparing unit 3022. The method should be processed. If the return message is the same as the request message identifier sent by the application unit 301, the callback method corresponding to the request message saved in the storage unit 3021 is called for processing, and the blocking control is uninstalled to release the UI lock.

In order to provide a more user-friendly interactive interface, the device may further include a timing unit 3024. The storage unit 3021 is further configured to store a timeout control callback method registered by the application unit 301. The timing unit 3024 is configured to start timing when the UI is locked. And the execution unit 3023 is notified when the timeout occurs; the execution unit 3023 is configured to call the timeout control callback method registered in the storage unit 3021 to process when the notification of the timing unit 3024 is received and the same comparison result of the identification of the comparison unit is not received, And uninstall the blocking control to unlock the UI.

According to the above description, the related processing of the timeout control callback method is optional. Therefore, the callback information preset by the application unit 301 to the blocking control 302 may include at least the callback information corresponding to the request message, and may also include a timeout control. The callback information is further included, and the information stored by the storage unit 3021 includes callback information corresponding to the request message preset by the application unit 3023, and may further include timeout control callback information.

Correspondingly, the execution unit 3023 can also be considered to include two execution units, the first execution unit and the second execution unit, wherein the first execution unit locks the user interface when the application unit 301 sends the request message, and informs the comparison unit 3022. When the comparison result is the same, the callback information corresponding to the request message stored in the storage unit 3021 is called for processing, and the user interface is unlocked. The second execution unit is configured to, when receiving the preset time notification of the timing unit 3024 and the comparison unit 3022 does not obtain the same comparison result, call the timeout control callback information stored by the storage unit 3021 for processing, and release the user interface lock.

If the system formed by the terminal and the server is relatively stable, the related processing of the timeout control callback information may not be performed, that is, the application unit 301 does not need to preset the timeout control callback information to the blocking control 302, and thus the blocking control 302 does not need to set the second execution unit. Of course, the timing unit 3024 does not need to exist.

In addition, it should be noted that the comparison unit 3022 compares whether the request message identifier and the server return message identifier are the same in the purpose of: determining whether the server return message is a response message of the sent request message, and if the identifiers are the same, the server returns that the message is The response message of the sent request message, if the identifier is different, indicates that the server returns a message that is not a response message of the sent request message. Therefore, the comparison identifier is only one specific embodiment for determining whether the terminal receives the response of the request message, and any functional unit that can determine whether the server return message is a response message of the sent request message can replace the comparison unit 3022. Such functional units are collectively referred to as a determining unit for determining whether the server returns a message as a response message to the transmitted request message. Further, if the system is relatively stable, and the second execution unit is not required to be set in the terminal, the basic function of blocking the user interface performed by the determining unit and the first execution unit is to lock the user interface when the terminal sends the request message. And when the terminal receives the response message of the request message returned by the server, calling the callback information corresponding to the request message stored in the storage unit to process and unlock the user interface. Thereby, the determining unit and the first executing unit can be merged together, which is called a blocking processing unit.

According to the technical solution of the embodiments of the present invention, the UI is locked when the terminal sends the request message, and only when the terminal receives the response message of the request message, the terminal can process and release the UI lock according to the preset callback information; Keeping the UI locked, so that the terminal does not respond to processing requests such as keyboard, screen, touchpad, etc., thereby realizing synchronization of messages on a single-threaded platform, and developing applications such as C/S and B/S on a wireless terminal of a single-threaded platform. Provides a convenient way to synchronize communications.

Further, in order to avoid that the response message cannot be returned due to network or server failure, thereby causing unnecessary waiting by the user and possible forced start of the wireless terminal, in one embodiment of the present invention, a method of timeout control is adopted, so that the terminal does not receive When the response message to the request message has exceeded the preset time, the preset timeout control callback information may be directly called for processing and the UI lock is cancelled; otherwise, if the preset time is not exceeded and the terminal does not receive the response message of the request message, Then, the UI is locked, so that the terminal does not respond to the processing request of the keyboard, the screen, the touchpad, etc., thereby realizing the synchronization of the messages on the single-threaded platform, and providing the user with a more friendly human-computer interaction interface.

The foregoing detailed description of a scheme for communicating terminal and server provided by the embodiments of the present invention is only for helping to understand the method and core idea of the present invention. Meanwhile, for those skilled in the art, according to the present invention The idea of the embodiment will be changed in the specific implementation and application scope. For example, the present invention is not only applicable to the Brew platform, but for all terminal applications based on the single-thread application platform, if the application and the application and the lower layer The communication between the platforms is asynchronous, and the synchronous communication between the terminal and the server can be realized by using the solution provided by the embodiment of the present invention. In conclusion, the content of the present specification should not be construed as limiting the invention.

Claims

Rights request

A method for communicating a terminal with a server, the system for a single-threaded platform, wherein the method includes:

The terminal sends a request message to the server and locks the user interface;

When receiving the response message of the request message returned by the server, the terminal processes and releases the user interface lock according to the preset callback method corresponding to the request message.

2. The method according to claim 1, further comprising:

The terminal starts timing when the user interface is locked;

When the timer exceeds the preset time and the terminal does not receive the response message of the request message, the user interface lock is processed and released according to the preset timeout control callback method.

The method according to claim 1 or 2, wherein, when the message identifier returned by the server is the same as the identifier of the request message, the terminal determines that the message returned by the server is a response of the request message. Message.

4. An apparatus for communication between a terminal and a server over a single-threaded platform, wherein the apparatus comprises:

a storage unit, configured to store callback information, where the callback information includes at least callback information corresponding to the request message sent by the terminal;

The blocking processing unit is configured to: when the terminal sends the request message, the user interface is locked, and when the terminal receives the response message of the request message returned by the server, the callback information corresponding to the request message stored in the storage unit is invoked. Process and unlock the user interface.

The device according to claim 4, wherein the blocking processing unit specifically includes: a determining unit, configured to determine, by the terminal, whether the message returned by the server is a response message of the request message;

a first execution unit, configured to: when the terminal sends the request message, lock the user interface, and when the result determined by the determining unit is a positive result, call the callback information corresponding to the request message stored in the storage unit for processing Unlock the user interface.

6. Apparatus according to claim 5 wherein:

The determining unit is specifically a comparing unit, configured to compare whether the identifier of the server return message is the same as the identifier of the request message, and the same indicates that the message returned by the server is the ringing of the request message. The message should be different; indicating that the message returned by the server is not a response message to the request message.

The apparatus according to claim 5 or 6, wherein the callback information stored by the storage unit further includes timeout control callback information, and the blocking processing unit further includes a timing unit and a second execution unit, where:

a timing unit for starting timing when the user interface is locked, and notifying the second execution unit when the timing exceeds the preset time;

a second execution unit, configured to invoke the timeout control callback information stored in the storage unit to process and release when the preset time notification of the timing unit is received and the determining unit does not obtain a positive result User interface is locked.

8. A terminal, comprising an application unit, a single-threaded platform, and a user interface, further comprising: a blocking control, wherein:

An application unit, configured to preset callback information to the blocking control, send a request message, and start the blocking control at the same time, where the preset callback information includes at least callback information corresponding to the request message;

Blocking control for storing callback information preset by the application unit and locking the user interface when the application unit sends the request message, and calling the preset when receiving the response message of the odd request message returned by the server The callback information corresponding to the request message is processed and the user interface is unlocked;

The single-threaded platform is configured to forward the request message sent by the application unit to a server, and forward the message returned by the server to an blocking control used by the application unit.

The terminal according to claim 8, wherein the blocking control specifically includes: a storage unit, configured to store callback information, where the callback information includes at least callback information corresponding to the request message sent by the terminal;

a blocking processing unit, configured to: when the terminal sends a request message to the server, to lock the user interface, and when the terminal receives the response message of the request message returned by the server, invoke the request message stored in the storage unit The callback information is processed and the user interface is unlocked.

The terminal according to claim 9, wherein the blocking processing unit comprises: a determining unit, configured to determine whether a message returned by the server received by the terminal is a response message of the request message;

a first execution unit, configured to lock the user interface when the terminal sends a request message to the server, and When the result determined by the determining unit is a positive result, the callback information corresponding to the request message stored in the storage unit is invoked for processing and the user interface is unlocked.

11. The terminal of claim 10, wherein:

The determining unit is specifically a comparing unit, configured to compare whether the identifier of the server return message is the same as the identifier of the request message, and the same indicates that the message returned by the server is a response message of the request message; The returned message is not a response message to the request message.

The terminal device according to claim 10 or 11, wherein the callback information preset by the application unit to the blocking control further includes timeout control callback information, and the callback information stored by the storage unit further includes the timeout control Callback information, the blocking control further includes a timing unit and a second execution unit, wherein:

a second execution unit, configured to call the timeout control callback information stored by the second storage unit to process and release the user when receiving the preset time notification of the timing unit and the determining unit does not obtain a positive result The interface is locked.

A system for communicating with a server, the system comprising a terminal and a server, wherein the terminal comprises a blocking control, an application unit, a single-threaded platform and a user interface, wherein: the application unit is configured to block the control The preset callback information is sent to the server and the blocking control is started at the same time. The preset callback information includes at least a callback blocking control corresponding to the request message, and is used to store a callback preset by the application unit. And locking the user interface when the application unit sends the request message, and calling the preset callback information processing corresponding to the request message and releasing the user interface lock when receiving the response message of the request message returned by the server ;

a single-threaded platform, configured to forward the request message sent by the application unit to the server, and forward the message returned by the server to the blocking control used by the application unit;

A server that processes the request message sent by the application unit and returns the message to the single-threaded platform.

The system of claim 13, wherein the blocking control comprises: a storage unit, configured to store callback information, where the callback information includes at least a request sent by the terminal. Callback information corresponding to the interest;

a blocking processing unit, configured to: when the terminal sends a request message to the server, to lock the user interface, and when the terminal receives the response message of the request message returned by the server, invoke the The callback information corresponding to the request message is processed and the user interface is unlocked.

The system according to claim 14, wherein the blocking processing unit specifically comprises:

a determining unit, configured to determine whether the message returned by the server received by the terminal is a response message of the request message;

a first execution unit, configured to: when the terminal sends a request message to the server, to lock the user interface, and when the result determined by the determining unit is a positive result, call the callback information corresponding to the request message stored in the storage unit Process and unlock the user interface.

The system according to claim 15, wherein the callback information preset by the application unit to the blocking control further includes timeout control callback information, and the callback information stored by the storage unit further includes the timeout control callback information. The blocking control further includes a timing unit and a second execution unit, wherein:

a timing unit for starting timing when the user interface is locked and notifying the second execution unit when the timing exceeds the preset time;

The system according to any one of claims 13 to 16, wherein the system further comprises a terminal communication module, configured to send a request message sent by the single-threaded platform to the server through the wireless network, and the server The returned message is sent to a single-threaded platform.