A method for data interaction between mobile terminals and servers

Abstract

This invention discloses a method for data interaction between mobile terminals and servers, which solves the problems of data consistency and continuity when servers interact with different terminals, while maintaining loose coupling between the server and the terminal. The technical solution is as follows: a first terminal encapsulates data into a JSON-formatted byte stream string; the first terminal submits the encapsulated byte stream string as an attribute in the JSON format to the server; the server parses the JSON-formatted data from the received byte stream string and stores the byte stream separately, establishing an index relationship between the parsed business data and the separately stored byte stream; when the server receives a request from a second terminal to retrieve JSON-formatted data, it returns the corresponding JSON-formatted byte stream string; the second terminal parses the received JSON-formatted byte stream string to recover the local data.

Description

Technical Field

[0001] This invention relates to a data interaction technology, specifically a method for data interaction between a mobile terminal and a server. Background Technology

[0002] Currently, the mainstream method for data interaction between mobile devices and servers is through JSON format. JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is based on a subset of ECMAScript (the JavaScript specification defined by the European Computer Association) and uses a text format completely independent of programming languages ​​to store and represent data. Its concise and clear hierarchical structure makes JSON an ideal data exchange language, easy for humans to read and write, easy for machines to parse and generate, and effectively improves network transmission efficiency.

[0003] The mobile app encapsulates the requested data into a JSON string, specifying the contentType as application / json in the request header. The server then uses @RequestBody to convert the JSON string into a Java object as input. After business processing, the Java object to be returned to the mobile app is converted back into a JSON string. Finally, the mobile app parses the JSON string to form the page to be displayed.

[0004] The main drawback of this approach is the data distortion issue that occurs when the data submitted by the first terminal is retrieved by the second terminal, especially when dealing with complex data structures. Specifically, the different business value propositions of the mobile terminal and the server lead to differences in their data structures, for example... Figure 1 As shown, when the first terminal submits JSON data with attributes (a,b,c,d,e) to the server, the server does not persist d and e because it considers d and e to have no actual business value, and only saves (a,b,c). Therefore, when the second terminal requests the same business data from the server, the JSON data (a,b,c) obtained is often very different from the JSON data (a,b,c,d,e) submitted by the first terminal. However, for the second terminal, d and e may also be data with temporary business value.

[0005] To solve the above problems, the most obvious solution is to keep the server's data structure consistent with that of the terminal. However, this solution would result in a large number of table structures and data on the server side that have no actual business value, and would also cause tight coupling between the terminal and the server, which would be very detrimental to later maintenance. Summary of the Invention

[0006] The following provides a brief overview of one or more aspects to offer a basic understanding of them. This overview is not an exhaustive summary of all conceived aspects, nor is it intended to identify key or decisive elements of all aspects, nor to define the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form to prepare for the more detailed descriptions that follow.

[0007] The purpose of this invention is to solve the above-mentioned problems and provide a method for data interaction between mobile terminals and servers, which solves the problems of data consistency and continuity when servers and different terminals interact, while maintaining loose coupling between the server and the terminal.

[0008] The technical solution of this invention is as follows: This invention discloses a method for data interaction between a mobile terminal and a server, the method comprising:

[0009] Step 1: The first terminal encapsulates the data into a byte stream string in JSON format;

[0010] Step 2: The first terminal submits the encapsulated byte stream string to the server as a JSON attribute;

[0011] Step 3: The server parses the JSON data from the received byte stream string and stores the byte stream separately. It then establishes an index relationship between the parsed business data and the separately stored byte stream.

[0012] Step 4: When the server receives a request from the second terminal to obtain JSON format data, it returns the corresponding JSON format byte stream string;

[0013] Step 5: After receiving the JSON formatted byte stream string, the second terminal parses and restores the local data.

[0014] According to an embodiment of the method for data interaction between a mobile terminal and a server according to the present invention, in step 1, before the first terminal submits data to the server, the data to be submitted to the server is selectively encapsulated into JSON format and converted into a byte stream string according to the data consistency and continuity requirements between different terminals.

