WO2024244473A1 - Component refreshing method and electronic device - Google Patents

Abstract

The present application relates to the technical field of terminals, and discloses a component refreshing method and an electronic device, for use in solving the problem of the application process needing to be resident to implement component refreshing, and reducing the system power consumption and the memory overhead of an electronic device. The method comprises: receiving component data published by a data provider of a component; and in response to a subscription event for the component data, transmitting the component data to a component user, wherein the component user is used for refreshing and displaying the component data in the component, and the subscription event is used for instructing the component user to subscribe to the refreshing of the component data.

Description

Component refreshing method and electronic device

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of the People's Republic of China on May 26, 2023, with application number 202310603225.5 and invention name "A component refresh method and electronic device", all contents of which are incorporated by reference in this application.

Technical Field

The embodiments of the present application relate to the field of terminal technology, and in particular to a component refresh method and an electronic device.

Background Art

With the popularization of electronic devices, in addition to providing users with basic application icons on the desktop, many operating systems can also provide users with some shortcut functions of applications or display some key information of applications in the form of components such as service cards and desktop widgets.

The information displayed by some types of components is time-sensitive. In order for users to obtain the latest information in a timely manner, it is generally necessary to refresh the data in a timely manner. Currently, component refresh requires pulling up the process of the component provider and the process of the component data provider. As the number and types of components on electronic devices gradually increase, the resulting power consumption and memory issues cannot be ignored.

Summary of the invention

The embodiments of the present application provide a component refresh method and an electronic device, which are used to solve the problem that an application process needs to be resident to implement component refresh, and can reduce the system power consumption and memory overhead of the electronic device.

In the first aspect, an embodiment of the present application provides a component refresh method. In the method, component data published by a data provider of the component is received; in response to a subscription event for the component data, the component data is transmitted to a component user, and the component user is used to refresh the component data and display it in the component; wherein the subscription event is used to instruct the component user to subscribe to the refresh of the component data.

Through this method, the life cycle of the component user and the component provider can be decoupled. The data provider of the component can publish updated data, and based on the subscription of the component user to the component data, the component can be refreshed and displayed in time. In this way, by dividing the component life cycle into data publishing and data subscription, self-refresh can be achieved without relying on the data provider. This method can solve the problem that the component provider process must be pulled up for component refresh, thereby reducing the power consumption and memory problems caused by component refresh.

In addition, the method can realize that the component provider does not need to integrate the software development kit (SDK) of other data providers by providing a component data proxy. The component data proxy can realize the connection between the component provider and the data provider, thereby reducing the complexity of development.

In one possible design, the data provider is an application (APP), a system or a server; wherein the APP is the APP to which the component belongs; wherein the APP includes the APP to which the component belongs, or the APP associated with the component data of the component; wherein the APP associated with the component data of the component can be understood as, the component data of an APP can be derived from other APPs, for example, the step data of a third-party sports health APP can be derived from the step data of the system sports health APP. In addition, a component can have a data provider and a component provider, and the component provider can be used to provide component layout, control the layout of controls on the component, and control click events, etc.; wherein the data provider can be the same APP as the component provider, or a different APP, or the data provider can also be a way to publish data such as a system or server, and this application does not limit this.

In this design, during the component refresh process, there is no need to pull up the component provider, and the data provider process does not need to be resident. When there is updated data, the data provider publishes the data to the component data agent or component management service. Therefore, it is possible to reduce power consumption and memory usage.

In one possible design, the component data is transmitted to the component user, which may be implemented as transmitting the component data to the component user through a component management service, and the component management service is used to manage the component. Exemplarily, a functional unit of a component data agent may be responsible for receiving component data published by a data provider, and a component user may subscribe to data from a component data agent through a component management service to achieve data refresh of the component. It is understandable that a component data agent and a component management service are logical functional units, which may be two independent functional units or an integrated functional unit, and this application does not limit this.

In this design, the component refresh method provided in the embodiment of the present application can be implemented through the component management service and the component data agent, and the life cycle decoupling of the component user and the component provider can be achieved, thereby reducing the power consumption and memory problems caused by component refresh.

In some possible designs, the card data agent may have but is not limited to the following capabilities: defining uniform resource identifiers (URIs) and corresponding data formats, providing standardized SDK interfaces, providing data storage, providing necessary data access permission checking capabilities, etc.

In one possible design, before transmitting the component data to a component user in response to a subscription event to the component data, the method further includes: detecting the subscription event, wherein the subscription event is used to indicate receipt of a subscription request sent by the component user, the subscription request includes a component identifier of the component, and the subscription request is used to indicate a subscription to a refresh of the component based on the component identifier.

In this design, component users can subscribe to component refresh data based on component identification, and data providers can publish component refresh data based on component identification. In this way, component identification can be used to achieve data docking between component users and data providers, so that the data published by the data provider can be refreshed to component users who subscribe to the component data.

