Method and apparatus for updating software toolkit

Abstract

The application provides an updating method and device of a software toolkit. The method comprises the following steps: sending a software toolkit list to a client; receiving an updating request of the client; wherein the updating request carries a target name and a target version number selected based on the software toolkit list; querying a baseline version matched with the target name and the target version number, and querying a target branch version matched with the type of the client in at least one branch version associated with the baseline version; wherein different branch versions correspond to different types of the client; and sending the software toolkit of the target branch version to the client; wherein the software toolkit of the target branch version is used to replace the software toolkit of a historical version of the target name in the client. Through the application, targeted and efficient updating of the version of the software toolkit can be realized.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a method and apparatus for updating a software toolkit. Background Technology

[0002] With the rapid development of the Internet, especially the mobile Internet, the update speed of software toolkits in various applications is also increasing.

[0003] Due to the rapid pace of version updates, in related technologies, the updated versions of software toolkits developed by developers are uniform updates for all users, making it impossible to achieve targeted and efficient updates for specific software toolkit versions.

[0004] There is currently no effective technical solution for how to achieve targeted and efficient updates to software toolkit versions. Summary of the Invention

[0005] This application provides a method, apparatus, computer-readable storage medium, and computer program product for updating a software toolkit, which can achieve targeted and efficient updates to the version of the software toolkit.

[0006] The technical solution of this application embodiment is implemented as follows:

[0007] This application provides a method for updating a software toolkit, including:

[0008] Send a list of software toolkits to the client; wherein the list of software toolkits includes the name of each software toolkit integrated in the client and at least one version number;

[0009] Receive the update request from the client; wherein the update request carries a target name and a target version number selected based on the software tool list;

[0010] Query the baseline version that matches the target name and the target version number, and query the target branch version that matches the client type in at least one branch version associated with the baseline version; wherein, different branch versions correspond to different types of the client;

[0011] Send the target branch version of the software toolkit to the client; wherein the target branch version of the software toolkit is used to replace the historical version of the software toolkit with the target name in the client.

[0012] This application provides a software toolkit updating device, comprising:

[0013] The first sending module is used to send a list of software toolkits to the client; wherein the list of software toolkits includes the name of each software toolkit integrated in the client and at least one version number;

[0014] A receiving module is configured to receive an update request from the client; wherein the update request carries a target name and a target version number selected based on the software tool list;

[0015] The query module is used to query a baseline version that matches the target name and the target version number, and to query a target branch version that matches the type of the client in at least one branch version associated with the baseline version; wherein different branch versions correspond to different types;

[0016] The second sending module is used to send the target branch version of the software toolkit to the client; wherein the target branch version of the software toolkit is used to replace the historical version of the software toolkit with the target name in the client.

[0017] In the above scheme, the query module is further configured to query the database based on the target name to obtain at least one array index corresponding to the target name; wherein, each array index includes a baseline version of the software toolkit of the target name, and the baseline versions included in different array indices have different version numbers; querying the at least one array index to find an array index that matches the target version number, and taking the baseline version included in the queried array index as the baseline version that matches the target name and the target version number.

[0018] In the above scheme, the query module is further used to parse the client update request to obtain the type of the client carried in the update request; take the array index of the baseline version that matches the target name and the target version number as the target array index, and compare each branch version included in the target array index with the type of the client to obtain the target branch version that matches the type of the client.

[0019] In the above scheme, the software toolkit update device further includes: a construction module, used to determine the version corresponding to each software toolkit based on each software toolkit integrated in the client; and to construct a list of software toolkits corresponding to the client based on the version corresponding to each software toolkit and the name of each software toolkit.

[0020] In the above scheme, the construction module is further configured to extract header files from the software toolkit initially submitted by the development device, and parse them to obtain the name and version number of the initially submitted software toolkit; construct a software toolkit list based on the name and version number of the initially submitted software toolkit; extract the corresponding header files from each subsequent software toolkit submitted by the development device, and parse them to obtain the name and updated version number of each submitted software toolkit; and sequentially write the updated version number of each submitted software toolkit into the list item of the corresponding name in the software toolkit list.

[0021] In the above scheme, the construction module is further configured to compare the name of the currently submitted software toolkit with the name of the previously submitted software toolkit; when the name of the currently submitted software toolkit exists in the name of the previously submitted software toolkit, the update version number of the currently submitted software toolkit is written into the list item with the same name as the currently submitted software toolkit; when the name of the currently submitted software toolkit does not exist in the name of the previously submitted software toolkit, a new list item with the name of the currently submitted software toolkit is created in the software toolkit list, and the update version number of the currently submitted software toolkit is written into the list item with the name of the currently submitted software toolkit.

[0022] In the above scheme, the software toolkit update device further includes: a dependency query module, used to determine at least one dependent software toolkit and its corresponding dependent version of the software toolkit of the baseline version based on the dependency information of the baseline version; and send the at least one dependent software toolkit of the dependent version to the client so that the client can perform the following process: replace the dependent software toolkit of the historical version in the client with the at least one dependent software toolkit of the dependent version.

[0023] In the above scheme, the dependency query module is further configured to determine, based on the dependency information of the baseline version, at least one dependent software toolkit that the software toolkit of the baseline version depends on; and to determine the corresponding dependency version based on the at least one dependent software toolkit that the software toolkit of the baseline version depends on; wherein, the dependency version is the lowest version that is depended on.

[0024] In the above scheme, the second sending module is further configured to query the storage address corresponding to the name and version number of the target branch version in the mapping relationship between the software toolkit list and the storage address; wherein, the mapping relationship includes the storage addresses of different names, different version numbers and corresponding software toolkits in the software toolkit list; download the software toolkit of the target branch version according to the queried storage address; and send the downloaded software toolkit of the target branch version to the client.

[0025] This application provides a software toolkit updating device, comprising:

[0026] Memory, used to store executable instructions;

[0027] The processor, when executing executable instructions stored in the memory, implements the software toolkit update method provided in the embodiments of this application.

[0028] This application provides a computer-readable storage medium storing executable instructions for implementing the software toolkit update method provided in this application when executed by a processor.

[0029] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the software toolkit update method described above in this application.

[0030] The embodiments of this application have the following beneficial effects:

[0031] Version management of different versions of software toolkits is achieved through a software toolkit list, effectively enhancing the efficiency of software toolkit version management. Simultaneously, it receives the target name and target version number selected from the software toolkit list, queries the baseline version matching the target name and version number, and then determines the target branch version matching the type of the client sending the update request based on the branch version associated with the baseline version. By replacing the corresponding historical version of the software toolkit in the client with the software toolkit of the target branch version, targeted and efficient updates can be performed because the target branch version's software toolkit matches the client type. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the system architecture for updating the software toolkit provided in the embodiments of this application;

[0033] Figure 2 This is a schematic diagram of the structure of the software toolkit update device provided in the embodiments of this application;

[0034] Figures 3A-3E This is a flowchart illustrating the update method of the software toolkit provided in this application embodiment;

