Dynamic interaction card to-do message pushing method and device based on a honkong system

Abstract

This invention relates to a method and apparatus for dynamic interactive card-based to-do message push based on the HarmonyOS system, comprising the following steps: A series of page routes that can be called externally are predefined in the to-do application; the server embeds a deep link and required parameters in the sent notification content; the HarmonyOS push service parses and stores the deep link when rendering and displaying the card; when the user clicks the pushed card, the HarmonyOS system intercepts the click event, and based on the deep link bound to the card, directly wakes up the target to-do application and jumps to the details page, while simultaneously passing the parameters to the page; after the target page within the to-do application is launched, it receives and parses the parameters, and then requests or loads detailed information from the server or from the local cache according to the link and presents it to the user. The advantages of this invention are: it achieves precise direct access from the pushed card to the target page within the application, greatly shortening the user's operation path.

Description

Technical Field

[0001] This invention relates to the field of computer applications, and more particularly to a method and apparatus for pushing dynamic interactive card-based to-do messages based on the HarmonyOS system. Background Technology

[0002] With the development of mobile internet, various applications (APPs) have become important tools for users to handle work and life affairs. Many enterprises and developers develop their own mobile APPs to handle various internal matters. In current mobile operating systems (such as Android and iOS), push notifications are an important way for service providers to interact with users. Traditional push notifications are usually presented in plain text or simple graphic format. After clicking, users need to jump to the corresponding application (App) to manually perform further actions, such as viewing details or replying to messages. Current mobile operating system push notifications (such as Android's Notification and iOS's Push Notification) usually only launch the application's default home page after the user clicks. Even if the user receives a notification for a specific function (such as a chat message), clicking it often first takes them to the application's home page, and then the user needs to manually navigate to the target page, failing to achieve precise direct access. Summary of the Invention

[0003] To address the aforementioned issues, the present invention aims to provide a dynamic interactive card-based to-do message push method and apparatus based on the HarmonyOS system, achieving precise and direct delivery from the pushed card to the target page within the application, thereby significantly shortening the user's operation path.

[0004] To achieve the above objectives, the present invention adopts the following technical solution:

[0005] Technical Solution 1

[0006] The dynamic interactive card-based to-do message push method based on HarmonyOS includes the following steps:

[0007] Deploy the application on the terminal of the HarmonyOS system and predefine page routes for page components that need to be triggered externally;

[0008] The terminal receives a notification from the server, which embeds a deep link carrying parameters required for the page.

[0009] After receiving the notification, the HarmonyOS push service renders and displays the card, and at the same time parses and stores the deep link and binds the card to the deep link;

[0010] When a user clicks on a pushed card, the HarmonyOS system intercepts the click event, reads the deep link bound to the card, determines the application package through the deep link, matches the page route of the application package with the deep link, and when the page path matches successfully, launches the target page and passes the required parameters from the deep link to the target page.

[0011] Once the target page is launched, it receives and parses the required parameters, and then requests or loads detailed information from the server or local cache based on the parameter parsing results and presents it to the user.

[0012] More preferably, the page route is a structured string consisting of an Ability, a page path, and supported parameters; after the page route is predefined, the application configuration file declares that external access is allowed and the supported route format is declared through the skills configuration of the Ability, exposing the routing rules to the system so that the system can invoke the corresponding Ability.

[0013] More preferably, the deep link consists of a protocol, application package name, Ability, page path, and key-value (KV) format parameters, wherein the KV format parameters are used to locate resources, filter content, or preset states.

[0014] Based on the same inventive concept, the present invention also provides a dynamic interactive card to-do message push device based on the HarmonyOS system.

[0015] A dynamic interactive card-based to-do message push device based on the HarmonyOS system, including

[0016] Predefined modules: Predefine page routes for page components that need to be triggered externally within the application;

[0017] Notification receiving module: The terminal receives a notification from the server, in which a deep link carrying parameters required for the page is embedded;

[0018] Link parsing module: After receiving the notification, the HarmonyOS push service renders and displays the card, and at the same time parses and stores the deep link and binds the card to the deep link;

[0019] Application routing module: When a user clicks on a pushed card, the HarmonyOS system intercepts the click event, reads the deep link bound to the card, determines the application package through the deep link, matches the page route of the application package with the deep link, and when the page path matches successfully, launches the target page and passes the required parameters from the deep link to the target page.

[0020] Parameter parsing module: After the target page is launched, it receives and parses the required parameters, and then requests or loads detailed information from the server or local cache based on the parameter parsing results and presents it to the user.

[0021] More preferably, the page route is a structured string consisting of an Ability, a page path, and supported parameters; after the page route is predefined, the application configuration file declares that external access is allowed and the supported route format is declared through the skills configuration of the Ability, exposing the routing rules to the system so that the system can invoke the corresponding Ability.