In a possible design, the subscription request also includes the subscribed data type. In this design, by including the data type, more accurate component refresh can be achieved.

In one possible design, the component is a service card or a widget. In one possible design, the component user is a host APP. The host APP includes but is not limited to one or more of the following APPs: desktop APP, negative one screen APP, notification bar APP, and any other APP that can create components.

In a second aspect, the present application provides an electronic device, the electronic device comprising multiple functional modules; the multiple functional modules interact with each other to implement the method performed by the electronic device in any of the above aspects and its embodiments. The multiple functional modules can be implemented based on software, hardware, or a combination of software and hardware, and the multiple functional modules can be arbitrarily combined or divided based on specific implementations.

In a third aspect, the present application provides an electronic device comprising at least one processor and at least one memory, wherein the at least one memory stores computer program instructions, and when the electronic device is running, the at least one processor executes the method executed by the electronic device in any of the above aspects and its various embodiments.

In a fourth aspect, the present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a computer, the computer executes any one of the above aspects and possible methods for designing electronic devices to execute the same.

In a fifth aspect, the present application provides a computer program product, which includes: a computer program (also referred to as code, or instruction), which, when executed, enables a computer to execute any of the above aspects and possible methods of designing an electronic device.

In a sixth aspect, an embodiment of the present application also provides a graphical user interface on an electronic device, the electronic device having a display screen, one or more memories, and one or more processors, the one or more processors being used to execute one or more computer programs stored in the one or more memories, the graphical user interface comprising a graphical user interface displayed when the electronic device executes any of the above aspects and their possible designs.

In a seventh aspect, the present application also provides a chip, which is used to read a computer program stored in a memory and execute any of the above aspects and possible methods for designing electronic devices to execute.

In an eighth aspect, the present application further provides a chip system, which includes a processor for supporting a computer device to implement any of the above aspects and possible methods for designing electronic devices to execute. In one possible design, the chip system also includes a memory, which is used to store programs and data necessary for the computer device. The chip system can be composed of a chip, or it can include a chip and other discrete devices.

For the beneficial effects of any aspect from the second to the eighth aspect and its possible designs, please refer to the beneficial effects of the various possible designs in the first aspect, which will not be repeated here.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1a is a schematic diagram of a scene of a card generation process;

FIG1b is a possible card display interface diagram of an electronic device;

FIG2 is a schematic diagram of a possible hardware structure of an electronic device provided in an embodiment of the present application;

FIG3 is a software structure block diagram of an electronic device provided in an embodiment of the present application;

FIG4 is a schematic diagram of a scenario of a component refresh method provided in an embodiment of the present application;

FIG5 is a schematic diagram of another scenario of a component refresh method provided in an embodiment of the present application;

FIG6 is a schematic flow chart of a component refresh method provided in an embodiment of the present application;

FIG. 7 is a flow chart of a component refresh method provided in an embodiment of the present application.

DETAILED DESCRIPTION

The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

The embodiments of the present application can be applied to the field of terminal technology, and specifically can be applied to scenarios in which desktop components including but not limited to service cards, desktop widgets, etc. are displayed on the display interface of an electronic device.

In the following embodiments, a card is used as an example for introduction. A card is a service form that can provide a more fine-grained atomic service capability than an application (APP), and directly display the services or content that users care about most to users in the form of interactive cards. In addition, the card can also track the changes in services or content over time, and display the latest services or content. For example, the card corresponding to the weather APP displays more timely weather information, the card corresponding to the clock APP displays accurate time information, and the card corresponding to the sports health APP displays updated step information. The card can be displayed through a variety of card hosts, for example, it can be set to display on the desktop, on the negative one screen, or it can be embedded in various APPs or interactive scenarios to better meet user needs. Users can jump to the corresponding APP or a service page in the APP by clicking on the card, reducing the difficulty of application operation.

In a possible scenario, refer to FIG. 1a, which is a schematic diagram of a card generation process. Exemplarily, the card generation process is generally implemented by the joint operation of the card user, the card management service, the card provider, and the data provider.

(1) Card user (also called "card host"): It is a host application that displays the card content and controls the location of the card in the host. For example, the card user can generally be a desktop application or process of an electronic device, such as realizing the display of a card on a mobile phone desktop, etc. As shown in FIG1b, interface 100A is a mobile phone desktop interface, and area 101 shown in the mobile phone desktop interface includes cards for the calendar APP and cards for the weather APP. For another example, the card user can also be a host application such as a negative one-screen application or process, a notification bar process, etc. of an electronic device, as shown in FIG1b, interface 100B is a negative one-screen display interface, and area 102 shown in the negative one-screen display interface includes a card for the phone usage time, a card for the sports and health APP, a card for the calendar APP, and a card for the weather APP.