[0035] Figures 4A-4B This is a schematic diagram illustrating the principle of the software toolkit update method provided in the embodiments of this application;

[0036] Figures 5A-5C This is a schematic diagram illustrating the effect of the software toolkit update method provided in the embodiments of this application;

[0037] Figure 6 This is a schematic diagram of the interactive flow of the software toolkit update method provided in the embodiments of this application. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0039] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0040] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0041] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0042] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0043] 1) Software Development Kit (SDK): Also known as a software development kit, it is a collection of development tools used to build application software for specific software packages, software frameworks, hardware platforms, operating systems, etc. In a broad sense, it refers to a collection of related documents, examples and tools that assist in the development of a certain type of software.

[0044] 2) B-end (Business): refers to enterprise users, which are management platforms in Internet products. They are often based on the overall evaluation of solutions to a certain problem by multiple people at the enterprise level.

[0045] 3) C-end (Consumer): refers to individual consumer users or personal users. Its characteristics are personal decision-making, relatively emotional decision-making process, and small transaction amount.

[0046] 4) Client: Also known as user terminal, it refers to the program that provides local services to users in contrast to the server. Except for some applications that can only run locally, it is generally installed on ordinary client machines and needs to cooperate with the server to run. That is, there needs to be a corresponding server and service program in the network to provide the corresponding services. Thus, a specific communication connection needs to be established between the client and the server to ensure the normal operation of the application.

[0047] 5) Software Toolkit List: A list that represents the mapping between the name and the corresponding version number of each software toolkit integrated in the client. The software toolkit list can be displayed in the client's interface so that users can view the list and select from the names and version numbers in the list.

[0048] 6) Version number: Used to number different versions of software toolkits with the same name, so as to facilitate the management of different versions of software toolkits with the same name.

[0049] 7) Baseline version: A combination of software toolkits with the same name and version number. Multiple software toolkits in a baseline version have the same name and version number, but different branch version numbers.

[0050] 8) Branch Version: A branch version represents a client type that matches a certain client type. In the same baseline version of the software toolkit, different branch versions represent versions of the same baseline version number of the client type that match different client types.

[0051] 10) Dependency Information: Information that characterizes the functional dependencies between two different software toolkits. For example, a software toolkit with recognition capabilities (e.g., a software toolkit with card recognition capabilities) typically depends on a software toolkit with scanning capabilities (e.g., a software toolkit with a "scan" function) to fully realize its recognition function. Therefore, the dependency information of the software toolkit with recognition capabilities is the information of the software toolkit with scanning capabilities.

[0052] During the implementation of the embodiments of this application, the applicant discovered the following problems with the related technology:

[0053] In related technologies, software toolkit updates typically involve developers releasing updated versions uniformly on a designated platform, from which users download and install the newest version. However, due to the rapid pace of updates, the resulting uniform updates are available to all users, making it impossible to provide customized versions of the software toolkit to meet the individual needs of different users and client types.

[0054] Meanwhile, with the iteration of software toolkit versions, the number of versions of privately delivered software toolkits is increasing, consuming a significant amount of server capacity. Managing these versions is extremely difficult. Currently, there is no effective solution in the relevant technologies to address the version management difficulties encountered during the release and update of software toolkits in private deployments.

[0055] This application provides a method, apparatus, device, computer-readable storage medium, and computer program product for updating a software toolkit, enabling targeted and efficient updates to the software toolkit version. The following describes exemplary applications of the software toolkit updating device provided in this application. This updating device can be implemented as various types of user terminals such as laptops, tablets, desktop computers, set-top boxes, mobile devices (e.g., mobile phones, portable music players, personal digital assistants, dedicated messaging devices, portable gaming devices), smart voice interaction devices, smart home appliances, and in-vehicle terminals, or it can be implemented as a server. The following describes exemplary applications when the device is implemented as a server.

[0056] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of the software toolkit update system 100 provided in the embodiments of this application. In order to support the update application of a software toolkit, the terminal (terminal 400 is shown as an example) connects to the server 200 through the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0057] Terminal 400 runs client 410, which is displayed on graphical interface 410-1 (graphical interface 410-1 is shown as an example). Terminal 400 and server 200 are connected to each other via wired or wireless network.

[0058] In some embodiments, server 200 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Terminal 400 may be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, etc., but is not limited thereto. Terminals and servers can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0059] In some embodiments, server 200 sends a list of software toolkits to client 410 in terminal 400. After receiving the list, client 410 displays the list through graphical interface 410-1. In response to a user's (e.g., a user using client 410 or a developer / tester of client 410) selection operation on the list of software toolkits, client 410 sends the name and version of the selected software toolkit to server 200. After receiving the name and version of the selected software toolkit, server 200 sends the corresponding name and version of the software toolkit to client 410 in terminal 400.

[0060] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the update server 200 of the software toolkit provided in this application embodiment. Figure 2 The server 200 shown includes at least one processor 410, memory 450, and at least one network interface 420. The various components of server 200 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 440.

[0061] The processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0062] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 410.

[0063] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0064] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0065] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0066] The network communication module 452 is used to reach other computing devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.

[0067] In some embodiments, the software toolkit update device provided in this application can be implemented in software. Figure 2 An update device 455 for a software toolkit stored in memory 450 is shown. This toolkit can be software in the form of programs and plug-ins, and includes the following software modules: a first sending module 4551, a receiving module 4552, a query module 4553, and a second sending module 4554. These modules are logically linked and can therefore be arbitrarily combined or further divided according to their implemented functions. The functions of each module will be described below.

[0068] In some embodiments, the terminal or server can implement the software toolkit update method provided in this application by running a computer program. For example, the computer program can be a native program or software module in the operating system; for instance, it can be a native application (APP), that is, a program that needs to be installed in the operating system to run. In summary, the above-mentioned computer program can be any form of application, module, or plugin.

[0069] The method for updating the software toolkit provided in this application will be described in conjunction with exemplary applications and implementations of the server provided in the embodiments of this application.

[0070] See Figure 3A , Figure 3A This is a flowchart illustrating the update method of the software toolkit provided in this application embodiment, which uses the server provided in this application embodiment as the execution subject to update the software toolkit. Figure 3A Steps 101 to 104 are described below.

[0071] In step 101, a list of software toolkits is sent to the client; wherein the list of software toolkits includes the name of each software toolkit integrated in the client and at least one version number.

[0072] As an example, see Figure 4A , Figure 4A This is a schematic diagram illustrating the principle of the software toolkit update method provided in this application embodiment. The server sends a list of software toolkits to the client, including the name of each software toolkit integrated in the client and at least one version number. It is understood that the name and at least one version number of each software toolkit integrated in the client are list items in the software toolkit list.

[0073] As an example, see Figure 6 , Figure 6 This is a schematic diagram of the interaction flow of the software toolkit update method provided in this application embodiment. Server 200 sends a list of software toolkits to the client in terminal 400.