[0022] More preferably, the deep link consists of a protocol, application package name, Ability, page path, and key-value (KV) format parameters, wherein the KV format parameters are used to locate resources, filter content, or preset states.

[0023] The present invention has the following beneficial effects:

[0024] This invention combines parameterized deep links with HarmonyOS push cards to achieve precise one-click access from push cards to specific function pages within an application. This avoids secondary navigation after the user enters the application. Through parameter transmission, it ensures that the context information carried by the push card is continuous and complete, enabling lossless and efficient transmission to the target page. This achieves instant page loading and state restoration, reducing the possibility of users abandoning the target action (such as viewing, paying, or replying) due to cumbersome operations, and effectively improving the conversion value of push notifications and the user activity of the application.

[0025] Meanwhile, the technical solution of this invention allows senders to easily configure different deep links for different types of push notifications, thereby enabling rich traffic redirection strategies. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the process of the present invention. Detailed Implementation

[0027] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments:

[0028] Example 1

[0029] See Figure 1 The dynamic interactive card-based to-do message push method based on the HarmonyOS system includes the following steps:

[0030] Step 1: Define page routes: Predefine page routes for page components in your application that need to be triggered externally. For example, in a to-do application, the "to-do details page" requires users to click on a notification to view it, and the "to-do editing page" requires users to jump from the calendar application to create it. These pages need to have predefined page routes, while the "about page," which is only accessed internally, does not need to have page routes defined.

[0031] The page routing of this invention is a structured string composed of Ability (i.e., application component name), page path, and required parameters. This page routing is a unique access identifier for a page defined based on the HarmonyOS Ability framework and routing protocol. It is used to directly invoke the application and jump to a specified page from external scenarios (such as notifications, other applications, and web pages), and is the core carrier of deep linking. Therefore, this invention combines the ArkTS UI framework and the HarmonyOS Intent mechanism for structured page routing design. Page routing is strongly bound to ArkTS page components (in the HarmonyOS system, each page is a component). Through page routing, the system can directly map to the specific page component that needs to be triggered externally. Required parameters refer to the data that must be obtained during page rendering. For example, the "To-Do Details Page" depends on the `todoId` parameter, fetching data from the server based on the Id; therefore, the page routing must forcibly include the `todoId` parameter. If the "To-Do List Page" needs to filter by date, it must include the optional parameter `date`.

[0032] After completing the predefined page routes, you need to declare "Allow external access" in the application configuration file (e.g., `module.json5`), and expose the routing rules to the system through the `visible: true` and `skills` configurations. The supported route formats are declared through the `skills` configuration of `Ability`, ensuring that the system can invoke the corresponding `Ability`.

[0033] Step 2: Receive notification of embedded deep link: The terminal receives a notification from the server, which embeds a deep link carrying parameters required by the page. The deep link consists of a protocol, application package name, Ability, page path, and key-value (KV) format parameters. The KV format parameters are data carried in the deep link that is necessary for the target page to load or initialize normally. They are used to locate resources, filter content, or preset states. These parameters are the "input items" of the target page; the lack of key parameters may cause the page to fail to display correctly (e.g., a blank page, error message).

[0034] The determination of key-value (KV) format parameters carried in deep links needs to be defined in conjunction with the "functional logic of the target page" and "user scenario requirements." Specifically, this can be analyzed through the following steps: First, clarify the core function of the page: For example, the core of a "to-do details page" is to display the content of a specific to-do item, therefore, it is essential to know the "unique identifier of this to-do item." What is the "unique identifier" of the data required for page loading? For example, the "to-do details page" relies on the "to-do ID" to retrieve the title, time, and content of the to-do item from the server; therefore, the "to-do ID" is a necessary parameter, with the format `todoId=1001`. If further scenario expansion requirements need to be considered: Is it necessary to record the jump source and preset operation status? For example, the "to-do details page" may need to know whether the user jumped from a "notification" or "other application" (for source statistics); therefore, the "source identifier" can be an optional parameter, with the format `from=notification`.

[0035] Take the "To-Do App" "To-Do Details Page" as an example:

[0036] Deep link: `ohos: / / com.example.todoapp / TodoAbility / detail?todoId=2025110601&from=notification&status=unfinished`

[0037] Parameter description:

[0038] `ohos: / / ` is the deep link protocol in HarmonyOS; following this protocol enables the system to resolve deep links and locate applications, avoiding routing conflicts with other applications.

[0039] `com.example.todoapp` is the application package name (uniquely identifying the application).

[0040] The name of the Ability is `TodoAbility` (which is the `Page Ability` that hosts pages related to to-do items).

[0041] Page path: ` / detail` (corresponding to the `TodoDetail` component)