(2) Card management service: a resident agent service for managing the cards added to the system, including the management and use of card objects, and periodic card refresh, etc. The card management service may include but is not limited to the following modules:

2-1) Refresh module: After the card is added, a scheduled task is started according to the card refresh policy to periodically trigger the refresh of the card. For example, the card of the calendar app can be updated daily to update the card of the calendar app to display the latest date information. For another example, the card of the weather app can be updated in response to a trigger event to display the latest weather information; wherein the trigger event may include but is not limited to: the user clicks on the operation instruction of the weather app card, the desktop process displays the desktop interface including the weather app card trigger event, etc.

2-2) Cache module: After a card is added to the card management service, the card's view information is cached so that the cached data can be directly returned the next time the card is retrieved, reducing latency.

2-3) Lifecycle management module: When a card is switched to the background or blocked, the card refresh is suspended; and the card data is updated and cleaned up in the card upgrade or uninstallation scenario.

2-4) Object management module: manages the remote procedure call (RPC) objects of the card user, which is used to verify the user's request and process callbacks after the card is updated.

2-5) Communication Adaptation Layer: responsible for RPC communication with card users and card providers.

(3) Card provider: a system application or third-party application that provides card layout and style, controls the card control layout and control click events, etc. The card provider may include but is not limited to the following modules:

3-1) Card service module: Developers can use the onCreateForm instruction to create a card, the onUpdateForm instruction to update a card, and the onDeleteForm instruction to delete a card to enable the developed application to provide corresponding card services.

3-2) Instance management module: implemented by the card provider developer, responsible for the persistent management of the card instances allocated by the card management service.

3-3) Communication adaptation layer: provided by the software development kit (SDK), it is responsible for communicating with the card management service and is used to actively push the card's updated data to the card management service.

Card users and card providers are not required to run resident services all the time. When a card user needs to add a card, delete a card, or request to update a card, the card management service will pull up the card provider to obtain the card information.

(4) Data provider: a server, system, or application that provides some type of specific data included in the card display content. For example, the card provider corresponding to the weather APP card is the weather APP, and the corresponding data provider can be the weather APP, or a platform, system or server that specifically provides weather data. For another example, the data provider corresponding to the card of a third-party weather APP can be the weather APP on the mobile phone; it can be understood that the weather APP can be understood as a system application of the mobile phone.

In some scenarios, the card provider and the data provider may be different. For example, a health app can be a card provider and provide a card that can include a step count function, while the data provider corresponding to the card is a sports health app. In this case, the card provider and the data provider are different. In other scenarios, the card provider and the data provider may be the same. For example, a sports health app can not only provide cards, but also provide step counts in combination with sensors and other devices.

In order to provide the latest information to users through components such as cards and desktop widgets, the information displayed on the card needs to be refreshed in a timely manner. In conjunction with the scenario shown in Figure 1a, the card information refresh usually requires the card management service to trigger the card provider and data provider to be pulled up, and then after receiving the updated information returned by the card provider and data provider, the card management service returns it to the card user, and the card user displays the refreshed information. However, each refresh of the card requires the card provider and data provider to be pulled up, and as the number of cards on the electronic device increases, the resulting memory usage and power consumption problems are also more serious.

In view of this, an embodiment of the present application provides a component refresh method. By setting a component data proxy function, the method can define a uniform resource identifier (URI) and a corresponding data format, and can receive and cache update data published by a component provider and/or a data provider, as well as accept subscriptions from component users and push updated data to component users. Through this method, the life cycle decoupling of component users and component providers and/or data providers can be achieved, and self-refresh that does not rely on data source applications can be achieved, thereby reducing memory usage and power consumption, and improving the performance of electronic devices.

The technical solution in the embodiments of the present application can be applied to electronic devices, and the electronic device can be any device that supports the component function. For example, the electronic device can be an electronic device such as a mobile phone, a tablet computer, a wearable device (e.g., a watch, a bracelet, etc.), a vehicle-mounted device, an augmented reality (AR)/virtual reality (VR) device, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), a smart home device (e.g., a smart TV, a smart speaker, etc.) that can display components on a desktop. It is understandable that the embodiments of the present application do not impose any restrictions on the specific type of electronic device.

The electronic devices to which the embodiments of the present application can be applied include but are not limited to electronic devices equipped with Or electronic devices with other operating systems. The electronic device may be, for example, the terminal device introduced in the above embodiments.

FIG2 shows a schematic diagram of the hardware structure of a possible electronic device. The electronic device 200 includes: a radio frequency (RF) circuit 210, a power supply 220, a processor 230, a memory 240, an input unit 250, a display unit 260, an audio circuit 270, a communication interface 280, and a Wi-Fi module 290. It can be understood by those skilled in the art that the hardware structure of the electronic device 200 shown in FIG2 does not constitute a limitation on the electronic device 200. The electronic device 200 provided in the embodiment of the present application may include more or fewer components than shown in the figure, may combine two or more components, or may have different component configurations. The various components shown in FIG2 can be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and/or application-specific integrated circuits.

