A method for automatically uploading local data of a mobile terminal to a server

Abstract

The application relates to a kind of mobile terminal local data automatic uploading server method, comprising: obtaining data to be processed;The data to be processed is verified;When verification succeeds, the data to be processed is divided to obtain data to be uploaded;According to preset upload configuration, data to be uploaded is uploaded;When uploading succeeds, the local data corresponding to the uploaded data is removed.The application adopts automatic uploading process, when mobile terminal exists data to be uploaded to server, instead of business party actively uploading, business party does not need to stay in uploading page, which greatly improves the use experience of business party.And the application verifies the data to be processed, and only allows uploading when verification succeeds, which can solve the data security risk.In the application, data to be uploaded is uploaded according to preset upload configuration, and by improving the flexibility of upload configuration, business party can configure uploading according to its own needs.

Description

Technical Field

[0001] This application relates to the field of automatic data upload technology for mobile devices, and in particular to a method for automatically uploading local data from a mobile device to a server. Background Technology

[0002] With the widespread adoption of smart devices, information is growing exponentially, leading to a continuous increase in the complexity of interactions between mobile devices and servers. Limited by factors such as device performance and network conditions, uploading local data from mobile devices presents numerous challenges, including: mobile devices cannot handle massive amounts of server data; bandwidth is prioritized and data resources are precious, making repeated uploads unsuitable; insufficient device performance can cause excessive processing time when loading too much data at once, impacting the user experience; excessive device memory usage can lead to the mobile device being "killed" by the system; and frequent data uploads from mobile devices negatively affect the user experience for business users.

[0003] Currently, some existing mobile automatic upload tools also implement the function of uploading to the server. The general idea is that the business user actively selects a file, clicks the upload button, and needs to stay on the current page until the upload is successful before leaving. This greatly affects the user experience and cannot guarantee resource security. In addition, due to different use cases, reusability is low, there are few or no configurable options, and flexibility is limited. Summary of the Invention

[0004] To at least partially overcome the problems of poor user experience, unreliable resource security, and limited flexibility when business users upload data from mobile devices in related technologies, this application provides a method for automatically uploading local data from mobile devices to a server.

[0005] The proposed solution is as follows:

[0006] A method for automatically uploading local data from a mobile device to a server includes:

[0007] Obtain the data to be processed;

[0008] The data to be processed is validated;

[0009] Upon successful verification, the data to be processed is divided into blocks to obtain the data to be uploaded.

[0010] The data to be uploaded is uploaded according to the preset upload configuration;

[0011] Upon successful upload, the local data corresponding to the uploaded data will be cleared.

[0012] Preferably, the method further includes:

[0013] When an upload fails, record the number of upload failures and determine whether the current number of upload failures exceeds a preset threshold.

[0014] If the value exceeds a preset threshold, the local data corresponding to the data to be uploaded will be cleared, and an error message will be sent back to the business side.

[0015] If the data is not greater than a preset threshold, the data to be uploaded will be used as local data to generate an upload failure dataset.

[0016] Preferably, the method further includes:

[0017] If the verification fails, the local data corresponding to the data to be uploaded will be cleared, and an error message will be sent back to the business side.

[0018] Preferably, acquiring the data to be processed includes:

[0019] The status of retrieving local data confirms the range of uploaded data.

[0020] If the local data contains a dataset of failed uploads, the data to be processed will be obtained first from the dataset of failed uploads, and then from the dataset uploaded by the business side.

[0021] A list of data to be processed is generated according to the order in which the data is retrieved.

[0022] Preferably, verifying the data to be processed includes:

[0023] Obtain the unique code generated when the business party registers;

[0024] The data to be processed is verified based on the unique code and the verification token contained in the data to be processed; wherein the verification token is generated by the business party according to a preset encryption method when uploading the dataset.

[0025] Preferably, the data to be processed is divided into blocks, including:

[0026] The data to be processed is divided into blocks according to the upload granularity preset by the business party.

[0027] Preferably, uploading the data to be uploaded according to a preset upload configuration includes:

[0028] Create a scheduled upload task based on the start time node set by the business party and the custom time step;

[0029] When the start time node is reached, a sub-thread is created to execute the timed upload task;

[0030] Monitor the number of child threads created and clean up any idle child threads.

[0031] Preferably, the method further includes:

[0032] On the business side's mobile device, the application is registered and bound, application configuration items are initialized, and the interface is injected.

[0033] Preferably, the method further includes:

[0034] Receive uploaded configuration information entered by the business party;

[0035] The upload configuration is performed according to the upload configuration information; the upload configuration includes at least: business version number, automatic upload switch, upload time step, batch upload limit, expired data cleanup time interval and local data limit size.

[0036] Preferably, the method further includes:

[0037] During a cold start, invalid data in the local database is retrieved and cleaned up.

[0038] The search for invalid data includes:

[0039] Expired data in the local data is retrieved as invalid data based on the pre-configured data validity period;

[0040] Data with a version number lower than the pre-configured version number in the local data is considered invalid.

[0041] When the size of local data exceeds the pre-configured local data limit, the excess portion will be treated as invalid data according to the storage time order of the local data.

[0042] The technical solution provided in this application can include the following beneficial effects: The method for automatically uploading local data from a mobile device to a server in this application includes: obtaining data to be processed; verifying the data to be processed; if the verification is successful, dividing the data to be processed into blocks to obtain data to be uploaded; uploading the data to be uploaded according to a preset upload configuration; and clearing the local data corresponding to the uploaded data upon successful upload. This application adopts an automated upload process. When there is data to be uploaded to the server on the mobile device, it automatically uploads it on behalf of the business party, eliminating the need for the business party to remain on the upload page, greatly improving the user experience. Furthermore, the verification of the data to be processed in this application, allowing upload only upon successful verification, can address data security risks. This application also uploads the data to be uploaded according to a preset upload configuration, increasing the flexibility of the upload configuration and allowing the business party to configure the upload according to its own needs.

[0043] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0044] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0045] Figure 1 This is a flowchart illustrating a method for automatically uploading local data from a mobile device to a server, according to an embodiment of this application.

[0046] Figure 2 This is a flowchart illustrating a method for automatically uploading local data from a mobile device to a server, provided in another embodiment of this application.

[0047] Figure 3 This is a flowchart illustrating a method for automatically uploading local data from a mobile device to a server, provided in another embodiment of this application. Detailed Implementation

[0048] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0049] Figure 1 This is a flowchart illustrating a method for automatically uploading local data from a mobile device to a server, provided in one embodiment of this application. (Refer to...) Figure 1 A method for automatically uploading local data from a mobile device to a server, comprising:

[0050] S11: Obtain the data to be processed;

[0051] S12: Verify the data to be processed;

[0052] S13: When the verification is successful, the data to be processed is divided into blocks to obtain the data to be uploaded;

[0053] S14: Upload the data to be uploaded according to the preset upload configuration;

[0054] S15: Upon successful upload, clear the local data corresponding to the uploaded data.

[0055] It should be noted that the technical solution in this embodiment relates to the technical field of automatic data uploading on mobile devices, and is specifically implemented on the mobile device of the business party.

[0056] It should be noted that obtaining the data to be processed includes:

[0057] The status of retrieving local data confirms the range of uploaded data.

[0058] If the local data contains a dataset of failed uploads, the data to be processed will be obtained first from the dataset of failed uploads, and then from the dataset uploaded by the business side.

[0059] A list of data to be processed is generated according to the order in which the data is retrieved.

[0060] In this embodiment, before uploading data, the range of data to be uploaded is confirmed by searching the status of local data, such as whether there are any failed upload datasets.

[0061] It should be noted that data retrieval will proceed in the order of failed upload datasets and business-uploaded datasets. Then, a pending list will be generated according to the order in which the data to be processed is obtained. Data that meets the expectations will then be stratified from the pending list for verification by S12.

[0062] It should be noted that the validation of the data to be processed includes:

[0063] Obtain the unique code generated when the business party registers;

[0064] The data to be processed is verified based on the unique code and the verification token contained in the data to be processed; the verification token is generated by the business party according to a preset encryption method when uploading the dataset.

[0065] In practice, before starting the automatic upload task, the validity of the S11 layered data is asynchronously verified using methods such as data encryption. This mainly includes:

[0066] Before a business unit integrates the module supported by this method, it will register through the registration service of this module to obtain a unique code (including APPID and APPSECRET). When configuring the service of this module, the business unit needs to pass the unique code to this module. Before each upload, this module will verify the unique code with the server to confirm the identity of the business unit.