[0074] In some embodiments, see Figure 3B , Figure 3B This is a flowchart illustrating the method for updating a software toolkit provided in this application embodiment. Before step 101, a software toolkit list is constructed by executing steps 105 to 106.

[0075] In step 105, based on each software toolkit integrated in the client, the version corresponding to each software toolkit is determined.

[0076] As an example, a financial client integrates four software toolkits (e.g., software toolkit A, software toolkit B, software toolkit C, and software toolkit D). The server can determine the corresponding versions of software toolkit A, software toolkit B, software toolkit C, and software toolkit D. For example, the versions corresponding to software toolkit A are software toolkit A1.0, software toolkit A2.0, and software toolkit A3.0.

[0077] As an example, see Figure 4A The software toolkit management platform and plugin platform run on servers, which can be the same server or different servers. Clients can be of different types; for example, clients can be iOS clients (iOS client), Android clients (Android client), or mini-program clients (mini-program client).

[0078] The software toolkit management platform running on the server can determine the version of each software toolkit based on the software toolkit integrated in the client (iOS, Android, and mini-program).

[0079] In step 106, a list of software toolkits for the corresponding client is constructed based on the version and name of each software toolkit.

[0080] As an example, a list of software toolkits for a financial client is constructed by considering the versions (e.g., for software toolkit A, there are versions A1.0, A2.0, and A3.0) and the names (e.g., the name of software toolkit A is A) of the software toolkits A integrated into a financial client.

[0081] As an example, see Figure 4A The software toolkit management platform running on the server can build a list of software toolkits for each client based on the version and name of each software toolkit.

[0082] In some embodiments, see Figure 3C , Figure 3C This is a flowchart illustrating the update method for the software toolkit provided in this application embodiment. Figure 3C Step 106 shown can be implemented through steps 1061 to 1064, which will be explained below.

[0083] In step 1061, the header file is extracted from the software toolkit submitted for the first time by the development device and parsed to obtain the name and version number of the software toolkit submitted for the first time.

[0084] In some embodiments, a header file is a file added to the software toolkit to record descriptive information about the software toolkit.

[0085] As an example, see Figure 4A The software toolkit management platform extracts header files from the submitted software toolkits and parses them to obtain the name and version number of the first submitted software toolkit.

[0086] In some embodiments, the header files in the software toolkit are pre-configured by the developer on the development device. The header files in the software toolkit include relevant information about the software toolkit, including: the name of the software toolkit (SDK-name), the version number of the software toolkit (SDK-version), the applicable platform number of the software toolkit (Platform-id), the timestamp of the compiled software toolkit (Timestamp), the description information of the software toolkit (Desc-info), the dependency information of the software toolkit (Dependencies), and the storage address (URL) of the software toolkit.

[0087] In this way, by extracting the header file from the submitted software toolkit and parsing the header file, the name (SDK-name) and version (SDK-version) of the software toolkit can be obtained from the header file. This makes it easier to build a list of software toolkits based on the obtained name (SDK-name) and version (SDK-version) of the software toolkit in the header file.

[0088] In step 1062, a list of software toolkits is constructed based on the name and version number of the software toolkit submitted for the first time.

[0089] As an example, see Figure 4A The software toolkit management platform constructs a list of software toolkits based on the name (SDK-name) and version number (SDK-version) of the first submitted software toolkit. In other words, the list items include the name and version number of the first submitted software toolkit. For example, if the first submitted software toolkit is software toolkit A, the software toolkit management platform constructs the list based on the name A and version number 1.0 of the first submitted software toolkit.

[0090] In step 1063, the corresponding header files are extracted from each subsequent software toolkit submitted by the development device and parsed to obtain the name and update version number of each submitted software toolkit.

[0091] As an example, see Figure 4A The system extracts the corresponding header files from each software toolkit submitted to the software toolkit management platform by the development device, and parses the header files to obtain the name and update version number of each submitted software toolkit. For example, it extracts the corresponding header files from software toolkit A submitted to the software toolkit management platform by the development device, and parses them to obtain the name B and update version number 2.0 of software toolkit A.

[0092] In step 1064, the update version number of each submitted software toolkit is sequentially written into the list item of the corresponding name in the software toolkit list.

[0093] As an example, see Figure 4A The updated version number 2.0 of the submitted software toolkit A is written into the list item of the name A in the software toolkit list. It can be understood that at this time, the list item of the name A in the software toolkit list has the initial version number 1.0 and the updated version number 2.0.

[0094] In some embodiments, step 1064 above can be implemented as follows: For the name and update version number of the currently submitted software toolkit, perform the following processing: compare the name of the currently submitted software toolkit with the name of the previously submitted software toolkit; if the name of the currently submitted software toolkit exists in the name of the previously submitted software toolkit, write the update version number of the currently submitted software toolkit into a list item with the same name as the currently submitted software toolkit; if the name of the currently submitted software toolkit does not exist in the name of the previously submitted software toolkit, create a new list item for the name of the currently submitted software toolkit in the software toolkit list, and write the update version number of the currently submitted software toolkit into the list item for the name of the currently submitted software toolkit.

[0095] As an example, comparing the name of the currently submitted software toolkit with the name of the previously submitted software toolkit allows us to determine whether they are different versions of the same software toolkit. For instance, if the currently submitted software toolkit is named A (i.e., software tool A), and the previously submitted software toolkit was named B (i.e., software toolkit B), then the names of the currently submitted and previously submitted software toolkits are different. Conversely, if the currently submitted software toolkit is named A (i.e., software tool A), and the previously submitted software toolkit was named A (i.e., software toolkit A), then the names of the currently submitted and previously submitted software toolkits are the same.

[0096] As an example, if the name of the currently submitted software toolkit is present in the name of the previously submitted software toolkit, that is, if the name of the currently submitted software toolkit is the same as the name of the previously submitted software toolkit, it means that the currently submitted software toolkit and the previously submitted software toolkit belong to different versions of the same software toolkit. In other words, if there is a list item in the software toolkit list with the same name as the currently submitted software toolkit, then the update version number of the currently submitted software toolkit can be written into the list item of the list of software toolkits with the same name as the currently submitted software toolkit.

[0097] As an example, if the name of the currently submitted software toolkit does not exist in the name of the previously submitted software toolkit (i.e., the name A of the currently submitted software toolkit is different from the name B of the previously submitted software toolkit), it means that the currently submitted software toolkit A and the previously submitted software toolkit B are software toolkits with different names and versions. In other words, there is no list item in the software toolkit list with the same name A as the currently submitted software toolkit. Therefore, it is necessary to create a list item with the name A of the currently submitted software toolkit in the software toolkit list and write the updated version number 1.0 of the currently submitted software toolkit into the list item with the name A of the currently submitted software toolkit.

[0098] In this way, by sequentially writing the update version number of each submitted software toolkit into the list item of the corresponding name in the software toolkit list, a software toolkit list is constructed, which makes version management of software toolkits more convenient.