The following is a detailed introduction to the various components of the electronic device 200 in conjunction with FIG. 2 :

The RF circuit 210 can be used for receiving and sending data during communication or calls. In particular, after receiving downlink data from the base station, the RF circuit 210 sends it to the processor 230 for processing; in addition, the uplink data to be sent is sent to the base station. Generally, the RF circuit 210 includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (LNA), a duplexer, etc.

In addition, the RF circuit 210 can also communicate with other devices through a wireless communication network. The wireless communication can use any communication standard or protocol, including but not limited to global system of mobile communication (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), long term evolution (LTE), email, short messaging service (SMS), etc.

Wi-Fi technology is a short-range wireless transmission technology. The electronic device 200 can connect to an access point (AP) through a Wi-Fi module 290 to access the data network. The Wi-Fi module 290 can be used to receive and send data during the communication process. In the embodiment of the present application, when the electronic device 200 is a tablet computer, the tablet computer can synchronize data with other electronic devices through the Wi-Fi module 290. For example, the tablet computer can obtain the user's latest step count from the mobile phone, so that the sports health information can be displayed on the tablet computer. The APP components display information that is more consistent with the user’s actual step count.

The electronic device 200 can be physically connected to other devices through the communication interface 280. Optionally, the communication interface 280 is connected to the communication interface of the other device through a cable to achieve data transmission between the electronic device 200 and the other device.

The electronic device 200 can also implement communication services and interact with other electronic devices, so the electronic device 200 needs to have a data transmission function, that is, the electronic device 200 needs to include a communication module. Although FIG. 2 shows communication modules such as the RF circuit 210, the Wi-Fi module 290, and the communication interface 280, it is understandable that the electronic device 200 has at least one of the above components or other communication modules (such as a Bluetooth module) for implementing communication to perform data transmission.

For example, when the electronic device 200 is a mobile phone, the electronic device 200 may include the RF circuit 210, and may also include the Wi-Fi module 290, or may include a Bluetooth module (not shown in FIG. 2 ); when the electronic device 200 is a tablet computer, the electronic device 200 may include the Wi-Fi module, or may include a Bluetooth module (not shown in FIG. 2 ); when the electronic device 200 is a smart home device, the electronic device 200 may include the Wi-Fi module 290, or may include a Bluetooth module (not shown in FIG. 2 ).

The memory 240 can be used to store software programs and modules. The processor 230 executes various functional applications and data processing of the electronic device 200 by running the software programs and modules stored in the memory 240. Optionally, the memory 240 may mainly include a program storage area and a data storage area. Among them, the program storage area can store an operating system (mainly including software programs or modules corresponding to the kernel layer, system layer, application framework layer, and application layer, etc.).

In addition, the memory 240 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage device. In the embodiment of the present application, the memory 240 may store data published by a component provider and/or a data provider for component users to refresh the component.

The input unit 250 can be used to receive editing operations of various types of data objects such as digital or character information input by the user, and generate key signal input related to user settings and function control of the electronic device 200. Optionally, the input unit 250 may include a touch panel 251 and other input devices 252.

The touch panel 251, also called a touch screen, can collect user touch operations on or near it (such as operations performed by a user using a finger, a stylus, or any other suitable object or accessory on or near the touch panel 251), and drive corresponding connection devices according to a pre-set program. In the embodiment of the present application, the touch panel 251 can collect user operations on or near it; for example, when the electronic device 200 is a mobile phone, the user operations can be used for the user to view, add, change, or delete components on the mobile phone interface.

Optionally, the other input devices 252 may include, but are not limited to, one or more of a physical keyboard, function keys (such as a volume control button, a switch button, etc.), a trackball, a mouse, a joystick, etc.

The display unit 260 can be used to display information input by the user or information provided to the user and various menus of the electronic device 200. The display unit 260 is the display system of the electronic device 200, which is used to present an interface and realize human-computer interaction. The display unit 260 may include a display panel 261. Optionally, the display panel 261 may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. In an embodiment of the present application, the display unit 260 can be used to display a desktop interface including components, or a negative one-screen interface, etc., and can also be used to display information after a component is refreshed, etc.

The processor 230 is the control center of the electronic device 200, and uses various interfaces and lines to connect various components, and executes various functions and processes data of the electronic device 200 by running or executing software programs and/or modules stored in the memory 240, and calling data stored in the memory 240, so as to realize various services based on the electronic device 200. In the embodiment of the present application, the processor 230 can be used to implement the method provided in the embodiment of the present application.

The electronic device 200 also includes a power supply 220 (such as a battery) for supplying power to various components. Optionally, the power supply 220 can be logically connected to the processor 230 through a power management system, so that the power management system can manage functions such as charging, discharging, and power consumption.