[0015] According to an embodiment of the method for data interaction between a mobile terminal and a server according to the present invention, in step 2, the server-side interface API additionally provides jsonStream and jsonStreamVer properties, which are used to store the byte stream string and its version, respectively. When the first terminal submits business data in JSON format, it uses the byte stream string encapsulated in step 1 as the jsonStream property. When it is added for the first time, jsonStreamVer is empty. The jsonStreamVer property is used to control data synchronization and version conflict issues between different terminals.

[0016] According to an embodiment of the method for data interaction between a mobile terminal and a server according to the present invention, in step 3, after the server receives the data submitted by the first terminal, it parses the JSON data submitted in step 2. First, it determines whether the terminal data is being received for the first time based on the ID of the business data and the value of the jsonStreamVer attribute. If it is being received for the first time, the attributes corresponding to the business data are processed according to the business rules and stored in the corresponding business data table. Then, the jsonStream byte stream string is bound to the business data ID value and persistently stored in the jsonStream table, and the version of the jsonStream byte stream string is set to 1.

[0017] According to an embodiment of the method for data interaction between a mobile terminal and a server according to the present invention, in step 4, when the second terminal requests the server to obtain the business data, the JSON format data returned by the server includes the jsonStream byte stream string corresponding to the business data ID and its version. The JSON format return parameters only include the business data ID, the jsonStream attribute and the version attribute, and other parameters are returned separately as needed for the business.

[0018] According to an embodiment of the method for data interaction between a mobile terminal and a server based on the present invention, in step 5, after the second terminal receives the data returned by the server, it first compares it with the version attribute corresponding to the local business data ID. If the local version does not exist or the version is lower than the server version, the jsonStream needs to be reverse-parsed into JSON format data and then restored to the local data structure of the first terminal. If the local version is not lower than the server version, it means that the data version of the second terminal is higher than the server version, and the data synchronized this time is not updated, so as to realize the collaborative processing of the same data between different terminals. After version control, data inconsistency and version conflict problems will not occur.

[0019] This invention also discloses a method for data interaction between a mobile terminal and a server, the method comprising:

[0020] Step 1: The first terminal encapsulates the master-slave table data into a JSON format byte stream string;

[0021] Step 2: The first terminal submits the master and slave table attributes, encapsulated as byte stream strings, as two attributes in JSON format to the server;

[0022] Step 3: The server parses the JSON formatted data from the received byte stream string and stores the byte streams of the master and slave tables separately. It then establishes an index relationship between the parsed master and slave table business data and the separately stored master and slave table byte streams.

[0023] Step 4: When the server receives a request from the second terminal to obtain JSON format data, it returns the corresponding JSON format byte stream string;

[0024] Step 5: After receiving the JSON format byte stream string, the second terminal parses it to restore the local data.

[0025] According to an embodiment of the method for data interaction between mobile terminals and servers according to the present invention, in step one, before the first terminal submits data to the server, the master-slave table data to be submitted to the server is selectively encapsulated into JSON format and converted into byte stream strings according to the data consistency and continuity requirements between different terminals.

[0026] According to an embodiment of the method for data interaction between mobile terminals and servers according to the present invention, in step two, the server-side interface API additionally provides jsonStream and jsonStreamVer attributes of master and slave tables, which are used to store the byte stream string and its version, respectively. When the first terminal submits business data in JSON format, it uses the master and slave table byte stream strings encapsulated in step one as master and slave jsonStream attributes respectively. When it is added for the first time, jsonStreamVer is empty. The jsonStreamVer attribute is used to control data synchronization and version conflict issues between different terminals.

[0027] According to an embodiment of the method for data interaction between a mobile terminal and a server according to the present invention, in step three, after the server receives the data submitted by the first terminal, it parses the JSON data submitted in step two. First, it determines whether the terminal data is being received for the first time based on the ID of the business data in the master-slave table and the value of the jsonStreamVer attribute. If it is being received for the first time, the attributes corresponding to the business data in the master-slave table are processed according to the business rules and stored in the corresponding business data table. Then, the jsonStream byte stream strings of the master-slave table are bound to the ID value of the business data in the master-slave table respectively and persistently stored in the jsonStream table, and the version of the jsonStream byte stream strings is set to 1 respectively.

[0028] According to an embodiment of the method for data interaction between a mobile terminal and a server according to the present invention, in step four, when the second terminal requests the server to obtain the business data, the JSON format return parameters returned by the server only include the business data ID of the master and slave tables, the jsonStream attribute, and the version attribute, and other parameters are returned as needed for the business.