[0067] This module will also pre-agree with the business side on the chosen encryption method, such as MD5 or RSA. When the business side sends in target data, it will encrypt it using this method to obtain a verification token for this upload. Upon receiving the upload request, this module will verify the validity of the verification token. If the verification tokens match, the verification is considered successful, and the task will be added to the pending upload list; if the verification tokens do not match, the verification is considered unsuccessful, the data will be considered to have been tampered with by a third party, and the upload request will be ignored.

[0068] It should be noted that in this embodiment, the data to be processed is divided into blocks, including:

[0069] The data to be processed is divided into blocks according to the upload granularity preset by the business party.

[0070] It should be noted that before the upload task is executed, the data to be processed needs to be divided into blocks according to the upload granularity preset by the business side.

[0071] It should be noted that the data to be uploaded will be uploaded according to the preset upload configuration, including:

[0072] Create a scheduled upload task based on the start time node set by the business party and the custom time step;

[0073] When the start time is reached, a child thread is created to execute the timed upload task.

[0074] Monitor the number of child threads created and clean up any idle child threads.

[0075] It should be noted that in this embodiment, a scheduled task will be created based on the start time node set by the business party and a custom time step. To improve resource utilization and program execution efficiency, a sub-thread will be created to execute the upload task. Since thread creation will occupy some space and thread scheduling will also incur some time overhead, this embodiment will monitor the number of threads created and clean up redundant threads at appropriate times to reduce the processor's overhead in thread scheduling.

[0076] It should be noted that in this embodiment, common problems such as data transfer and synchronization control in multithreaded environments can be solved by using thread locks and other methods.

[0077] It should be noted that, referring to Figure 2 The methods also include:

[0078] S16: When an upload fails, record the number of upload failures and determine whether the current number of upload failures is greater than a preset threshold;

[0079] If the value exceeds the preset threshold, the local data corresponding to the data to be uploaded will be cleared, and an error message will be sent back to the business side.

[0080] If the data is not greater than the preset threshold, the data to be uploaded will be generated as local data to create an upload failure dataset.

[0081] It should be noted that, referring to Figure 2 The methods also include:

[0082] If the verification fails, the local data corresponding to the data to be uploaded will be cleared, and an error message will be sent back to the business side.

[0083] It's important to note that when data upload fails, and the current number of failures is less than a preset threshold, it means there's still a chance the data can be uploaded successfully, and further attempts are needed. However, if the current number of failures exceeds the preset threshold, it means the data has already failed to upload multiple times and is almost impossible to upload successfully. In this case, the local data corresponding to the data to be uploaded is cleared, and an error message is sent back to the business logic.

[0084] It should be noted that data awaiting upload that fails verification may have been tampered with by a third party and needs to be cleared directly, with an error message sent back to the business side.

[0085] In practice, it is necessary to call back the corresponding error information according to the different data types to be uploaded, and to optionally display error prompts according to the user's configuration.

[0086] It should be noted that in this embodiment, when the data upload is successful, the local data corresponding to the uploaded data is cleared to prevent secondary uploads from causing server pressure or contaminating server data.

[0087] It should be noted that the method for automatically uploading local data from the mobile device to the server in this embodiment requires pre-configuration before implementation. Specifically:

[0088] Reference Figure 3 The methods also include:

[0089] S21: Register and bind the application on the business side's mobile device, initialize the application configuration items, and inject the interface.

[0090] In practice, the method for automatically uploading local data from the mobile device to the server in this embodiment uses an automatic upload module as a carrier. During the development process, the automatic upload module encapsulated in this embodiment is used to register and bind the application, initialize configuration items, inject APIs, etc.

[0091] It should be noted that the automatic upload module encapsulated in this embodiment includes, but is not limited to, initialization components, loading components, and persistence components.

[0092] Reference Figure 3 The methods also include:

[0093] S22: Receive the uploaded configuration information entered by the business party;

[0094] S23: Configure the upload based on the upload configuration information; the upload configuration should include at least: business version number, automatic upload switch, upload time step, batch upload limit, expiration data cleanup interval and local data limit size.

[0095] It should be noted that after the automatic upload module is integrated into the application, the upload configuration of the automatic upload module needs to be configured within the application.

[0096] In practice, the data structure and field names to be parsed can be determined in conjunction with the business version number and the server. When the business upgrades the data structure, this module does not need to be configured additionally. The server can automatically perform the corresponding compatibility processing based on the business version number, preventing problems such as the server being unable to parse the data or causing crashes after the business modifies the data structure on its own.

[0097] The purpose of opening the interface for the automatic upload switch is to allow business users to flexibly choose the configuration according to their own needs.