As shown in FIG2 , the electronic device 200 further includes an audio circuit 270, a microphone 271 and a speaker 272, which can provide an audio interface between the user and the electronic device 200. The audio circuit 270 can be used to convert audio data into a signal that can be recognized by the speaker 272, and transmit the signal to the speaker 272, which is converted into a sound signal for output by the speaker 272. The microphone 271 is used to collect external sound signals (such as the sound of a person speaking, or other sounds, etc.), and convert the collected external sound signals into signals that can be recognized by the audio circuit 270, and send them to the audio circuit 270. The audio circuit 270 can also be used to convert the signal sent by the microphone 271 into audio data, and then output the audio data to the RF circuit 210 to send it to, for example, another electronic device, or output the audio data to the memory 240 for subsequent further processing.

Although not shown, the electronic device 200 may also include a camera, at least one sensor, etc., which will not be described in detail herein. The at least one sensor may include but is not limited to a pressure sensor, an air pressure sensor, an acceleration sensor, a distance sensor, a fingerprint sensor, a touch sensor, a temperature sensor, etc.

The operating system (OS) involved in the embodiment of the present application is the most basic system software running on the electronic device 200. The software system of the electronic device 200 can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application takes an operating system adopting a layered architecture as an example to illustrate the software structure of the electronic device 200.

FIG3 is a block diagram of the software structure of an electronic device provided in an embodiment of the present application. As shown in FIG3, the software structure of the electronic device can be a layered architecture, for example, the software can be divided into several layers, each layer has a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the operating system is divided into five layers, from top to bottom, namely, the application layer, the application framework layer (framework, FWK), the runtime and system library, the kernel layer, and the hardware layer.

The application layer may include a series of application packages. As shown in FIG3 , the application layer may include camera, settings, skin module, user interface (UI), third-party applications, etc. Among them, third-party applications may include, for example, wireless local area network (WLAN), music, calls, Bluetooth, video, etc.

In one possible implementation, applications can be developed using the Java language by calling the application programming interface (API) provided by the application framework layer. Developers can interact with the underlying layers of the operating system (such as the hardware layer, kernel layer, etc.) through the application framework layer to develop their own applications. The application framework layer is mainly a series of services and management systems for the operating system.

The application framework layer provides an application programming interface and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions. As shown in Figure 3, the application framework layer may include an activity manager, a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, etc.

The activity manager is used to manage the life cycle of each application and provide common navigation back functions, providing an interactive interface for all program windows.

The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc. The content provider is used to store and obtain data and make the data accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

The phone manager is used to provide communication functions for electronic devices, such as the management of call status (including answering, hanging up, etc.).

The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, an electronic device vibrates, an indicator light flashes, etc.

The runtime includes the core library and the virtual machine. The runtime is responsible for the scheduling and management of the operating system.

The core library consists of two parts: one is the function that the Java language needs to call, and the other is the core library of the operating system. The application layer and the application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform object life cycle management, stack management, thread management, security and exception management, and garbage collection.

The system library can include multiple functional modules, such as surface manager, media framework, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc.

The surface manager is used to manage the display subsystem and provide the fusion of 2D and 3D layers for multiple applications.

The media framework supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media framework can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

A 2D graphics engine is a drawing engine for 2D drawings.

In some embodiments, a three-dimensional graphics processing library may be used to draw a three-dimensional motion trajectory image, and a two-dimensional graphics engine may be used to draw a two-dimensional motion trajectory image.

The kernel layer is the layer between hardware and software. The kernel layer contains at least display driver, camera driver, audio driver, and sensor driver.

The hardware layer can include various types of sensors, such as accelerometers, gravity sensors, touch sensors, etc.

Usually, the electronic device 200 can run multiple applications at the same time. In a simpler case, one application can correspond to one process, and in a more complex case, one application can correspond to multiple processes. Each process has a process number (process ID).

It should be understood that in the embodiments of the present application, "at least one of the following" or similar expressions refer to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can represent: a, b, c, a and b, a and c, b and c, or a, b and c, where a, b, c can be single or multiple. "Multiple" refers to two or more. "And/or" is used to describe the association relationship of associated objects, indicating that three relationships can exist. For example, A and/or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character "/" generally indicates that the previous and next associated objects are in an "or" relationship.

In addition, it should be understood that, in the description of this application, words such as "first" and "second" are only used for the purpose of distinguishing the description, and cannot be understood as indicating or implying relative importance, nor can they be understood as indicating or implying an order.

It should be understood that the hardware structure of the electronic device can be as shown in Figure 2, and the software system architecture can be as shown in Figure 3, wherein the software programs and/or modules corresponding to the software system architecture in the electronic device can be stored in the memory 240, and the processor 230 can run the software programs and applications stored in the memory 240 to execute the process of a component refresh method provided in an embodiment of the present application.