[0029] According to an embodiment of the method for data interaction between a mobile terminal and a server according to the present invention, in step five, after the second terminal receives the data returned by the server, it first compares it with the version attribute corresponding to the business data ID in the local master-slave table. If the local version does not exist or the version is lower than the server version, the jsonStream needs to be reverse-parsed into JSON format data and then restored to the local data structure of the first terminal. If the local version is not lower than the server version, it means that the data version of the second terminal is higher than the server version, and the data synchronized this time is not updated, so as to realize the collaborative processing of the same data between different terminals. After version control, there will be no data inconsistency or version conflict problems.

[0030] Compared with the prior art, the present invention has the following advantages: The method of the present invention encapsulates the terminal business data into JSON format and converts it into a binary stream string. Then, the binary stream string is used as an attribute in the JSON string submitted to the server. The server only needs to save this binary stream string attribute and its version. When other terminals request the business data, the binary stream string and its version are returned. This solves the problem of data consistency and continuity between the server and different terminals, and also maintains the loose coupling between the server and the terminal. Attached Figure Description

[0031] The above-described features and advantages of the present invention will be better understood after reading the following detailed description of embodiments of the present disclosure in conjunction with the accompanying drawings. In the drawings, components are not necessarily drawn to scale, and components having similar related characteristics or features may have the same or similar reference numerals.

[0032] Figure 1 An example diagram of a traditional JSON data exchange method is shown.

[0033] Figure 2 A flowchart of a first embodiment of the method for data interaction between a mobile terminal and a server according to the present invention is shown.

[0034] Figure 3 A schematic diagram of the server-side data structure in the first embodiment of the present invention is shown.

[0035] Figure 4 A flowchart of a second embodiment of the method for data interaction between a mobile terminal and a server according to the present invention is shown.

[0036] Figure 5 A schematic diagram of the server-side data structure in the second embodiment of the present invention is shown. Detailed Implementation

[0037] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. It should be noted that the aspects described below with reference to the accompanying drawings and specific embodiments are merely exemplary and should not be construed as limiting the scope of protection of the present invention in any way.

[0038] First embodiment of a method for data interaction between mobile terminals and servers

[0039] Figure 2 The flowchart of a first embodiment of the method for data interaction between a mobile terminal and a server according to the present invention is shown. Please refer to [link to relevant documentation]. Figure 2 The implementation steps of the method in this embodiment are detailed below. Furthermore, before describing this embodiment, we will still use... Figure 1 For example, suppose the first terminal has five attributes a, b, c, d, and e, while the server-side API can only save and return attributes a, b, and c. In this case, in order to ensure that the second terminal also has the same five attributes a, b, c, d, and e when receiving the business data,

[0040] Step S11: The first terminal encapsulates the data into a byte stream string in JSON format.

[0041] Before the first terminal submits data to the server, based on the data consistency and continuity requirements between different terminals, the data to be submitted to the server is selectively encapsulated into JSON format and converted into a byte stream string.

[0042] In this example, the first terminal encapsulates the five attributes a, b, c, d, and e into JSON format and converts them into a byte stream string.

[0043] Step S12: The first terminal submits the encapsulated byte stream string to the server as an attribute in JSON format.

[0044] The server-side API needs to provide additional `jsonStream` and `jsonStreamVer` properties, used to store the byte stream string and its version, respectively. When the first terminal submits business data in JSON format, it uses the byte stream string encapsulated in step S11 as the `jsonStream` property. When it is added for the first time, `jsonStreamVer` is empty. The `jsonStreamVer` property is used to control data synchronization and version conflict issues between different terminals.

[0045] In this example, the JSON format input parameters for the server-side API can be found here:

[0046]

[0047] Step S13: The server parses the JSON formatted data from the received byte stream string, stores the byte stream separately, and establishes an index relationship between the parsed business data and the separately stored byte stream.