[0099] In step 102, an update request is received from the client; wherein the update request carries the target name and target version number selected based on the software tool table list.

[0100] In some embodiments, the target name is the name of the software toolkit to be updated in the client, and the target version number is the version of the software toolkit to be updated under the target name.

[0101] As an example, see Figure 4A The client (iOS, Android, or mini-program) sends an update request to the plugin platform running on the server. The plugin platform on the server receives the update request from the client. The update request carries the target name and target version number selected by the user based on the software toolkit list. In other words, the plugin platform running on the server receives the target name and target version number selected based on the software toolkit list.

[0102] As an example, see Figure 6 The client in terminal 400 sends an update request to server 200, and server 200 receives the update request sent by the client in terminal 400.

[0103] In step 103, a baseline version matching the target name and target version number is queried, and a target branch version matching the client type is queried in at least one branch version associated with the baseline version; wherein different branch versions correspond to different client types.

[0104] As an example, see Figure 4A The plugin platform running on the server queries the baseline version that matches the target name and target version number. For example, if the target name selected based on the software toolkit list is A and the target version number is 1.0, the baseline version that the plugin platform running on the server queries that matches the target name A and the target version number 1.0 can be version 1.0.

[0105] As an example, see Figure 6 Server 200 queries a baseline version that matches the target name and target version number, and in at least one branch version associated with the baseline version, queries a target branch version that matches the client type.

[0106] In some embodiments, see Figure 3D , Figure 3D This is a flowchart illustrating the update method for the software toolkit provided in this application embodiment. Figure 3D The query in step 103 that matches the baseline version with the target name and target version number can be achieved through steps 1031 to 1032, which will be explained below.

[0107] In step 1031, the database is queried based on the target name to obtain at least one array index corresponding to the target name; wherein each array index includes a baseline version of the software toolkit of the target name, and the baseline versions included in different array indices have different version numbers.

[0108] In some embodiments, the database may be a database deployed on the server described above, or a database deployed independently of the server. The database stores a mapping relationship between target names and array indices. By querying the database based on the target name, the mapping relationship between target names and array indices is retrieved, yielding at least one array index corresponding to the target name.

[0109] As an example, given a target name A, the database is queried to find the mapping between target names and array indices, resulting in array indices {A1.0, A1.1, A1.2, A1.3} corresponding to target name A. Each array index includes a baseline version of the software toolkit for the target name. Array index A1.0 includes baseline version 1.0 of the software toolkit for target name A, array index A1.1 includes baseline version 1.1 of the software toolkit for target name A, and array index A1.3 includes baseline version 1.3 of the software toolkit for target name A. Furthermore, the baseline versions included by different array indices have different version numbers. For example, array index A1.0 includes a baseline version with version number 1.0, and array index A1.1 includes a baseline version with version number 1.1; that is, array index A1.0 and array index A1.1 include baseline versions with different version numbers.

[0110] In step 1032, at least one array index is queried to find an array index that matches the target version number, and the baseline version included in the queried array index is used as the baseline version that matches the target name and the target version number.

[0111] As an example, if the target version number is 1.1, then in at least one array index {A1.0, A1.1, A1.2, A1.3}, we search for the array index that matches the target version number 1.1. The array index that matches the target version number 1.1 is A1.1. The baseline version 1.1 included in the searched array index is taken as the baseline version that matches the target name and the target version number.

[0112] In some embodiments, step 1032 above can be implemented in the following way: parsing the client update request to obtain the client type carried in the update request; taking the array index of the baseline version that matches the target name and target version number as the target array index; comparing each branch version included in the target array index with the client type to obtain the target branch version that matches the client type.

[0113] Each array index also includes at least one branch version belonging to the baseline version, each branch version includes the same version number as the baseline version, and each branch version also includes its own corresponding client type.

[0114] As an example, see Figure 4A The plugin platform running on the server parses the received client update requests to determine the client type carried in the update request. Since the update request includes the target name and target version number selected by the user based on the software toolkit list, and the client also includes a client type tag in the update request when sending it, the received client update request can be parsed to obtain the client type carried in the update request.

[0115] As an example, each array index also includes at least one branch version belonging to the baseline version. Array index A1.1 also includes at least one branch version {A1.1-a, A1.1-b, A1.1-c} belonging to the baseline version 1.1. It can be seen that each branch version includes the same version number 1.1 as the baseline version 1.1, and each branch version also includes its corresponding types a, b, and c for different clients.

[0116] As an example, assuming the client type is b, each branch version {A1.1-a, A1.1-b, A1.1-c} included in the target array index is compared with the client type b to obtain the target branch version A1.1-b that matches the client type b. The target branch version A1.1-b includes the baseline version number 1.1 and the client type b. That is, the branch version includes the baseline version number and the client type.

[0117] In this way, by querying the baseline version that matches the target name and target version number, the software toolkit of the baseline version selected by the user is determined. Then, by querying the software toolkit of the target branch version that matches the client type from at least one branch version associated with the baseline version, the software toolkit of the target branch version that is determined is both compatible with the client type and is the version selected by the user, thereby better meeting the user's personalized needs.

[0118] In some embodiments, after querying the baseline version that matches the target name and target version number in step 103 above, the dependent software toolkits are determined as follows: based on the dependency information of the baseline version, at least one dependent software toolkit and its corresponding dependent version of the software toolkit of the baseline version are determined. At least one dependent software toolkit of the dependent version is sent to the client so that the client can perform the following process: replace the dependent software toolkit of the historical version in the client with at least one dependent software toolkit of the dependent version.

[0119] In some embodiments, dependency information is obtained by parsing the header files in the baseline version of the software toolkit to obtain the baseline version's dependency information. The dependency information includes the minimum required versions of the dependent software toolskits and their names.

[0120] In some embodiments, before determining at least one dependent software toolkit and its corresponding dependent version of the software toolkit of the baseline version based on the dependency information of the baseline version, the dependency information of the baseline version can be determined by parsing the header file of the software toolkit of the baseline version to obtain the dependency information of the software toolkit of the baseline version.

[0121] As an example, the header file of the baseline version of a software toolkit includes its dependencies. These dependencies represent information about other software toolkits that the baseline version depends on. Assuming the baseline version is a toolkit with identification capabilities, and scanning functionality is often fundamental to identification, the toolkit with identification capabilities often relies on the toolkit with scanning capabilities to implement its functionality. Therefore, the dependency information of the toolkit with identification capabilities includes information about the toolkit with scanning capabilities. The toolkit that the toolkit with identification capabilities depends on the toolkit with scanning capabilities.

[0122] As an example, see Figure 4A The plugin platform can send at least one dependency software package of a dependency version (e.g., the required initial dependency version (minimum dependency version) or the final dependency version (maximum dependency version)) to the client (iOS, Android, or mini-program). The client (iOS, Android, or mini-program) replaces the historical version of the dependency software package in the client with at least one dependency software package of the dependency version (e.g., minimum dependency version).