In order to facilitate understanding of a component refresh method provided by the present application, the implementation process of the method provided by the present application is introduced below in combination with the contents shown in Figures 4 to 7. The embodiment of the present application is applicable to the scenario where components are displayed on the desktop of an electronic device; wherein the components may be, for example, components in service cards, desktop widgets, etc. that require data refresh, and may be used to display some services or content of concern to users on some display interfaces of electronic devices. It should be noted that the embodiment of the present application does not limit the style, type, display position, etc. of the components; taking cards as an example, the style of the cards may be 1×2 style, 2×2 style, and the color of the cards may be blue, red, etc.

In a possible embodiment, refer to FIG4, which is a schematic diagram of a scenario of a component refresh method provided in an embodiment of the present application. In the following embodiments, a service card (referred to as "card") is used as an example, and the scenario may include: a card user 401, a card management service 402, a card data agent 403, a card provider 404A, and a data provider 404B. The card user 401, the card management service 402, the card provider 404A, and the data provider 404B in FIG4. Exemplarily, the card user 401 may start a timed task based on the card refresh strategy to periodically trigger the card refresh; the card management service 402 may subscribe to or query data from the card data agent 403 in response to the refresh request of the card user 401; the card provider 404A and/or the data provider 404B may publish data to the card data agent 403; after the card management service 402 receives the return data from the card data agent 403, it may continue to return data to the card user 401. As can be seen from FIG. 4 , in the embodiment of the present application, a card data agent 403 may also be provided, and the card data agent 403 may be used to provide but not limited to the following capabilities:

(1) Define a uniform resource identifier (URI) and a corresponding data format. In some possible embodiments, the card data agent 403 can implement agents for various types of cards by defining URIs and corresponding data formats. For example, the URI of a card for a weather app and the weather data format corresponding to the weather app can be defined; the URI of a card for a calendar app and the date data format corresponding to the calendar app can also be defined; the URI of a card for a sports and health app and the step data format corresponding to the sports and health app can also be defined. In this way, the card management service 402 can subscribe to data from the card data agent 403 based on the URI of the data to be subscribed; and the card provider 404A and/or the data provider 404B can use the defined URI and the corresponding data format to publish updated data to the card data agent 403.

In some possible embodiments, data is usually in the form of a database (key-value) that stores data in key-value pairs; wherein key can be understood as a URI, such as the data of a sports health APP, and value can be understood as the specific data corresponding to the key, such as json (a data format) data, such as the number of steps (stepcount: 9999), date (date: 05/05), and health state (healthstate: normal). Exemplarily, the card management service 402 can transmit a URI to the card data agent 403, and receive the callback data through a callback function (callback); taking the card provider 404A as an example, when publishing data, the card provider 404A can transmit a URI and the specific data corresponding to the URI, so that the card data agent 403 can store the data published by the card provider 404A for subscription by the card management service 402.

(2) Provide a standardized SDK interface; the SDK interface can be used for subscription, query and access of data publishing. Referring to the module diagram shown in FIG. 1a , the card data agent 403 can also provide a communication adaptation layer; the communication adaptation layer can be provided by the SDK and is responsible for communicating with the card provider 404A and/or the data provider 404B to receive the data published by the card provider 404A and/or the data provider 404B; It can also be responsible for communicating with the card management service 402 to receive data subscriptions from the card management service 402 and send refreshed data to the card management service 402 .

(3) Providing data storage. In some possible embodiments, the card data agent 403 may also provide centralized storage or distributed storage. For example, the card data agent 403 may store the following data: exercise steps, power (including but not limited to local devices and distributed devices), weather, heart rate, calendar, etc.

(4) Providing necessary data access permission checking capabilities. In some embodiments, the card data agent 403 may allow some verified data providers 404B to publish data, thereby ensuring the security and accuracy of card data refresh.

Among them, the card user 401 can be understood as the host application of the card, for example, it can be a desktop APP or desktop process, a negative one screen APP or a negative one screen process, etc.

In some possible embodiments, after creating a card, the card user 401 may trigger sending a subscription request to the card data agent 403 through the card management service 402. In an optional embodiment, the subscription request may include a card identifier, and the card identifier may be used by the card data agent 403 to return the subscribed card data to the card user 401 based on the card identifier. In another optional embodiment, the subscription request may include a card identifier and a subscribed data type, and the data type may be used to indicate the specific data type of the card subscribed by the card user 401, such as a step count data type, a date data type, etc.