[0048] After receiving the data submitted by the first terminal, the server parses the JSON data submitted in step S12. First, it determines whether this is the first time the terminal has received the data based on the business data's ID and the value of the `jsonStreamVer` attribute. If it is, the server processes the corresponding attributes of the business data (e.g., attributes a, b, and c in this example) according to business rules and stores them in the corresponding business data table. Then, it binds the `jsonStream` byte stream string with the business data's ID value and persists it to the `jsonStream` table, setting the version of the `jsonStream` byte stream string to 1. In this way, the server does not need to concern itself with the data structure of the `jsonStream` byte stream string to save the terminal's complete data structure, ensuring loose coupling between the terminal and the server. Figure 3 The storage structure of server-side data in the first embodiment is shown.

[0049] Step S14: When the server receives a request from the second terminal to obtain JSON format data, it returns the corresponding JSON format byte stream string.

[0050] When a second terminal requests the server to retrieve the business data, the server returns JSON-formatted data containing a jsonStream byte stream string corresponding to the business data ID and its version. The JSON-formatted return parameters only need to include the business data ID, the jsonStream attribute, and the version attribute; other parameters can be returned additionally as needed. See:

[0051]

[0052] Step S15: After receiving the JSON format byte stream string, the second terminal parses it and restores the local data.

[0053] When the second terminal receives the data returned by the server, it first compares it with the version attribute corresponding to the local business data ID. If the local version does not exist or is lower than the server version, the jsonStream needs to be reverse-parsed into JSON format data and then restored to the local data structure of the first terminal. If the local version is not lower than the server version, it means that the data version of the second terminal is higher than the server version, and the update of the synchronized data can be refused. This allows different terminals to collaboratively process the same data, and version control prevents data inconsistencies and version conflicts.

[0054] Second embodiment of the method for data interaction between mobile terminals and servers

[0055] Figure 4 The flowchart of a second embodiment of the method for data interaction between a mobile terminal and a server according to the present invention is shown. The difference from the first embodiment is that... Figure 3 This is a basic version of the invention. Figure 5 The diagram shows a relatively complex business data structure involving master-slave tables and other similar data structures.

[0056] Step S21: The first terminal encapsulates the master and slave table data into a byte stream string in JSON format.

[0057] Before the first terminal submits data to the server, based on the data consistency and continuity requirements between different terminals, the master-slave table data that needs to be submitted to the server is selectively encapsulated into JSON format and converted into a byte stream string.

[0058] In this example, we assume that the data structure of the first terminal is a main table with attributes a, b, c, x, y, z, and a secondary table with attributes d, e, f, g, h, i. The attributes a, b, c, x, y, z of the main table and the attributes d, e, f, g, h, i of the secondary table are encapsulated into JSON format and converted into byte stream strings.

[0059] Step S22: The first terminal submits the master and slave table attributes, which are encapsulated as byte stream strings, to the server as two attributes in JSON format.

[0060] The server-side API requires additional jsonStream and jsonStreamVer properties for the master and slave tables, respectively, to store the byte stream string and its version. When the first terminal submits business data in JSON format, it uses the master and slave table byte stream strings encapsulated in step S21 as the master and slave jsonStream properties. When adding data for the first time, jsonStreamVer is empty. The jsonStreamVer property is used to control data synchronization and version conflict issues between different terminals.

[0061] In this example, the JSON format input parameters for the server-side API can be found here:

[0062]

[0063] Step S23: The server parses the JSON formatted data from the received byte stream string and stores the byte streams of the master and slave tables separately. The parsed business data of the master and slave tables is then indexed with the separately stored byte streams of the master and slave tables.

[0064] After receiving the data submitted by the first terminal, the server parses the JSON data submitted in step S22. First, it determines whether this is the first time the terminal has received the data, based on the ID of the master-slave table business data and the value of the `jsonStreamVer` attribute. If it is the first time, the server processes the corresponding attributes of the master-slave table business data (e.g., attributes a, b, c in the master table and attributes d, e, f in the slave table) according to the business rules and stores them in the corresponding business data tables. Then, it binds the `jsonStream` byte stream strings of the master and slave tables to the corresponding business data ID values ​​and persists them to the `jsonStream` table, setting the version of each `jsonStream` byte stream string to 1. In this way, the server does not need to concern itself with the data structure of the `jsonStream` byte stream strings to save the complete master-slave table data structure of the terminal, ensuring loose coupling between the terminal and the server.