[0123] In this way, by determining at least one dependent software toolkit and its corresponding dependent version based on the dependency information of the baseline version, the dependent software toolkit is sent to the client, thereby installing and replacing the historical version of the software toolkit in the client. While installing and replacing the software toolkit selected by the user, the dependent software toolkits that depend on the functions of the software toolkit selected by the user are also installed and replaced, so that the updated software toolkit selected by the user can better perform its functions, effectively ensuring the functionality of the updated software toolkit and better meeting the user's functional needs for updating the software toolkit.

[0124] In some embodiments, the above-mentioned determination of at least one dependent software toolkit and its corresponding dependent version of the software toolkit of the baseline version based on the dependency information of the baseline version can be achieved in the following way: determining at least one dependent software toolkit that the software toolkit of the baseline version depends on based on the dependency information of the baseline version; determining the corresponding dependent version based on at least one dependent software toolkit that the software toolkit of the baseline version depends on; wherein, the dependent version is the lowest version that is depended on.

[0125] As an example, see Figure 4A Based on the dependency information of baseline version 1.1, the plugin platform determines at least one dependent software toolkit that software toolkit A of baseline version 1.1 depends on. Based on the at least one dependent software toolkit that software toolkit A of baseline version 1.1 depends on, the plugin platform determines the dependency version corresponding to the at least one dependent software toolkit that software toolkit A of baseline version 1.1 depends on. The version number of the corresponding dependency version can be 1.1, 1.2, 1.3, 1.4, etc., and the dependency version can be the lowest version 1.1 that is depended on.

[0126] In this way, by identifying at least one dependent software toolkit and its corresponding version for the baseline version of the software toolkit, the dependent software toolkit of the historical version in the client is replaced. Thus, while updating the software toolkit of the target branch version, the dependent software toolkit of the historical version in the client is updated simultaneously, thereby comprehensively updating the corresponding functions in the client.

[0127] In step 104, the software toolkit of the target branch version is sent to the client; wherein the software toolkit of the target branch version is used to replace the software toolkit of the historical version with the target name in the client.

[0128] As an example, see Figure 4AThe plugin platform running on the server sends the target branch version of the software toolkit to the client (iOS, Android, and mini-program). The target branch version of the software toolkit is used to replace the historical version of the software toolkit with the target name in the client (iOS, Android, and mini-program).

[0129] As an example, see Figure 6 Server 200 sends the target branch version of the software toolkit to the client in terminal 400, wherein the target branch version of the software toolkit is used to replace the historical version of the software toolkit with the target name in the client in terminal 400.

[0130] In some embodiments, see Figure 3D , Figure 3D This is a flowchart illustrating the update method for the software toolkit provided in this application embodiment. Figure 3D Step 104 shown can be implemented through steps 1041 to 1043, which will be explained below.

[0131] In step 1041, the storage address corresponding to the name and version number of the target branch version is queried from the mapping relationship between the software toolkit list and the storage address; wherein, the mapping relationship includes the storage address of the software toolkit with different names and different version numbers in the software toolkit list.

[0132] In some embodiments, the mapping between the software toolkit list and the storage address is formed synchronously with the software toolkit list.

[0133] As an example, see Figure 4A The plugin platform queries the storage address (URL) corresponding to the name and version number of the target branch version within the mapping relationship between the software toolkit list and storage addresses (URLs). The mapping relationship represents the association between different names and version numbers included in the software toolkit list and the corresponding storage addresses of the software toolkits.

[0134] In step 1042, the target branch version of the software toolkit is downloaded based on the queried storage address.

[0135] As an example, see Figure 4A The plugin platform downloads the target branch version of the software toolkit from the software toolkit management platform based on the queried storage address.

[0136] For example, the queried storage address represents the storage location of the target branch version of the software toolkit in the software toolkit management platform. Once the storage location of the target branch version of the software toolkit in the software toolkit management platform is determined, the plugin platform can download the target branch version of the software toolkit from the corresponding storage location in the software toolkit management platform.

[0137] In step 1043, the downloaded target branch version of the software toolkit is sent to the client.

[0138] As an example, see Figure 4A The plugin platform sends the downloaded target branch version of the software toolkit to the client (iOS, Android, or mini-program).

[0139] In this way, the software toolkit downloaded and selected by the user is sent to the client through the plugin platform. Moreover, the software toolkit of the target branch version is adapted to the user's type, thereby meeting the personalized customization needs of the client to update the software toolkit.

[0140] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0141] This application embodiment can be applied in various scenarios, such as instant messaging apps, financial apps, and other types of applications, which typically require the integration of software toolkits with different functionalities. For example, when a user uses a financial app and needs to view the geographical distribution of financial institutions, the app often needs to integrate a software toolkit with map functionality to meet the user's needs. Because financial apps require continuous updates to the map-enabled software toolkit as branch locations change and new branches are established, users need to view real-time and accurate branch distribution information. Typically, when updating the map-enabled software toolkit, financial apps need to download the updated version from the platform provided by the map-enabled software toolkit developer to update previous versions of the map-enabled software toolkit within the financial app. In this situation, users in different cities often have different needs for software toolkits with map functions when using financial apps (for example, users in city A often only need maps of city A, while users in city B often only need maps of city B). Therefore, the software toolkit update method provided in this application embodiment can intelligently provide users with software toolkits that meet their personalized needs, catering to different user requirements.

[0142] In some embodiments, when delivering a software toolkit to B-end users, the provided toolkit includes basic capabilities for their use. As the B-end users' mobile client applications undergo continuous iteration and upgrades, the provided software toolkit will also be upgraded accordingly. As the number of B-end users increases, their customization needs also increase, leading to more frequent version updates of the software toolkit.

[0143] In some embodiments, see Figure 4B , Figure 4B This is a schematic diagram illustrating the principle of the software toolkit update method provided in this application embodiment. The SDK package management platform (i.e., the software toolkit management platform mentioned above) and the TMF plugin platform (i.e., the plugin platform mentioned above) run on a backend server (i.e., the server mentioned above), which can be the same server or different servers. The frontend (client) can have different types of clients. For example, the frontend (client) can be an iOS client (i.e., iOS client), an Android client (Android client), or a mini-program client (mini-program client). After the updated version of the software toolkit (SDK) is uploaded to the distributed version control system (Git), Git compiles the code of the updated version of the software toolkit (SDK) and sends the compiled updated version of the software toolkit (SDK) package to the software toolkit management platform (SDK package management platform). The software toolkit management platform parses the header file (Collocation) of the incoming updated version of the software toolkit (SDK). The header file contains relevant information about the software toolkit (SDK), including: the name of the software toolkit (SDK-name), the version number of the software toolkit (SDK-version), the applicable platform number of the software toolkit (Platform-id), the timestamp of the software toolkit after compilation (Timestamp), the description information of the software toolkit (Desc-info), the dependencies of the software toolkit (Dependencies), and the storage address (URL) of the software toolkit. Meanwhile, by manually compiling the software and performing client-side performance analysis (Quick Application Performance Monitor, QAPM), a corresponding software toolkit can be generated and uploaded to the software toolkit management platform (SDK package management platform).