In another possible embodiment, refer to FIG. 5, which is another scenario diagram of a component refresh method provided by an embodiment of the present application. The scenario may include the card user 401, the card provider 404A and the data provider 404B in FIG. 4; and the card data agent 403 in the scenario may be integrated into the card management service, for example, may be referred to as the card management service 402'. It can be understood that the card management service 402' can not only implement the logical functions of the card management service 402 introduced in FIG. 4, but also implement the logical functions of the card data agent 403 introduced in FIG. 4. Exemplarily, the card user 401 may start a timed task based on the card refresh strategy to periodically trigger the card refresh; the card management service 402' may receive the refresh request of the card user 401, and in response to the refresh request, perform local data subscription and query. The card provider 404A and/or the data provider 404B may publish data to the card management service 402'; after the card management service 402' detects that there is newly published data in the local cache, it may return data to the card user 401. Among them, the logical functions of the card management service 402' can refer to the logical functions of the card management service 402 and the card data agent 403 introduced in Figure 4, which will not be repeated here.

Taking the scenario described in FIG. 4 as an example, FIG. 6 is a flow chart of a component refresh method provided in an embodiment of the present application. The flow may include the following steps:

Step 601a, sports health publishes data. In some possible embodiments, the sports health APP can be used as a data provider for the card corresponding to the sports health APP. In the embodiment of the present application, the sports health APP can respond to the change of the number of steps and publish the latest number of steps to the card data agent in a timely manner.

Step 601b, the power management publishes the current system power. In some possible embodiments, the data source of the power management can be the data provider of the card corresponding to the data source of the power management. In the embodiment of the present application, the data source of the power management can be, for example, the operating system of the electronic device, and the data source of the power management can publish the current system power to the card data agent in a timely manner in response to the change of power.

It can be understood that after the card data agent receives the data published by the data provider through step 601a or step 601b, it can cache the data.

Step 602, the card provider sets a refresh policy. In some possible embodiments, the card provider can set a refresh policy based on the data type, etc.; and can publish data according to the refresh policy. For example, the refresh policy can be based on a cycle or time, etc. For example, the card corresponding to the calendar APP can set a refresh policy according to a time point, and update the card corresponding to the calendar APP at 00:00 every morning. For another example, the refresh policy can also be based on a trigger event, and the trigger event can include but is not limited to: the user clicks on the card's operation instruction, the desktop process displays a trigger event including the desktop interface of the card, etc.

Step 603, the card data agent detects that the refresh policy is satisfied. In some possible embodiments, when the desktop process detects the user's operation of adding a card in the desktop process, in response to the operation, it can subscribe to data from the card data agent. Among them, the desktop process can carry the URI corresponding to the card when subscribing to data from the card data agent according to the specific type of the card. For example, if the card is a card of a sports health APP, the URI can be the data of the sports health APP, so that at least one data corresponding to the data format defined by the sports health APP can be obtained, such as but not limited to: "stepcount: 9999", "date: 05/05", "healthstate: normal".

In some other possible embodiments, after receiving the data published by the card provider and/or data provider, the card data agent may also return the received published data to the card user who subscribes to the data based on the card user's subscription event to the data.

Step 604a: The card data agent refreshes the number of steps to the desktop process.

Step 604b: The card data agent refreshes the current system power to the desktop process.

Step 605: The desktop process updates the card.

The method provided by the embodiment of the present application can solve the problem that the card provider process must be started for card refresh, thereby reducing the power consumption and memory problems caused by card refresh. In addition, the method can achieve the decoupling of the life cycle of the card user and the card provider, thereby achieving self-refresh without relying on the data provider. In addition, the method can achieve the card provider without integrating the SDK of other data providers by providing a card data agent, and the card data agent can achieve the connection between the card provider and the data provider, thereby reducing the complexity of development.

In a possible implementation, FIG7 is another flow chart of a component refresh method provided in an embodiment of the present application. The method can be applied to an electronic device including a component, and the process may include the following steps:

Step 701: Receive component data published by a data provider of the component.

In an optional embodiment, the electronic device may include a component data agent and a component management service functional unit; in this scenario, the component data agent may be responsible for receiving the component data.

In another optional embodiment, the electronic device may include a functional unit integrating a component data agent and a component management service; in this scenario, the integrated functional unit may be responsible for receiving the component data.

Step 702: In response to a subscription event to the component data, the component data is transmitted to a component user, and the component user is used to refresh the component data and display it in the component; wherein the subscription event is used to instruct the component user to subscribe to the refresh of the component data.

In an optional embodiment, in a scenario where the electronic device includes a component data proxy and a component management service functional unit, the component user can subscribe to the component data from the component data proxy through the component management service. In this way, the component data proxy can return the component data sent by the data provider to the component user through the component management service. Exemplarily, when sending a subscription request, the component user can indicate the component ID, or can indicate the component ID and the type of data subscribed; similarly, when publishing data, the data provider can indicate the component ID, or can indicate the component ID and the type of data included in the component. Therefore, the card data proxy can achieve accurate component refresh based on the component ID, or based on the component ID and the data type.