[0065] Compared to the first embodiment, this embodiment deals with relatively complex business data structures such as master-slave tables. The server can distinguish between master-slave and slave JSON streams by adding a type field to the JsonStream table. When the terminal obtains data from the server, the server reassembles the master-slave table JsonStreams according to the master-slave table structure, ultimately achieving data consistency and loose coupling under complex structures. Figure 5The storage structure of server-side data in the second embodiment is shown.

[0066] Step S24: When the server receives a request from the second terminal to obtain JSON format data, it returns the corresponding JSON format byte stream string.

[0067] When the second terminal requests the server to retrieve this business data, the server only needs to return JSON parameters containing the business data ID of the master and slave tables, the jsonStream attribute, and the version attribute. Other parameters can be returned as needed, as shown in the following example:

[0068]

[0069] Step S25: After receiving the JSON format byte stream string, the second terminal parses it and restores the local data.

[0070] When the second terminal receives the data returned by the server, it first compares it with the version attribute corresponding to the business data ID in the local master-slave table. If the local version does not exist or is lower than the server version, the jsonStream needs to be reverse-parsed into JSON format data and then restored to the local data structure of the first terminal. If the local version is not lower than the server version, it means that the data version of the second terminal is higher than the server version, and the update of the synchronized data can be refused. This allows different terminals to collaboratively process the same data, and version control prevents data inconsistencies and version conflicts.

[0071] Although the methods described above are illustrated and depicted as a series of actions for the sake of simplicity, it should be understood and appreciated that these methods are not limited by the order of the actions, as some actions may occur in a different order and / or concurrently with other actions from the illustrations and descriptions herein or not illustrated and described herein but which may be understood by those skilled in the art, according to one or more embodiments.

[0072] Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, the various illustrative components, blocks, modules, circuits, and steps are described above in a generalized manner in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as departing from the scope of the invention.

[0073] The various illustrative logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein can be implemented or performed using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but in alternatives, it may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors cooperating with a DSP core, or any other such configuration.

[0074] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of both. The software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor such that the processor can read and write information to / from the storage medium. In an alternative, the storage medium may be integrated into the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In an alternative, the processor and storage medium may reside as discrete components in the user terminal.

[0075] In one or more exemplary embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software as a computer program product, the functionality may be stored or transmitted as one or more instructions or code on or through a computer-readable medium. A computer-readable medium includes both computer storage media and communication media, encompassing any medium that facilitates the transfer of a computer program from one location to another. A storage medium may be any available medium accessible to a computer. By way of example and not limitation, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and is accessible to a computer. Any connection is also legitimately referred to as a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of a medium. As used in this article, disk and disc include compact discs (CDs), laser discs, optical discs, digital multi-purpose discs (DVDs), floppy disks, and Blu-ray discs. Disks typically reproduce data magnetically, while discs reproduce data optically using lasers. Combinations of these should also be included within the scope of computer-readable media.

[0076] The prior description of this disclosure is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not intended to be limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for data interaction between a mobile terminal and a server, characterized in that, The methods include: Step 1: The first terminal encapsulates the data into a byte stream string in JSON format; Step 2: The first terminal submits the encapsulated byte stream string to the server as a JSON attribute; Step 3: The server parses the JSON data from the received byte stream string and stores the byte stream separately. It then establishes an index relationship between the parsed business data and the separately stored byte stream. Step 4: When the server receives a request from the second terminal to obtain JSON format data, it returns the corresponding JSON format byte stream string; Step 5: After receiving the JSON formatted byte stream string, the second terminal parses it to recover the local data; In step 2, the server-side API additionally provides jsonStream and jsonStreamVer properties, which are used to store the byte stream string and its version, respectively. When the first terminal submits business data in JSON format, it uses the byte stream string encapsulated in step 1 as the jsonStream property. When it is added for the first time, jsonStreamVer is empty. The jsonStreamVer property is used to control data synchronization and version conflict issues between different terminals.

2. The method for data interaction between a mobile terminal and a server according to claim 1, characterized in that, In step 1, before the first terminal submits data to the server, the data to be submitted to the server is selectively encapsulated into JSON format and converted into a byte stream string according to the data consistency and continuity requirements between different terminals.