[0098] Business users can control the upload frequency by passing in a custom time step. The time when the business user first starts this module is persisted to the local machine, which is the initial time by default. When the time is the initial time and a multiple of the time step, the upload task is automatically triggered.

[0099] Due to limitations in mobile device performance and network conditions, this module will impose limits on the size of each uploaded data packet. Furthermore, considering that application activity is determined by user habits, this module will also handle expired data. When data expires or exceeds the maximum limit, this module will automatically trigger a cleanup process.

[0100] Reference Figure 3 The methods also include:

[0101] S24: During a cold start, retrieve invalid data from the local data and clean it up;

[0102] Retrieve invalid data, including:

[0103] Expired data in the local data is retrieved as invalid data based on the pre-configured data validity period;

[0104] Data with a version number lower than the pre-configured version number in the local data is considered invalid.

[0105] When the size of local data exceeds the pre-configured local data limit, the excess portion will be treated as invalid data according to the storage time order of the local data.

[0106] It should be noted that, in this embodiment, considering the performance of the mobile device and the validity period of data, invalid data in the local data is retrieved and cleaned up during cold start. The determination of invalid data includes the following three methods:

[0107] First, relative time: the business can optionally input the validity period of the uploaded data. This module will judge the local data one by one and clean up the expired data. Second, version number: the business can choose to configure a version number. Data with a version number lower than that will be cleaned up. Third, data size limit: in order to reduce disk space usage, when the data exceeds the specified threshold, the data will be cleaned up in chronological order to reduce the use of redundant data. In practice, the default data size limit is 10% of the available space.

[0108] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0109] It should be noted that in the description of this application, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means at least two.

[0110] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this application pertain.

[0111] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0112] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0113] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0114] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0115] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0116] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for automatically uploading local data from a mobile device to a server, characterized in that, include: Obtain the data to be processed; The data to be processed is validated; Upon successful verification, the data to be processed is divided into blocks to obtain the data to be uploaded. The data to be uploaded is uploaded according to the preset upload configuration; Upon successful upload, the local data corresponding to the uploaded data will be cleared. The method further includes: When an upload fails, record the number of upload failures and determine whether the current number of upload failures exceeds a preset threshold. If the value exceeds a preset threshold, the local data corresponding to the data to be uploaded will be cleared, and an error message will be sent back to the business side. If the data is not greater than the preset threshold, the data to be uploaded will be used as local data to generate an upload failure dataset. Obtain the data to be processed, including: The status of retrieving local data confirms the range of uploaded data. If the local data contains a dataset of failed uploads, the data to be processed will be obtained first from the dataset of failed uploads, and then from the dataset uploaded by the business side. Generate a list of data to be processed according to the order in which the data was acquired; The verification of the data to be processed includes: Obtain the unique code generated when the business party registers; The data to be processed is verified based on the unique code and the verification token contained in the data to be processed; wherein the verification token is generated by the business party according to a preset encryption method when uploading the dataset.

2. The method according to claim 1, characterized in that, The method further includes: If the verification fails, the local data corresponding to the data to be uploaded will be cleared, and an error message will be sent back to the business side.

3. The method according to claim 1, characterized in that, The data to be processed is divided into blocks, including: The data to be processed is divided into blocks according to the upload granularity preset by the business party.

4. The method according to claim 1, characterized in that, The data to be uploaded is uploaded according to the preset upload configuration, including: Create a scheduled upload task based on the start time node set by the business party and the custom time step; When the start time node is reached, a sub-thread is created to execute the timed upload task; Monitor the number of child threads created and clean up any idle child threads.

5. The method according to claim 1, characterized in that, The method further includes: On the business side's mobile device, the application is registered and bound, application configuration items are initialized, and the interface is injected.

6. The method according to claim 1, characterized in that, The method further includes: Receive uploaded configuration information entered by the business party; The upload configuration is performed according to the upload configuration information; the upload configuration includes at least: business version number, automatic upload switch, upload time step, batch upload limit, expired data cleanup time interval and local data limit size.

7. The method according to claim 6, characterized in that, The method further includes: During a cold start, invalid data in the local database is retrieved and cleaned up. The search for invalid data includes: Expired data in the local data is retrieved as invalid data based on the pre-configured data validity period; Data with a version number lower than the pre-configured version number in the local data is considered invalid. When the size of local data exceeds the pre-configured local data limit, the excess portion will be treated as invalid data according to the storage time order of the local data.

Images