In another optional embodiment, in a scenario where the electronic device includes a functional unit that integrates a component data proxy and a component management service, a component user can subscribe to component data from the integrated functional unit.

Based on the above embodiments, the present application also provides an electronic device, which includes multiple functional modules; the multiple functional modules interact with each other to implement the functions performed by the electronic device in each method described in the embodiments of the present application. The multiple functional modules can be implemented based on software, hardware, or a combination of software and hardware, and the multiple functional modules can be arbitrarily combined or divided based on the specific implementation. For example, steps 601a to 605 performed by the electronic device in the embodiment shown in Figure 6 are executed; it can be understood that the card provider and card data agent shown in Figure 6 are logical functional units in the electronic device, which can be implemented by the processor in the electronic device, and the desktop process, sports health, power management, etc. are applications in the electronic device, which can also be implemented by the processor in the electronic device. Alternatively, steps 701 to 702 performed by the electronic device in the embodiment shown in Figure 7 are executed. It can be understood that the electronic device can also include a logical functional unit of a card management service, or a functional unit integrating a card management service and a card data agent.

Based on the above embodiments, the present application also provides an electronic device, which includes at least one processor and at least one memory, wherein the at least one memory stores computer program instructions, and when the electronic device is running, the at least one processor performs the functions performed by the electronic device in each method described in the embodiments of the present application. For example, steps 601a to 605 performed by the electronic device in the embodiment shown in FIG. 6 are executed; it can be understood that the card provider and the card data agent shown in FIG. 6 are logical function units in the electronic device, which can be implemented by the processor in the electronic device, and the desktop process, sports health, power management, etc. are applications in the electronic device, which can also be implemented by the processor in the electronic device. Alternatively, steps 701 to 702 performed by the electronic device in the embodiment shown in FIG. 7 are executed. It can be understood that the electronic device can also include a logical function unit of a card management service, or a function unit integrating a card management service and a card data agent. Based on the above embodiments, the present application also provides a computer program product, which includes: a computer program (also referred to as a code, or an instruction), when the computer program is executed, the computer executes the methods described in the embodiments of the present application.

Based on the above embodiments, the present application further provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a computer, the computer executes the methods described in the embodiments of the present application.

Based on the above embodiments, the present application further provides a chip, which is used to read a computer program stored in a memory to implement the methods described in the embodiments of the present application.

Based on the above embodiments, the present application provides a chip system, which includes a processor for supporting a computer device to implement The various methods described in the embodiments of the present application. In a possible design, the chip system also includes a memory, which is used to store the necessary programs and data of the computer device. The chip system can be composed of a chip, or it can include a chip and other discrete devices. It should be understood by those skilled in the art that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

The present application is described with reference to the flowchart and/or block diagram of the method, device (system), and computer program product according to the present application. It should be understood that each process and/or box in the flowchart and/or block diagram, as well as the combination of the process and/or box in the flowchart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the function specified in one process or multiple processes in the flowchart and/or one box or multiple boxes in the block diagram.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the scope of protection of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims (11)

A component refresh method, characterized by comprising: Receive component data published by a data provider of the component; In response to a subscription event to the component data, the component data is transmitted to a component user, and the component user is used to refresh the component data and display it in the component; wherein the subscription event is used to instruct the component user to subscribe to the refresh of the component data. The method according to claim 1 is characterized in that the data provider is an application APP, a system or a server; wherein the APP includes the APP to which the component belongs, or the APP associated with the component data of the component. The method according to claim 1 or 2, characterized in that the transmitting the component data to the component user comprises: The component data is transmitted to a component user through a component management service, and the component management service is used to manage the component. The method according to any one of claims 1 to 3, characterized in that, before transmitting the component data to the component user in response to a subscription event for the component data, the method further comprises: The subscription event is detected, the subscription event is used to indicate that a subscription request sent by the component user is received, the subscription request includes a component identifier of the component, and the subscription request is used to indicate a subscription to a refresh of the component based on the component identifier. The method according to claim 4 is characterized in that the subscription request also includes the subscribed data type. The method according to any one of claims 1 to 5, characterized in that the component is a service card or a widget. The method according to any one of claims 1 to 6 is characterized in that the component user is a host APP. The method according to claim 7, characterized in that the host APP includes one or more of the following APPs: Desktop APP, or negative one screen APP, notification bar APP. An electronic device, characterized in that it comprises at least one processor, wherein the at least one processor is coupled to at least one memory, and the at least one processor is used to read a computer program stored in the at least one memory to execute the method as described in any one of claims 1 to 8. A computer-readable storage medium, characterized in that instructions are stored in the computer-readable storage medium, and when the computer-readable storage medium is run on a computer, the computer is caused to execute the method as claimed in any one of claims 1 to 8. A computer program product comprising instructions, characterized in that when the computer program product is run on a computer, the computer is caused to execute the method according to any one of claims 1 to 8.