[0042] `todoId=2025110601` (required): A unique identifier for the to-do item (string type). The page uses this ID to retrieve specific content from the server (such as the title "Monday Meeting" and the time "14:00").

[0043] `from=notification` (optional): Redirect source identifier (string type), used to track whether users clicked through from a notification (other possible values: "calendar", "share"), facilitating subsequent optimization of operational strategies. `status=unfinished` (optional): Preset to-do status (string type). The page can display an "incomplete" filter view by default based on this parameter, reducing user interaction.

[0044] Deep linking is a unique link format defined in this invention. It carries structured parameters (KV format) required for page rendering, transmits data to the target page, and combines it with pre-registered page routes in the application package to implement parameter parsing logic. It can not only launch the target application, but also directly jump to a specified page within the application, realizing a complete closed loop of "external trigger → application launch → precise page jump → data initialization". Its core value is to shorten the user operation path, avoid users manually navigating from the application homepage to the target page, and improve the experience efficiency.

[0045] Step 3: Binding of Cards and Links: After receiving the notification, the HarmonyOS push service on the terminal renders and displays the card, and at the same time parses and stores the deep link and binds the card to the deep link.

[0046] Step 4, Intelligent Routing and Parameter Transmission: When a user clicks on a pushed card, the HarmonyOS system intercepts the click event, reads the deep link bound to the card, determines the application package through the deep link, and matches the application package with the deep link through the page route. When the page path matches successfully, the KV format parameters in the deep link are passed to the page.

[0047] Step 5: Instant loading of the target page: After the target page in the to-do application is launched, it receives and parses the parameters, and then requests or loads detailed information from the server or local cache based on the parameter parsing results and presents it to the user. This achieves the direct wake-up of the target to-do application and jumps to the details page, while passing the parameters to the page.

[0048] The core of this invention's technical solution is that "the system parses deep links and combines them with the application's pre-registered page routes. The system finds the page path through deep links, and the application package matches the page using parameters through page routes." Page routes are the "core mapping rules" of the entire process, enabling the association between deep links and pages within the application, thereby achieving the "direct access" function. Key-value (KV) format parameters are the key to locating resources and are the core condition for data requests—without parameters, the page cannot determine the specific content to load, and the function of direct access to the details page through deep links cannot be realized.

[0049] Taking the "To-Do Details Page" of a to-do application as an example, the application redirection process of this invention is explained as follows:

[0050] The steps for defining page routes in ArkTS are as follows:

[0051] 1. Set the page route on the page that needs to be triggered externally: `[Ability Name] / [Page Path]?[Parameters]`

[0052] 2. Register page routes in the configuration of the application to be done.