[0144] In some embodiments, see Figure 4BThe software package management platform parses the header files (collocations) of incoming updated software package (SDK) versions and categorizes them by their SDK names (SDK-name), meaning that software packages with the same name belong to different versions of the same SDK. An array is created based on the software package initially submitted to the platform, specifically based on its SDK name and version number. The dependency information of each software package is indexed to the lowest versions of other software packages that the current software package depends on. The software package management platform is a server-based management platform used to store the binary packages of various versions of the software packages.

[0145] In some embodiments, see Figure 4B The TMF plugin platform (the plugin platform mentioned above) is used to parse, store, and obtain header files (collocations), and send the received list of software toolkits to the application running on the client (iOS, Android, and mini-program). The application running on the client creates a LoadCenter to load the list of software toolkits. Different users use different branch versions corresponding to the baseline version. For example, for baseline version 1.0, users A, B, C, and D could have branch version numbers of SDK-A-1.0, SDK-B-1.0, SDK-C-1.0, and SDK-D-1.0. For baseline version 1.1, users A, B, C, and D could have branch version numbers of SDK-A-1.2, SDK-B-1.2, SDK-C-1.2, and SDK-D-1.2.

[0146] In some embodiments, see Figure 4B When a user performs a download operation on an application running on the client (iOS, Android, or WeChat Mini Program), a serial queue is created in the application's LoadCenter. The TMF plugin platform downloads the specified version of the software toolkit from the software toolkit management platform via the software toolkit's storage address (URL), along with the corresponding dependent software toolkits, and sends them to the application running on the client (iOS, Android, or WeChat Mini Program). The application running on the client (iOS, Android, or WeChat Mini Program) downloads the specified version of the software toolkit and the corresponding dependent software toolkits. Once the download is successful, it replaces the software toolkit with the same name stored locally on the client.

[0147] In some embodiments, when a user needs to update a software toolkit, the application running on the client (iOS, Android, or mini-program) responds to the user's switching operation on the software toolkit list, switching between different versions for the user to choose from for updating. In response to the user's selection operation on the software toolkit list, the application running on the client sends an update request to obtain the branch version of the software toolkit that is compatible with its own type.

[0148] In some embodiments, see Figure 3E , Figure 3E This is a flowchart illustrating the method for updating the software toolkit provided in this application embodiment.

[0149] In step 301, the software package management platform on the server parses the relevant information of the software package (SDK) in the header file (Collocation). The header file contains information about the software package (SDK), including: the software package name (SDK-name), the software package version number (SDK-version), the applicable platform number (Platform-id), the compiled timestamp (Timestamp), the software package description information (Desc-info), the software package dependencies (Dependencies), and the software package storage address (URL). (This is equivalent to the collocation file in the plugin platform parsing the project).

[0150] In step 302, the software toolkit management platform on the server draws (creates) a software toolkit list. Specifically, SDK packages are categorized by their names (SDK-name), and an array is created based on the initially submitted software toolkits. The array is then sorted by version number (SDK-version) to generate the software toolkit list. The software toolkit management platform sends the created software toolkit list to the TMF plugin platform, which then transmits the received SDK list back to the terminal for display (i.e., drawing the SDK list).

[0151] In step 303, the application running on the client (iOS, Android, or mini-program) responds to the user's selection of a target software toolkit version from the software toolkit list by displaying the corresponding header file information, switching between different versions for selection and update, and generating a target software toolkit acquisition request. This request is then sent to the TMF plugin platform on the server (i.e., selecting a specific SDK).

[0152] In step 304, the TMF plugin platform on the server responds to the target software toolkit acquisition request. The TMF plugin platform retrieves the index of the array of baseline versions corresponding to the target software toolkit from the package management platform. This array of baseline versions includes multiple target SDKs of different types. For example, in baseline version 1.0, there are SDK-A-1.0, SDK-B-1.0, SDK-C-1.0, and SDK-D-1.0. In baseline version 1.2, there could be SDK-A-1.2, SDK-B-1.2, SDK-C-1.2, and SDK-D-1.2. Based on the index of the baseline version array (i.e., the array index), the TMF plugin platform (i.e., the plugin platform mentioned above) determines the target software toolkit that matches the client type corresponding to the target software toolkit acquisition request (i.e., the update request mentioned above). (This involves reading the array index from the package management platform).

[0153] In step 305, the target software toolkit that matches the client type corresponding to the target software toolkit acquisition request (i.e., the update request mentioned above) is sent to the application running on the client (iOS client, Android client, mini-program client) to perform the update.

[0154] In step 306, the application running on the client (iOS, Android, or mini-program) downloads (receives) the target software toolkit and its dependent software toolkits that match the client type corresponding to the target software toolkit acquisition request, sent back by the server (TMF plugin platform). (That is, downloading the minimum machine dependencies for the specified SDK version).

[0155] In this way, by downloading the target software toolkit and its dependent software toolkits that match the client type corresponding to the target software toolkit acquisition request, the dependent software toolkits can be updated synchronously with one click, thus significantly saving the time of updating software toolkits.

[0156] In step 307, the application running on the client (iOS, Android, or mini-program) replaces the local software toolkit on the terminal with the target software toolkit that matches the client type of the received target software toolkit acquisition request (i.e., the update request mentioned above), thus completing the update (i.e., replacing the local SDK).

[0157] Thus, the software toolkit update method provided in this application embodiment solves the problem of version management difficulties in the release and update of software toolkits when delivering software toolkits in a private manner, and realizes the orderly sending and updating of software toolkit versions when delivering software toolkits in a private manner.

[0158] In some embodiments, see Figure 5A , Figure 5A This is a schematic diagram illustrating the effect of the software toolkit update method provided in this application embodiment. Figure 5A The image shows the display interface of the applications running in the client (iOS, Android, and mini-program). Figure 5A The left-hand component information bar displays a list of software toolkits by name (SDK-name), where the software toolkit name (SDK-name) can be: TMFlocation, TMFShare, TMFWebOffline, etc.

[0159] In some embodiments, see Figure 5B , Figure 5B This is a schematic diagram illustrating the effect of the software toolkit update method provided in this application embodiment. Figure 5B The header file information shown is for the software toolkit named TMFShark, version 1.6.

[0160] In some embodiments, see Figure 5C , Figure 5C This is a schematic diagram illustrating the effect of the software toolkit update method provided in this application embodiment. Figure 5C The header file information shown is for the software toolkit named TMFShark, version 1.7.

[0161] As an example, see Figures 5A to 5C When the user selects Figure 5A When TMFShark is listed in the software toolkit list, it is displayed in the interface of the application running on the client (iOS, Android, and WeChat Mini Program). Figure 5B The header file information for the TMF Shark software toolkit version 1.6 is shown; in response to the switching operation, the display interface of the application running in the client (iOS, Android, and mini-program) is displayed. Figure 5C The header file information shown indicates that the TMFShark software toolkit version number is 1.7.