3. The method for data interaction between a mobile terminal and a server according to claim 1, characterized in that, In step 3, after the server receives the data submitted by the first terminal, it parses the JSON data submitted in step 2. First, it determines whether the terminal data is being received for the first time based on the ID of the business data and the value of the jsonStreamVer attribute. If it is being received for the first time, the server processes the attributes corresponding to the business data according to the business rules and stores them in the corresponding business data table. Then, it binds the jsonStream byte stream string with the business data ID value and persists it to the jsonStream table, and sets the version of the jsonStream byte stream string to 1.

4. The method for data interaction between a mobile terminal and a server according to claim 1, characterized in that, In step 4, when the second terminal requests the server to obtain the business data, the server returns JSON format data containing the jsonStream byte stream string corresponding to the business data ID and its version. The JSON format return parameters only contain the business data ID, jsonStream attribute and version attribute, and other parameters are returned as needed by the business.

5. The method for data interaction between a mobile terminal and a server according to claim 1, characterized in that, In step 5, after the second terminal receives the data returned by the server, it first compares it with the version attribute corresponding to the local business data ID. If the local version does not exist or the version is lower than the server version, the jsonStream needs to be reverse-parsed into JSON format data and then restored to the local data structure of the first terminal. If the local version is not lower than the server version, it means that the data version of the second terminal is higher than the server version, and the data synchronized this time is not updated. This enables different terminals to collaboratively process the same data. After version control, data inconsistency and version conflict issues will not occur.

6. A method for data interaction between a mobile terminal and a server, characterized in that, The methods include: Step 1: The first terminal encapsulates the master-slave table data into a JSON format byte stream string; Step 2: The first terminal submits the master and slave table attributes, encapsulated as byte stream strings, as two attributes in JSON format to the server; Step 3: The server parses the JSON formatted data from the received byte stream string and stores the byte streams of the master and slave tables separately. It then establishes an index relationship between the parsed master and slave table business data and the separately stored master and slave table byte streams. Step 4: When the server receives a request from the second terminal to obtain JSON format data, it returns the corresponding JSON format byte stream string; Step 5: After receiving the JSON formatted byte stream string, the second terminal parses it to recover the local data; In step two, the server-side API additionally provides the jsonStream and jsonStreamVer properties of the master and slave tables, which are used to store the byte stream string and its version, respectively. When the first terminal submits business data in JSON format, it uses the master and slave table byte stream strings encapsulated in step one as the master and slave jsonStream properties. When a new jsonStream is added for the first time, it is empty. The jsonStreamVer property is used to control data synchronization and version conflict issues between different terminals.

7. The method for data interaction between a mobile terminal and a server according to claim 6, characterized in that, In step one, before the first terminal submits data to the server, based on the data consistency and continuity requirements between different terminals, the master-slave table data that needs to be submitted to the server is selectively encapsulated into JSON format and converted into a byte stream string.

8. The method for data interaction between a mobile terminal and a server according to claim 6, characterized in that, In step three, after the server receives the data submitted by the first terminal, it parses the JSON data submitted in step two. First, it determines whether the terminal data is being received for the first time based on the ID of the business data in the master-slave table and the value of the jsonStreamVer attribute. If it is being received for the first time, the server processes the corresponding attributes of the business data in the master-slave table according to the business rules and stores them in the corresponding business data table. Then, it binds the jsonStream byte stream strings of the master-slave table with the ID value of the business data in the master-slave table and persists them to the jsonStream table, and sets the version of the jsonStream byte stream strings to 1 respectively.

9. The method for data interaction between a mobile terminal and a server according to claim 6, characterized in that, In step four, when the second terminal requests the server to obtain the business data, the JSON format parameters returned by the server only contain the business data ID of the master and slave tables, the jsonStream attribute, and the version attribute. Other parameters are returned as needed by the business.

10. The method for data interaction between a mobile terminal and a server according to claim 6, characterized in that, In step five, after the second terminal receives the data returned by the server, it first compares it with the version attribute corresponding to the business data ID in the local master-slave table. If the local version does not exist or the version is lower than the server version, the jsonStream needs to be reverse-parsed into JSON format data and then restored to the local data structure of the first terminal. If the local version is not lower than the server version, it means that the data version of the second terminal is higher than the server version, and the data synchronized this time is not updated. This is to enable different terminals to collaboratively process the same data. After version control, there will be no data inconsistency or version conflict issues.

Images