[0053] You need to declare `TodoAbility` to support external access in the `abilities` configuration of `module.json5` (this is the application's configuration file), and bind a routing rule (telling the system "this route corresponds to this Ability"):

[0054] { "module": { "package": "com.example.todoapp", "abilities": [ { "name": "TodoAbility", / / Ability name (must match the code) "type": "page", / / Page type Ability "visible": true, / / Allow external access "skills": [ { "actions": ["ohos.intent.action.VIEW"], / / Supported actions (VIEW is usually used for external invocation) "uris": [ { "scheme": "ohos", / / Protocol "host": "com.example.todoapp", / / Application package name "path":" / TodoAbility / detail", / / Page path (associated with Ability) "parameters": ["todoId", "from"] / / Supported parameters} ]} ]} ]}}

[0055] 2. The parameter parsing process of page components when a page route is triggered is as follows (ArkTS code)

[0056] In the `TodoDetail.ets` component, externally passed parameters are received through the `onNewIntent` method of `Ability` (the parameters are encapsulated in an `Intent`):

[0057] import { Intent} from '@ohos.app.ability.Intent';

[0058] import router from '@ohos.router';

[0059] @Entry

[0060] @Component

[0061] struct TodoDetail {

[0062] @State todoId: string = '';

[0063] @State from: string = 'unknown';

[0064] async aboutToAppear() {

[0065] / / Get the Intent of the current Ability (including externally passed parameters)

[0066] const abilityContext = getContext(this) as AbilityContext;

[0067] const intent: Intent = abilityContext.currentIntent;

[0068] if (intent) {

[0069] / / Parse parameters in the route

[0070] this.todoId = intent.getStringParam('todoId') || '';

[0071] this.from = intent.getStringParam('from') || 'unknown';

[0072] / / Load to-do details based on todoId

[0073] await this.loadTodoDetail(this.todoId);}}

[0074] / / Load to-do details from the server

[0075] async loadTodoDetail(id: string) {

[0076] if (!id) return;

[0077] const response = await fetch(`https: / / api.example.com / todo / ${id}`);

[0078] const data = await response.json();

[0079] / / Update UI to display details...

[0080] }

[0081] build() {

[0082] Column() {

[0083] Text(`To-do ID: ${this.todoId}`)

[0084] Text(`Source: ${this.from}`)

[0085] / / Other UI components...

[0086] }}}

[0087] This invention combines parameterized deep links with HarmonyOS push cards to achieve precise one-click access from push cards to specific function pages within an application. This avoids secondary navigation after the user enters the application. Through parameter transmission, it ensures that the context information carried by the push card is continuous and complete, enabling lossless and efficient transmission to the target page. This achieves instant page loading and state restoration, reducing the possibility of users abandoning the target action (such as viewing, paying, or replying) due to cumbersome operations, and effectively improving the conversion value of push notifications and the user activity of the application.

[0088] Example 2

[0089] A dynamic interactive card-based to-do message push device based on the HarmonyOS system, including

[0090] Predefined modules: Predefine page routes for page components that need to be triggered externally within the application;

[0091] Notification receiving module: The terminal receives a notification from the server, which embeds a deep link carrying parameters required for the page. The deep link consists of a protocol, application package name, Ability, page path, and key-value (KV) format parameters.

[0092] Link parsing module: After receiving the notification, the HarmonyOS push service on the terminal renders and displays the card, and at the same time parses and stores the deep link and binds the card to the deep link;

[0093] Application routing module: When a user clicks on a pushed card, the HarmonyOS system intercepts the click event, reads the deep link bound to the card, determines the application package through the deep link, and matches the application package with the deep link through page routing. When the page path matches successfully, the key-value format parameters in the deep link are passed to the page.

[0094] The parameter parsing module receives and parses parameters after the target page within the to-do application is launched. Then, based on the parameter parsing results, it requests detailed information from the server or loads it from the local cache and presents it to the user. This enables the direct wake-up of the target to-do application and redirection to the details page, while simultaneously passing the parameters to that page.

[0095] For details not described in this embodiment two, please refer to the method in embodiment one. The beneficial effects of this embodiment two are the same as those of embodiment one.

[0096] The above description is merely a specific embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for pushing a to-do message of a dynamic interaction card based on a Harmony system, characterized in that: Includes the following steps: Deploy the application on the terminal of the HarmonyOS system and predefine page routes for page components that need to be triggered externally; The terminal receives a notification from the server, which embeds a deep link carrying parameters required for the page. After receiving the notification, the HarmonyOS push service renders and displays the card, and at the same time parses and stores the deep link and binds the card to the deep link; When a user clicks on a pushed card, the HarmonyOS system intercepts the click event, reads the deep link bound to the card, determines the application package through the deep link, matches the page route of the application package with the deep link, and when the page path matches successfully, launches the target page and passes the required parameters from the deep link to the target page. Once the target page is launched, it receives and parses the required parameters, and then requests or loads detailed information from the server or local cache based on the parameter parsing results and presents it to the user.

2. The method of claim 1, wherein the method is implemented by a system based on a HongMeng system. The page route is a structured string consisting of an Ability, a page path, and supported parameters. After the page route is predefined, external access is allowed in the application configuration file, and the supported route format is declared through the skills configuration of the Ability, exposing the routing rules to the system so that the system can invoke the corresponding Ability. 3.The method of claim 2, wherein the method further comprises: The deep link consists of a protocol, application package name, Ability, page path, and key-value (KV) format parameters. The KV format parameters are used to locate resources, filter content, or preset states.

4. A dynamic interactive card-based to-do message push device based on the HarmonyOS system, characterized in that: include Predefined modules: Predefine page routes for page components that need to be triggered externally within the application; Notification receiving module: The terminal receives a notification from the server, in which a deep link carrying parameters required for the page is embedded; Link parsing module: After receiving the notification, the HarmonyOS push service renders and displays the card, and at the same time parses and stores the deep link and binds the card to the deep link; Application routing module: When a user clicks on a pushed card, the HarmonyOS system intercepts the click event, reads the deep link bound to the card, determines the application package through the deep link, matches the page route of the application package with the deep link, and when the page path matches successfully, launches the target page and passes the required parameters from the deep link to the target page. Parameter parsing module: After the target page is launched, it receives and parses the required parameters, and then requests or loads detailed information from the server or local cache based on the parameter parsing results and presents it to the user.

5. The dynamic interactive card-based to-do message push device based on HarmonyOS according to claim 4, characterized in that: The page route is a structured string consisting of an Ability, a page path, and supported parameters. After the page route is predefined, external access is allowed in the application configuration file, and the supported route format is declared through the skills configuration of the Ability, exposing the routing rules to the system so that the system can invoke the corresponding Ability.

6. The dynamic interactive card-based to-do message push device based on HarmonyOS according to claim 5, characterized in that: The deep link consists of a protocol, application package name, Ability, page path, and key-value (KV) format parameters. The KV format parameters are used to locate resources, filter content, or preset states.

Images