[0162] The following description continues to illustrate the exemplary structure of the software toolkit update device 455 provided in the embodiments of this application as a software module. In some embodiments, such as... Figure 2 As shown, the software modules stored in the software toolkit update device 455 in the memory 440 may include:

[0163] The first sending module 4551 is used to send a list of software toolkits to the client; wherein the list of software toolkits includes the name of each software toolkit integrated in the client and at least one version number; the receiving module 4552 is used to receive an update request from the client; wherein the update request carries a target name and a target version number selected based on the list of software toolkits; the query module 4553 is used to query a baseline version that matches the target name and target version number, and query a target branch version that matches the client's type in at least one branch version associated with the baseline version; wherein different branch versions correspond to different types; the second sending module 4554 is used to send the software toolkit of the target branch version to the client; wherein the software toolkit of the target branch version is used to replace the software toolkit of the historical version with the target name in the client.

[0164] In some embodiments, the query module 4553 is further configured to query the database based on the target name to obtain at least one array index corresponding to the target name; wherein each array index includes a baseline version of the software toolkit of the target name, and the baseline versions included in different array indexes have different version numbers; querying the array index that matches the target version number in at least one array index, and using the baseline version included in the queried array index as the baseline version that matches the target name and the target version number.

[0165] In some embodiments, the query module 4553 is further configured to parse the client update request to obtain the client type carried in the update request; take the array index of the baseline version that matches the target name and target version number as the target array index; and compare each branch version included in the target array index with the client type to obtain the target branch version that matches the client type.

[0166] In some embodiments, the software toolkit update apparatus further includes: a construction module, configured to determine the version corresponding to each software toolkit based on each software toolkit integrated in the client; and to construct a software toolkit list for the corresponding client based on the version corresponding to each software toolkit and the name of each software toolkit.

[0167] In some embodiments, the above-described construction module is further configured to extract header files from the software toolkit initially submitted by the development device, and parse them to obtain the name and version number of the initially submitted software toolkit; construct a software toolkit list based on the name and version number of the initially submitted software toolkit; extract the corresponding header files from each subsequent software toolkit submitted by the development device, and parse them to obtain the name and updated version number of each submitted software toolkit; and sequentially write the updated version number of each submitted software toolkit into the list item of the corresponding name in the software toolkit list.

[0168] In some embodiments, the above-described construction module is further configured to compare the name of the currently submitted software toolkit with the name of the previously submitted software toolkit; when the name of the currently submitted software toolkit exists in the name of the previously submitted software toolkit, the update version number of the currently submitted software toolkit is written into a list item with the same name as the currently submitted software toolkit; when the name of the currently submitted software toolkit does not exist in the name of the previously submitted software toolkit, a new list item with the name of the currently submitted software toolkit is created in the software toolkit list, and the update version number of the currently submitted software toolkit is written into the list item with the name of the currently submitted software toolkit.

[0169] In some embodiments, the software toolkit update apparatus further includes: a dependency query module, configured to determine at least one dependent software toolkit and its corresponding dependent version of the baseline version software toolkit based on the dependency information of the baseline version; and send at least one dependent software toolkit of the dependent version to the client so that the client can perform the following process: replace the dependent software toolkit of the historical version in the client with at least one dependent software toolkit of the dependent version.

[0170] In some embodiments, the dependency query module is further configured to determine, based on the dependency information of the baseline version, at least one dependent software toolkit that the software toolkit of the baseline version depends on; and to determine the corresponding dependency version based on the at least one dependent software toolkit that the software toolkit of the baseline version depends on; wherein, the dependency version is the lowest version that is depended on.

[0171] In some embodiments, the second sending module is further configured to query the storage address corresponding to the name and version number of the target branch version in the mapping relationship between the software toolkit list and the storage address; wherein the mapping relationship includes the storage addresses of the software toolkits with different names and version numbers in the software toolkit list; download the software toolkit of the target branch version according to the queried storage address; and send the downloaded software toolkit of the target branch version to the client.

[0172] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the software toolkit update method described above in this application.

[0173] This application provides a computer-readable storage medium storing executable instructions. When these executable instructions are executed by a processor, they cause the processor to execute an update method for a software toolkit provided in this application. For example, ... Figure 3A The software toolkit update method is shown.

[0174] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0175] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0176] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0177] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0178] In summary, the embodiments of this application have the following beneficial effects:

[0179] (1) Version management of different versions of software toolkits is achieved through a software toolkit list, which effectively enhances the efficiency of software toolkit version management. Simultaneously, the system receives the target name and target version number selected from the software toolkit list, queries the baseline version matching the target name and target version number, and then determines the target branch version matching the type of the client sending the update request based on the branch version associated with the baseline version. By replacing the corresponding historical version of the software toolkit in the client with the software toolkit of the target branch version, targeted and efficient updates to the software toolkit version are achieved.

[0180] (2) The software toolkit of the target branch version downloaded by the user is sent to the client through the plug-in platform. The software toolkit of the target branch version is adapted to the user's type, so as to meet the personalized customization needs of the client to update the software toolkit.

[0181] (3) By extracting the header file from the submitted software toolkit and parsing the header file, the name (SDK-name) and version number (SDK-version) of the software toolkit in the header file can be obtained, which facilitates the construction of a software toolkit list based on the obtained name (SDK-name) and version number (SDK-version) of the software toolkit in the header file.

[0182] (4) By writing the update version number of each submitted software toolkit into the list item of the corresponding name in the software toolkit list in sequence, a software toolkit list is constructed. The software toolkit list makes it easier to manage the version of the software toolkit.

[0183] (5) By identifying at least one dependent software toolkit and its corresponding dependent version of the baseline version of the software toolkit, the dependent software toolkit of the historical version in the client is replaced. Thus, while updating the software toolkit of the target branch version, the dependent software toolkit of the historical version in the client is updated simultaneously, thereby comprehensively updating the corresponding functions in the client.

[0184] (6) By determining at least one dependent software toolkit and its corresponding dependent version based on the dependency information of the baseline version, the dependent software toolkit is sent to the client, thereby installing and replacing the historical version of the software toolkit in the client. While installing and replacing the software toolkit selected by the user, the dependent software toolkits that are mutually dependent with the functions of the software toolkit selected by the user are also installed and replaced, so that the updated software toolkit selected by the user can better realize its functions, effectively ensuring the functions of the updated software toolkit and better meeting the user's functional needs for updating the software toolkit.

[0185] (7) By querying the baseline version that matches the target name and target version number, the software toolkit of the baseline version selected by the user is determined. Then, by querying the software toolkit of the target branch version that matches the client type in at least one branch version associated with the baseline version, the software toolkit of the target branch version that is determined is both compatible with the client type and is the version selected by the user, thereby better meeting the user's personalized needs.

[0186] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for updating a software toolkit, characterized in that, The method includes: Send a list of software toolkits to the client; wherein the list of software toolkits includes the name of each software toolkit integrated in the client and at least one version number; Receive the update request from the client; wherein the update request carries a target name and a target version number selected based on the software toolkit list; The database is queried based on the target name to obtain at least one array index corresponding to the target name; wherein each array index includes a baseline version of the software toolkit of the target name, and different array indexes include baseline versions with different version numbers; each array index also includes at least one branch version belonging to the baseline version, each branch version includes the same version number as the baseline version, and each branch version also includes a type corresponding to a different client. In the at least one array index, query the array index that matches the target version number. Take the baseline version included in the queried array index as the baseline version that matches the target name and the target version number. In the at least one branch version associated with the baseline version, query the target branch version that matches the type of the client. Different branch versions correspond to different types of the client. Send the target branch version of the software toolkit to the client; wherein the target branch version of the software toolkit is used to replace the historical version of the software toolkit with the target name in the client.

2. The method according to claim 1, characterized in that, The step of querying for a target branch version that matches the client type in at least one branch version associated with the baseline version includes: The client update request is parsed to obtain the type of the client carried in the update request; The array index of the baseline version that matches the target name and the target version number is used as the target array index. Each branch version included in the target array index is compared with the type of the client to obtain the target branch version that matches the type of the client.

3. The method according to claim 1, characterized in that, Before sending the list of software toolkits to the client, the method further includes: Perform the following processing for different types of clients: Based on each software toolkit integrated in the client, determine the version corresponding to each software toolkit; Based on the version and name of each software toolkit, a list of software toolkits corresponding to the client is constructed.

4. The method according to claim 3, characterized in that, The step of constructing a list of software toolkits corresponding to the client based on the version and name of each software toolkit includes: For each of the software toolkits, the following processing is performed: The header file is extracted from the software toolkit submitted for the first time by the development device and parsed to obtain the name and version number of the software toolkit submitted for the first time; Based on the name and version number of the software toolkit submitted for the first time, construct a list of software toolkits; The header files are extracted from each subsequent software toolkit submitted by the development device and parsed to obtain the name and update version number of each submitted software toolkit. The update version number of each submitted software toolkit is sequentially written into the list item of the corresponding name in the software toolkit list.

5. The method according to claim 4, characterized in that, The step of sequentially writing the update version number of each submitted software toolkit into the list item of the corresponding name in the software toolkit list includes: Perform the following processing on the name and update version number of the currently submitted software toolkit: The name of the currently submitted software toolkit is compared with the name of the previously submitted software toolkit. When the name of the currently submitted software toolkit is present in the name of the previously submitted software toolkit, the update version number of the currently submitted software toolkit is written into the list item with the same name as the currently submitted software toolkit. If the name of the currently submitted software toolkit does not exist in the previously submitted software toolkit name, a new list item for the name of the currently submitted software toolkit is created in the software toolkit list, and the update version number of the currently submitted software toolkit is written into the list item for the name of the currently submitted software toolkit.

6. The method according to claim 1, characterized in that, When the baseline version is associated with dependency information, after querying the baseline version that matches the target name and the target version number, the method further includes: Based on the dependency information of the baseline version, determine at least one dependent software toolkit and its corresponding dependent version for the software toolkit of the baseline version; The client sends the at least one dependent software toolkit of the dependent version to the client so that the client can perform the following process: replace the dependent software toolkit of the historical version in the client with the at least one dependent software toolkit of the dependent version.

7. The method according to claim 6, characterized in that, The step of determining at least one dependent software toolkit and its corresponding dependent version for the software toolkit of the baseline version based on the dependency information of the baseline version includes: Based on the dependency information of the baseline version, determine at least one of the dependent software toolkits that the software toolkit of the baseline version depends on; Determine the corresponding dependency version based on at least one of the dependent software toolkits that the baseline version of the software toolkit depends on; The dependent version is the lowest version that is required.

8. The method according to claim 1, characterized in that, Sending the target branch version of the software toolkit to the client includes: In the mapping relationship between the software toolkit list and storage addresses, query the storage address corresponding to the name and version number of the target branch version; wherein, the mapping relationship includes the storage addresses of different names and version numbers of the software toolkits in the software toolkit list. Download the software toolkit for the target branch version based on the retrieved storage address; Send the downloaded software toolkit of the target branch version to the client.

9. A software toolkit update device, characterized in that, The device includes: The first sending module is used to send a list of software toolkits to the client; wherein the list of software toolkits includes the name of each software toolkit integrated in the client and at least one version number; A receiving module is configured to receive an update request from the client; wherein the update request carries a target name and a target version number selected based on the software toolkit list; A query module is configured to query a database based on the target name to obtain at least one array index corresponding to the target name; wherein each array index includes a baseline version of the software toolkit for the target name, and different array indexes include baseline versions with different version numbers; each array index also includes at least one branch version belonging to the baseline version, each branch version includes the same version number as the baseline version, and each branch version also includes a different client type; the module queries the at least one array index for an array index that matches the target version number, takes the baseline version included in the queried array index as the baseline version that matches the target name and the target version number, and queries the at least one branch version associated with the baseline version for a target branch version that matches the client type; wherein different branch versions correspond to different types; The second sending module is used to send the target branch version of the software toolkit to the client; wherein the target branch version of the software toolkit is used to replace the historical version of the software toolkit with the target name in the client.

10. The apparatus as claimed in claim 9, characterized in that, The query module is also used for: The client update request is parsed to obtain the type of the client carried in the update request; the array index of the baseline version that matches the target name and the target version number is used as the target array index; each branch version included in the target array index is compared with the type of the client to obtain the target branch version that matches the type of the client.

11. The apparatus as claimed in claim 9, characterized in that, It also includes building modules for: Based on each software toolkit integrated in the client, determine the version corresponding to each software toolkit; based on the version corresponding to each software toolkit and the name of each software toolkit, construct a list of software toolkits corresponding to the client.

12. The apparatus as claimed in claim 11, characterized in that, The building module is also used for: The header file is extracted from the software toolkit submitted for the first time by the development device and parsed to obtain the name and version number of the first submitted software toolkit; a list of software toolkits is constructed based on the name and version number of the first submitted software toolkit; The header file is extracted from each subsequent software toolkit submitted by the development device and parsed to obtain the name and update version number of each submitted software toolkit; the update version number of each submitted software toolkit is then written into the list item of the corresponding name in the software toolkit list.

13. A software toolkit update device, characterized in that, include: Memory, used to store executable instructions; A processor, when executing executable instructions stored in the memory, implements the method for updating the software toolkit according to any one of claims 1 to 8.

14. A computer-readable storage medium storing executable instructions, characterized in that, Used to cause the processor to execute a method for updating the software toolkit according to any one of claims 1 to 8.

15. A computer program product comprising computer-executable instructions, characterized in that, When the computer-executable instructions are executed by the processor, they implement the method for updating the software toolkit according to any one of claims 1 to 8.

Images