Method for determining display state and electronic device

Abstract

Embodiments of the present application are applicable to the technical field of data processing, and provide a display state determination method and electronic equipment. The method is applied to an electronic device and includes the following steps. In response to a first operation, a first application sends a first parameter to a second application. The first parameter is used to indicate a display state of a first component. The display state includes a hidden state and a visible state. The first application is an application that displays the first component. The second application is an application that provides display data for the first component. The first operation is used to modify the display state of the first component. The first component is a component generated based on a micro skill Widget. The second application determines the display state of the first component based on the first parameter. In this way, the second application that provides display data for the micro skill Widget component can determine the display state of the micro skill Widget component based on the first parameter. Compared with a traditional method, the embodiments of the present application enrich the functions of the micro skill Widget.

Description

Methods for determining display status and electronic devices Technical Field

[0001] This application relates to the field of data processing, and more specifically, to a method for determining a display state and an electronic device. Background Technology

[0002] A widget is a small component in the Android system that typically allows the content displayed by one application to be shown on the screen of another application. For example, the weather widget displayed on the home screen is a component that displays content from the weather application via a widget.

[0003] However, at present, the functionality of Widgets is limited and cannot meet the growing needs of users.

[0004] Therefore, how to enrich the functionality of Widgets has become an urgent problem to be solved. Summary of the Invention

[0005] This application provides a method for determining the display state, which can enrich the functionality of Widgets.

[0006] Firstly, a method for determining a display state is provided, which is applied to an electronic device and includes:

[0007] In response to the first operation, the first application sends a first parameter to the second application. The first parameter is used to indicate the display state of the first component. The display state includes a hidden state and a visible state. The first application is the application that displays the first component, and the second application is the application that provides display data for the first component. The first operation is used to modify the display state of the first component. The first component is a component generated based on MicroWidget.

[0008] The second application determines the display state of the first component based on the first parameter.

[0009] Among them, the first application is equivalent to the Widget host application, the second application is equivalent to the Widget provider application, and the first component is equivalent to the Widget component.

[0010] The method for determining the display state provided in this application embodiment is applied in an electronic device and includes: in response to a first operation, a first application sends a first parameter to a second application, the first parameter being used to indicate the display state of a first component, the display state including a hidden state and a visible state, the first application being an application that displays the first component, the second application being an application that provides display data for the first component, the first operation being used to modify the display state of the first component, the first component being a component generated based on a Widget, and the second application determining the display state of the first component based on the first parameter. Thus, the second application that provides display data for the Widget component can determine the display state of the Widget component based on the first parameter. Compared with traditional methods, this application embodiment enriches the functionality of the Widget.

[0011] In conjunction with the first aspect, in some embodiments of the first aspect, the electronic device includes a first module, the first module includes a first unit, and a first application sends a first parameter to a second application, including: the first application sends the first parameter to the first unit in the first module; the first unit of the first module receives the first parameter and sends the first parameter to the second application.

[0012] The first module is equivalent to the Widget lifecycle control module in the basic service layer. The first unit is equivalent to the lifecycle management unit in the Widget lifecycle control module.

[0013] In conjunction with the first aspect, in some embodiments of the first aspect, the first module further includes a second unit. The first unit of the first module receives a first parameter and sends the first parameter to a second application, including: the first unit receiving the first parameter instructs the second unit to determine whether the state of the electronic device meets a preset condition; if the state of the electronic device meets the preset condition, the second unit instructs the first unit to send the first parameter to the second application.

[0014] The second unit is equivalent to the rule execution unit.

[0015] The method for determining the display state provided in this application embodiment first instructs the second unit to determine whether the state of the electronic device meets preset conditions when the first application sends the first parameter to the second application. If the state of the electronic device meets the preset conditions, the first unit is then instructed to send the first parameter to the second application. This is equivalent to sending the first parameter only when the state of the electronic device meets the preset conditions, so that the second application can determine the display state of the Widget component based on the first parameter. This avoids the situation where the second application occupies system resources when determining the display state of the Widget component based on the first parameter when the state of the electronic device is not suitable.

[0016] In conjunction with the first aspect, in some embodiments of the first aspect, the aforementioned preset conditions include:

[0017] The first component is a component from a preset list;

[0018] The time interval between two consecutive displays of the first component is less than the preset time interval;

[0019] The battery level of the electronic device is higher than the preset battery threshold;

[0020] The temperature of the electronic device is lower than the preset temperature threshold.

[0021] It is understandable that when the battery level of an electronic device is higher than a preset battery level threshold and the temperature of the electronic device is lower than a preset temperature threshold, the electronic device is in normal working condition.

[0022] The preset list can be a list determined based on the user's selection.

[0023] In conjunction with the first aspect, in some embodiments of the first aspect, preset conditions are stored in a cloud server, and the second unit determines whether the state of the electronic device meets the preset conditions, including: the second unit requests the cloud server to obtain the preset conditions; the cloud server sends the preset conditions to the second unit; and the second unit determines whether the state of the electronic device meets the preset conditions.

[0024] The method for determining the display state provided in this application embodiment stores preset conditions in a cloud server. When the second unit determines whether the state of the electronic device meets the preset conditions, it needs to request the preset conditions from the cloud server. Only after receiving the preset conditions sent by the cloud server can it determine whether the state of the electronic device meets the preset conditions. Since the preset conditions are stored in the cloud server, the preset conditions will not be lost due to storage failure in the electronic device. This can improve the security of the preset conditions and thus improve the reliability of determining whether the state of the electronic device meets the preset conditions. At the same time, storing the preset conditions in the cloud server ensures that storing the preset conditions does not occupy the memory of the electronic device.

[0025] In conjunction with the first aspect, in some embodiments of the first aspect, preset conditions are stored in a second unit, and the second unit determines whether the state of the electronic device meets the preset conditions, including: the second unit reading the pre-stored preset conditions; and the second unit determining whether the state of the electronic device meets the preset conditions.

[0026] The method for determining the display state provided in this application embodiment stores preset conditions in a second unit. When the second unit determines whether the state of the electronic device meets the preset conditions, it only needs to read the pre-stored preset conditions to determine whether the state of the electronic device meets the preset conditions. In this way, the electronic device does not need to obtain the preset conditions from the cloud server, avoiding the situation where the electronic device cannot obtain the preset conditions due to communication failure between the electronic device and the cloud server.

[0027] In conjunction with the first aspect, in some embodiments of the first aspect, the value of the first parameter includes a first value, which is used to indicate that the first component is in a visible state. The second application determines the display state of the first component based on the first parameter, including: the second application parses the first parameter to obtain the value of the first parameter; if the value of the first parameter is the first value, then the display state of the first component is determined to be a visible state.

[0028] It's understandable that the first parameter can be the `extras` parameter in the intent, where the intent is resolved by overriding the `OnReceive()` function of the App Widget Provider base class. The value of the first parameter can refer to the value of the key "WIDGET_LIFECYCLE" in the `extras` parameter. If the value of the key "WIDGET_LIFECYCLE" in the `extras` parameter is "Onshow", then the first parameter takes the first value.

[0029] In conjunction with the first aspect, in some embodiments of the first aspect, the value of the first parameter further includes a second value, the second value being used to indicate that the first component is in a hidden state, and the method further includes: if the value of the first parameter is the second value, then determining that the display state of the first component is a hidden state.

[0030] Understandably, the first parameter can be the `extras` parameter in the intent, where the intent is resolved by overriding the `OnReceive()` function of the App Widget Provider base class. The value of the first parameter can refer to the value of the key "WIDGET_LIFECYCLE" in the `extras` parameter. If the value of the key "WIDGET_LIFECYCLE" in the `extras` parameter is "Onhide", then the first parameter takes the second value.

[0031] In conjunction with the first aspect, in some embodiments of the first aspect, the method further includes: if the display state of the first component is visible, updating the first component according to a preset period; if the display state of the first component is hidden, stopping updating the first component according to the preset period.

[0032] The method for determining the display state provided in this application embodiment updates the first component according to a preset cycle when the first component is determined to be in a visible state. Since users typically have a higher willingness to view the content of the first component when it is visible, updating the first component according to the preset cycle better aligns with user preferences and improves user experience. Conversely, updating the first component according to the preset cycle is stopped when it is in a hidden state. Since users have a lower willingness to view the content of the first component when it is hidden, stopping the update can reduce the system resources consumed by updating the first component in the electronic device.

[0033] In conjunction with the first aspect, in some embodiments of the first aspect, the method further includes: determining the number of times the first component is displayed based on the display state of the first component.

[0034] For example, since the first application sends the first parameter to the second application in response to the first operation that modifies the display state of the first component, each time the first parameter is sent to the second application, the display state of the first component changes. The electronic device only needs to count the number of times the first parameter is received to determine the number of times the first component is displayed.

[0035] In conjunction with the first aspect, in some embodiments of the first aspect, the method further includes: a second application determining the number of times the first component is displayed based on the display state of the first component.

[0036] It is understandable that the second application is an application that provides display data for the first component, that is, the second application is an application that provides data for the first component. Therefore, the second application can determine the number of times the first parameter is obtained by statistics.

[0037] In conjunction with the first aspect, in some embodiments of the first aspect, the first component is a MicroWidget component, the first application is a MicroWidget host application, and the second application is an application that provides display data for the MicroWidget component.

[0038] In conjunction with the first aspect, in some embodiments of the first aspect, the method further includes: in response to a second operation, a first application sending a second parameter to a second application, the second parameter indicating the addition of a first component; the second application sending first data to the first application based on the second parameter, the first data being data for adding the first component; and the first application adding the first component based on the first data.

[0039] The second parameter can refer to the onEnable() function, and the first data can refer to the remoteViews required to add the Widget component.

[0040] In conjunction with the first aspect, in some embodiments of the first aspect, the above-mentioned response to the second operation, the first application sending the second parameter to the second application, includes: in response to the second operation, the first application sending the second parameter and the third parameter to the second application, the third parameter being used to indicate updating the first component; the second application sending second data to the first application based on the third parameter, the second data being data for updating the first component; and the first application updating the first component based on the second data.

[0041] The second parameter can refer to the onEnable() function, and the second data can refer to the remoteViews required to update the Widget component.

[0042] In conjunction with the first aspect, in some embodiments of the first aspect, the method further includes: a first application sending a third parameter to a second application at a preset period, the third parameter being used to indicate updating the first component; the second application sending second data to the first application based on the third parameter, the second data being data for updating the first component; and the first application updating the first component based on the second data.

[0043] The third parameter can refer to the onAppWidgetOptionsChanged() function, and the second data can refer to the remoteViews required to update the Widget component.

[0044] The method for determining the display status provided in this application embodiment involves a first application sending a third parameter to a second application according to a preset period. The third parameter is used to indicate the updating of the first component. Based on the third parameter, the second application sends second data to the first application. The second data is the data for updating the first component. The first application updates the first component based on the second data. In this way, the first component can be updated periodically according to the preset period, thereby improving the timeliness of displaying the first component.

[0045] In conjunction with the first aspect, in some embodiments of the first aspect, the method further includes: in response to a third operation, the first application sends a third parameter to the second application, the third parameter being used to instruct the deletion of the first component; the second application clears the runtime data of the first component based on the third parameter.

[0046] The third parameter can refer to the onDisable() function and / or the onDeleted() function. Clearing the runtime data of the first component can include releasing resources or stopping background services to clean up system resources, or releasing all Widget component resources.

[0047] For example, in the onDeleted() function with the third parameter, clearing the running data of the first component can mean releasing resources or stopping background services to clean up system resources.

[0048] For example, in the onDisable() function with the third parameter, clearing the runtime data of the first component can mean releasing all Widget component resources.

[0049] Secondly, a display state determination apparatus is provided, including a unit for performing any of the methods in the first aspect. This apparatus may be a server, a terminal device, or a chip within a terminal device. The apparatus may include an input unit and a processing unit.

[0050] When the device is a terminal device, the processing unit may be a processor, and the input unit may be a communication interface; the terminal device may also include a memory for storing computer program code, which, when the processor executes the computer program code stored in the memory, causes the terminal device to perform any of the methods in the first aspect.

[0051] When the device is a chip within a terminal device, the processing unit can be an internal processing unit of the chip, and the input unit can be an output interface, pin, or circuit, etc.; the chip may also include a memory, which can be an internal memory of the chip (e.g., a register, cache, etc.) or an external memory (e.g., a read-only memory, random access memory, etc.); the memory is used to store computer program code, and when the processor executes the computer program code stored in the memory, the chip performs any of the methods in the first aspect.

[0052] In one possible implementation, the memory is used to store computer program code; the processor executes the computer program code stored in the memory, and when the computer program code stored in the memory is executed, the processor is used to perform: in response to a first operation, a first application sends a first parameter to a second application, the first parameter indicating the display state of a first component, the display state including a hidden state and a visible state, the first application being an application that displays the first component, the second application being an application that provides display data for the first component, the first operation modifying the display state of the first component, the first component being a component generated based on a micro-widget; the second application determines the display state of the first component based on the first parameter.

[0053] Thirdly, a computer-readable storage medium is provided, the computer-readable storage medium storing computer program code, which, when executed by a function calling device, causes the function calling device to perform any of the display state determination methods in the first aspect.

[0054] Fourthly, a computer program product is provided, the computer program product comprising: computer program code, which, when executed by a function calling device, causes the function calling device to perform any of the apparatus methods in the first aspect.

[0055] The method for determining the display state provided in this application embodiment is applied in an electronic device and includes: in response to a first operation, a first application sends a first parameter to a second application, the first parameter being used to indicate the display state of a first component, the display state including a hidden state and a visible state, the first application being an application that displays the first component, the second application being an application that provides display data for the first component, the first operation being used to modify the display state of the first component, the first component being a component generated based on a Widget, and the second application determining the display state of the first component based on the first parameter. Thus, the second application that provides display data for the Widget component can determine the display state of the Widget component based on the first parameter. Compared with traditional methods, this application embodiment enriches the functionality of the Widget. Attached Figure Description

[0056] Figure 1 is a software structure block diagram of an electronic device at present;

[0057] Figure 2 is a software structure block diagram of an electronic device applicable to an embodiment of this application;

[0058] Figure 3 is a schematic diagram of an application scenario provided by an embodiment of this application;

[0059] Figure 4 is a flowchart illustrating a method for determining a display status according to an embodiment of this application;

[0060] Figure 5 is a flowchart illustrating the method for determining whether to transmit an exposure event according to an embodiment of this application;

[0061] Figure 6 is a flowchart illustrating another method for determining the display status provided in an embodiment of this application;

[0062] Figure 7 is a flowchart illustrating the method for determining the type of event to be transmitted according to an embodiment of this application;

[0063] Figure 8 is a flowchart illustrating another method for determining the display status provided in an embodiment of this application;

[0064] Figure 9 is a schematic diagram of another application scenario provided by an embodiment of this application;

[0065] Figure 10 is a schematic diagram of another application scenario provided by an embodiment of this application;

[0066] Figure 11 is a flowchart illustrating another method for determining the display status provided in an embodiment of this application;

[0067] Figure 12 is a flowchart illustrating another method for determining the display status provided in an embodiment of this application;

[0068] Figure 13 is a schematic diagram of a hardware system for an electronic device applicable to this application. Detailed Implementation

[0069] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0070] Hereinafter, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include one or more of that feature.

[0071] For ease of understanding, the examples provided are for reference only and are related to the concepts in the embodiments of this application.

[0072] 1. Widget.

[0073] A widget is a small component in the Android system that typically allows the content displayed in one application to be shown on the screen of another application. For example, the weather widget displayed on the home screen is a widget that displays content from a weather application on the home screen.

[0074] 2. Widget host application.

[0075] A widget host application can refer to the application that displays the relevant content. For example, when displaying content from a weather app on a desktop application, the widget host application refers to the desktop application.

[0076] 3. Provide Widget applications.

[0077] A widget application can refer to an application that provides the content to be displayed. For example, when displaying content from a weather application on a desktop application, the widget application refers to the weather application.

[0078] 4. Widget component.

[0079] A widget can refer to a component that displays information about the widget application on its host application. For example, when displaying content from a weather application on a desktop application, a widget is a component that displays the weather application's content on the desktop application.

[0080] Currently, electronic devices can display static information and provide interactive operations through widgets. By using widgets, developers can provide users with more convenient ways to view application information and perform related operations, improving the user experience. The functions that widgets can achieve include:

[0081] A. Add the Widget component to the Widget host application.

[0082] Electronic devices can add Widget components to their host application using the `onEnable()` function. When adding a Widget component, developers can perform initialization settings. These settings may include starting a background service or registering a broadcast receiver.

[0083] B. Update the Widget component.

[0084] Electronic devices can update widget components according to a preset period, thereby updating the widget components. For example, an electronic device can update the text and / or images displayed in a widget component according to a preset period. When the update time indicated by the preset period arrives, the electronic device calls the onUpdate() function to update the widget component.

[0085] C. Adjust the size of the Widget component.

[0086] Electronic devices can arrange and display widget components in different sizes. When the size of a widget component changes, the electronic device can call the onAppWidgetOptionsChanged() function to change the size of the widget component.

[0087] D. Remove the Widget component.

[0088] When a Widget component is removed from its host application, it typically performs cleanup operations, such as releasing resources or stopping background services. Electronic devices can call the `onDeleted()` function to perform these cleanup operations.

[0089] E. Release the Widget component.

[0090] It's understandable that a host application can include multiple widgets from the same application. For example, a desktop application might display two weather widgets. In this case, when the last weather widget is removed from the desktop application, its resources can be released. The electronic device can call the `onDisable()` function to release the widget's resources.

[0091] The following explanation, using the software structure diagram of the electronic device shown in Figure 1, illustrates how the electronic device implements the functions of the aforementioned Widget.

[0092] The software system of electronic devices can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. The following example uses the layered architecture of the Android system to illustrate the software structure of electronic devices.

[0093] As shown in Figure 1, the layered architecture of an electronic device divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0094] The application layer can include a series of application packages.

[0095] As shown in Figure 1, an application package may include a Widget host application and applications that provide Widget applications.

[0096] The Widget host application can refer to a desktop application or a negative one screen application; this application embodiment does not limit this. The Widget host application may include a Widget component module, which can be used to handle operations related to Widget components.

[0097] The application that provides the Widget can be an application that provides the display content of the Widget component. For example, the Widget host application can be a weather application, a calendar application, a music playback application, etc. This application embodiment does not limit this.

[0098] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0099] As shown in Figure 1, the application framework layer may include a Widget manager, etc.

[0100] The Widget Manager can be used to retrieve relevant data from the Widget-providing application based on update commands from the Widget host application. Furthermore, the Widget Manager can be used to manage the size of Widget components.

[0101] For example, after the Widget host application sends an update command to the Widget Manager, the Widget Manager broadcasts to multiple providing Widget applications. This broadcast carries at least one of the following functions: `onEnable()`, `onUpdate()`, `onAppWidgetOptionsChanged()`, `onDeleted()`, and `onDisable()`. Upon receiving this broadcast, the target providing Widget application for the Widget component to be updated retrieves the relevant business data and returns it to the Widget Manager. Based on this business data, the Widget Manager sends the aforementioned business data information to the Widget host application. The Widget host application then performs the corresponding operation based on this business data information.

[0102] It is understood that the aforementioned update instructions can instruct at least one of the following: adding a Widget component to a Widget host application, updating a Widget component, resizing a Widget component, removing a Widget component, and releasing a Widget component. For example, if the update instruction instructs that a Widget component be added to a Widget host application, the Widget Manager sends a broadcast carrying the `onEnable()` function to multiple providing Widget applications. After receiving the broadcast, the target providing Widget application parses it, obtains the `onEnable()` function, and then returns the business data required to add the Widget component to the Widget host application based on the `onEnable()` function. The Widget Manager then sends the business data to the Widget host application, enabling the Widget host application to display the Widget component based on the business data.

[0103] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for scheduling and managing the Android system.

[0104] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0105] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0106] A system library can include multiple functional modules.

[0107] The kernel layer is the layer between hardware and software. The kernel layer includes at least display drivers, camera drivers, audio drivers, sensor drivers, Wi-Fi drivers, etc.

[0108] It should be noted that the electronic device mentioned in the embodiments of this application may include more or fewer modules of the aforementioned electronic device. For example, the electronic device may also include a memory, a timer, etc.

[0109] Understandably, the aforementioned update instructions can instruct at least one of the following: adding a Widget component to the Widget host application, updating a Widget component, resizing a Widget component, removing a Widget component, and releasing a Widget component. In other words, at this stage, the functions a Widget can perform include adding, updating, resizing, removing, and releasing a Widget component. Widgets do not support the functionality of counting the number of times a Widget component is displayed.

[0110] In view of this, the present application provides a method for determining the display state, applied in an electronic device, comprising: responding to a first operation, a first application sending a first parameter to a second application, the first parameter being used to indicate the display state of a first component, the display state including a hidden state and a visible state, the first application being an application that displays the first component, the second application being an application that provides display data for the first component, the first operation being used to modify the display state of the first component, the first component being a component generated based on a Widget, and the second application determining the display state of the first component based on the first parameter. Thus, the second application that provides display data for the Widget component can determine the display state of the Widget component based on the first parameter. Compared with traditional methods, the present application enriches the functionality of the Widget.

[0111] The method for determining the display state provided in this application can be applied to electronic devices. Optionally, the electronic device includes a terminal device, which can also be called a terminal, user equipment (UE), mobile station (MS), mobile terminal (MT), etc. The terminal device can be a mobile phone, smart TV, wearable device, tablet computer, computer with wireless transceiver function, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, etc. The embodiments of this application do not limit the specific technology or device form used in the terminal device.

[0112] The software system of an electronic device using the display state determination method provided in this application embodiment can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses the layered architecture Android system as an example to exemplify the software structure of the electronic device.

[0113] The layered architecture of electronic devices divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer. Optionally, a basic services layer may be included between the application layer and the application framework layer.

[0114] For example, the software architecture block diagram of an electronic device can be shown in Figure 2.

[0115] The application layer can include a series of application packages.

[0116] For example, as shown in Figure 2, there is a Widget host application and a Widget provider application.

[0117] The Widget host application can refer to a desktop application or a negative one screen application; this embodiment of the application does not impose any limitation on this. The following explanation uses a desktop application as an example. A desktop application may include a Widget component module and an exposure processing module. The Widget component module can be used to obtain relevant data from the providing Widget application and process this data. For example, it can display this relevant data on the desktop.

[0118] The exposure handling module is used to transmit exposure events. An exposure event can refer to an event that displays a Widget component. For example, if a Widget component is on the -1 screen and the electronic device is currently displayed on the main interface of a desktop application, when the electronic device responds to the user's swipe gesture and switches from the main interface of the desktop application to displaying the -1 screen, the Widget component is exposed once, which is equivalent to an exposure event occurring.

[0119] The application that provides the Widget can be an application corresponding to a component displayed on the Widget host application. Examples include weather applications, audio player applications, and calendar event applications. This application does not impose any limitations on this.

[0120] Optionally, the basic service layer includes a Widget lifecycle control module.

[0121] The Widget lifecycle control module can receive exposure events transmitted by the exposure processing module, and based on these exposure events, broadcast them by calling the Framework interface through the Widget Manager.

[0122] The Widget lifecycle control module can also obtain control rules and determine whether to call the broadcast sending interface in the Widget Manager to broadcast the exposure event.

[0123] The Widget lifecycle control module can obtain control rules from a cloud server or from a target address in an electronic device; this application embodiment does not impose any limitations on this.

[0124] The control rules may include whether the Widget component is allowed to obtain exposure counts, the minimum time interval between two exposures, whether exposure counts are allowed in low power mode, and whether exposure counts are allowed in high temperature mode.

[0125] For example, a Widget component can obtain the number of times it has been shown by calling the onShow() function. Each time the onShow() function is called, the Widget component is shown once.

[0126] For example, a Widget component can obtain the time difference between two consecutive calls to the onShow() function. If the time difference is greater than the minimum time interval mentioned above, the Widget component will be exposed twice; if the time difference is less than or equal to the minimum time interval mentioned above, the Widget component will be exposed once.

[0127] For example, a Widget component can obtain the remaining battery power of an electronic device. If the remaining battery power of the electronic device is greater than a preset battery power threshold, the Widget component will be exposed once when the onShow() function is called; if the remaining battery power of the electronic device is less than or equal to the preset battery power threshold, the onShow() function will not be called.

[0128] For example, a Widget component can obtain the temperature value from the electronic device's temperature sensor. If the temperature value is less than a preset temperature threshold, the Widget component will be exposed once when the onShow() function is called; if the temperature value is greater than or equal to the preset temperature threshold, the onShow() function will not be called.

[0129] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0130] As shown in Figure 2, the application framework layer may include a Widget manager, etc.

[0131] The Widget Manager can be used to retrieve relevant data from the Widget-providing application based on update commands from the Widget host application. Furthermore, the Widget Manager can be used to manage the size of Widget components.

[0132] For example, after the Widget host application sends an update command to the Widget Manager, the Widget Manager broadcasts to multiple providing Widget applications. This broadcast carries at least one of the following functions: `onEnable()`, `onUpdate()`, `onAppWidgetOptionsChanged()`, `onDeleted()`, `onDisable()`, `onShow()`, and `onHide()`. Upon receiving this broadcast, the target providing Widget application for the Widget component to be updated retrieves the relevant business data and returns it to the Widget Manager. Based on this business data, the Widget Manager sends the aforementioned business data information to the Widget host application. The Widget host application then performs the corresponding operation based on this business data information.

[0133] It is understood that the above update instructions can instruct at least one of the following: adding a Widget component to the Widget host application, updating a Widget component, adjusting the size of a Widget component, removing a Widget component, releasing a Widget component, exposing a Widget component, and hiding a Widget component.

[0134] For example, if an update command instructs the widget component to be exposed, the widget manager sends a broadcast containing the onShow() function to multiple widget-providing applications. Upon receiving the broadcast, the target widget-providing application parses it, retrieves the onShow() function, and determines that the widget component is in an exposed state, i.e., a displayed state, based on the onShow() function.

[0135] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for scheduling and managing the Android system.

[0136] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0137] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0138] The kernel layer is the layer between hardware and software. The kernel layer includes at least display drivers, camera drivers, audio drivers, sensor drivers, Wi-Fi drivers, etc.

[0139] It should be noted that the electronic device mentioned in the embodiments of this application may include more or fewer modules of the above-mentioned electronic device.

[0140] The application scenarios provided by the embodiments of this application are described below with reference to the accompanying drawings.

[0141] Figures 3(a) to 3(d) are schematic diagrams illustrating application scenarios of the display state determination method provided in this application embodiment. As shown in Figure 3(a), a weather component 10A1 is displayed on the desktop interface 10A of the electronic device. The desktop application can be a Widget host application, and the weather component can be a Widget component. At this time, the Widget component is visible, so the number of times the Widget component is exposed can be counted. The user slides the display interface 10A from left to right, as shown in Figure 3(b). In response to the user's sliding operation, the electronic device display interface switches to the interface 10B of the negative one screen as shown in Figure 3(c). At this time, the Widget component is invisible. When the user slides the interface 10B from right to left, as shown in Figure 3(d), in response to the user's sliding operation, the electronic device display interface switches back to the desktop interface shown in Figure 3(a). At this time, the Widget component is visible, so the number of times the Widget component is exposed can be counted again.

[0142] In this way, electronic devices can update widgets when they are exposed. When a widget is not exposed, users usually don't care whether its content has changed. Therefore, stopping updates to a widget when it is not exposed can avoid unnecessary updates that waste system resources.

[0143] Alternatively, electronic devices can count exposures each time a widget is exposed. In some cases, the widget application providing the widget may need to determine the number of times the widget is exposed in order to provide personalized services to the user based on that number of exposures.

[0144] It should be understood that the above are illustrative examples of application scenarios and do not limit the application scenarios of this application in any way.

[0145] The method for determining the display state provided in the embodiments of this application, with reference to Figures 4 to 12, will be described in detail below.

[0146] Figure 4 is a flowchart illustrating a method for determining a display state according to an embodiment of this application. The embodiment shown in Figure 4 focuses on describing how an electronic device adds a Widget component after adding the Widget component, and records the specific process of an exposure event. As shown in Figure 4, the method includes:

[0147] S101. In response to the user's operation of adding a Widget component, the Widget host application obtains the WidgetID from the Widget Manager.

[0148] Here, WidgetID refers to the identification information corresponding to the added Widget component. For example, if the user adds a Widget component, it could be a component of a weather application, and WidgetID would be the identification information corresponding to the weather application. The Widget host application cannot directly determine the Widget ID of a Widget component. Therefore, after the user adds a Widget component, the Widget host application can request the Widget ID from the Widget Manager.

[0149] The host application for a widget can refer to the application that displays widget components, such as a desktop application or an application displayed on the -1 screen. Components displayed on the desktop or -1 screen are typically widget components.

[0150] S102, Widget Manager assigns WidgetID.

[0151] The Widget Manager obtains the identification information, or WidgetID, corresponding to the Widget component added by the user based on the request from the Widget host application.

[0152] S103. The Widget Manager returns the WidgetID to the Widget Host Application.

[0153] S104. The Widget host application obtains the remoteViews corresponding to the WidgetID from the Widget Manager based on the WidgetID.

[0154] Among them, remoteViews can be used to indicate information such as the size and shape of Widget components.

[0155] S105, The Widget Manager sends a broadcast to the application that provides the Widget to add a component.

[0156] The add component broadcast can include the onEnable() function, which allows the Widget application to parse the onEnable() function after receiving the add component broadcast, and then perform initialization settings based on the onEnable() function, such as starting a background service or registering a broadcast receiver.

[0157] Providing a Widget application can refer to the application corresponding to the display content of the Widget component. For example, if the Widget component is a weather component, providing a Widget application can indicate the weather application; if the Widget component is a music playback component, providing a Widget application can indicate the music playback application.

[0158] S106, The Widget Manager broadcasts updates to the Widget application.

[0159] Understandably, when a Widget component is added for the first time, it will also be updated once. Therefore, when the Widget Manager sends an add component broadcast to the application providing the Widget, it will also send an update component broadcast simultaneously. The update component broadcast can include an `onUpdate()` function. After receiving the update component broadcast, the application providing the Widget can parse the `onUpdate()` function and then update the display content of the Widget component based on the `onUpdate()` function. For example, it can display text and images.

[0160] It should be noted that the Widget application can update the display content of the Widget component when the onUpdate() function is resolved, or it can update the display content of the Widget component according to a preset period. This application embodiment does not limit this.

[0161] For example, when a widget is added for the first time, the electronic device can update the widget's display content in response to this initial addition. This is equivalent to updating the widget's display content the first time it's shown. Then, the electronic device can update the widget's display content at preset intervals.

[0162] For example, after a Widget component has been added, the electronic device updates the displayed content of the Widget component at preset intervals.

[0163] S107. Provides Widget applications with access to remoteViews based on adding and updating component broadcasts.

[0164] In this context, remoteViews can be used to indicate information such as the size and shape of a Widget component. A Widget application (such as a weather application) can obtain information such as the size and shape of the displayed Widget component (e.g., the weather widget) as a remoteView.

[0165] S108, Provides Widget applications to return remoteViews to the Widget Manager.

[0166] Widget applications (such as weather applications) can provide remoteViews to the Widget Manager, which display information such as the size and shape of Widget components (such as the weather component).

[0167] S109. The Widget Manager sends an update command to the Widget Host Application, which carries remoteViews.

[0168] S110, Widget host application adds Widget components based on update command.

[0169] Widget host applications (such as desktop applications) can display widget components (such as weather widgets) on the desktop based on remoteViews carried in update instructions.

[0170] Thus, the electronic device has successfully added the Widget component to the Widget host application, meaning the Widget component is displayed on the Widget host application. Then, the Widget host application sends an exposure event to the application that provided the Widget, indicating that the Widget component has been exposed once. The steps from S111 to S129 are described in detail below.

[0171] S111, The Widget host application transmits the first event to the event dispatch unit in the Widget lifecycle control module.

[0172] The Widget lifecycle control module may include an event dispatch unit. When the event dispatch unit determines that the current event is an exposure event, it can pass the exposure event to other units in the Widget lifecycle control module, such as passing the exposure event to the lifecycle management unit.

[0173] Widget components in the host application can have two states: visible and hidden. Widget components in the host application are not always visible. For example, a desktop application might display multiple screens: a first screen, a second screen, and a third screen. The weather widget might be displayed on the second screen. When the user swipes to the second screen, the weather widget appears there and is visible. When the user swipes to the first or third screen, the weather widget is not displayed there and is hidden. When a widget transitions from hidden to visible, it is equivalent to the widget being exposed once.

[0174] After a user performs any action within the Widget host application, the Widget host application transmits a first event to the event dispatch unit in the Widget lifecycle control module. This first event can be used to indicate the current action performed by the user within the Widget host application. The Widget host application may include an exposure handling module. When a Widget component switches from a hidden state to a visible state, or vice versa, the exposure handling module can record the action and send the first event indicating the user's action to the event dispatch unit in the Widget lifecycle control module.

[0175] S112, The event distribution unit identifies whether the first event is an exposure event.

[0176] If the first event is the user's action of switching the Widget component from a hidden state to a visible state, then the first event is an exposure event; if the first event is the user's action of switching the Widget component from a visible state to a hidden state, then the first event is a hiding event.

[0177] If the first event is an exposure event, the event dispatch unit identifies and passes the exposure event to the lifecycle management unit in the Widget lifecycle control module, which is to execute S113.

[0178] S113. The event distribution unit transmits exposure events to the lifecycle management unit.

[0179] The Lifecycle Management Unit is the core unit in the Widget Lifecycle Control Module. It receives external events, such as exposure, hiding, and removal events. The Lifecycle Management Unit can also schedule the Rule Processing Management Unit, Rule Execution Management Unit, and Rule Execution Unit within the Widget Lifecycle Control Module to process external events and, based on the processing results, determine whether to call the framework interface to send an update broadcast.

[0180] After receiving the exposure event from the event distribution unit, the lifecycle management unit can retrieve a rule list from the rule execution management unit in the Widget lifecycle control module. This rule list includes multiple preset conditions. Only when the electronic device meets these preset conditions will it further transmit the Widget exposure event to the application providing the Widget.

[0181] S114. The lifecycle management unit obtains the rule list from the rule execution management unit.

[0182] It is understood that the rule list can be stored in a cloud server or in the Widget lifecycle control module, and this application embodiment does not limit this.

[0183] The rule execution management unit can be used to obtain a rule list, for example, from a cloud server or from a Widget lifecycle control module. This application embodiment does not impose any limitations on this. The following description uses the example of the rule execution management unit obtaining a rule list from a cloud server.

[0184] The rule list can include multiple preset conditions. For example, the rule list can include a whitelist of whether to allow Widget component modules in the Widget host application to call the onShow() function, the minimum time interval between two calls to the onShow() function, whether to allow the onShow() function to be called when the electronic device is in low power mode, and whether to allow the onShow() function to be called when the electronic device is in high temperature mode.

[0185] In one possible scenario, the rule list can be stored on a cloud server. The rule execution management unit can send a request to the cloud server to retrieve the rule list, causing the cloud server to respond to the request and return the rule list to the execution management unit. This is equivalent to executing S115 and S116.

[0186] S115. The rule execution management unit requests the rule list from the cloud server.

[0187] S116. The cloud server returns a list of rules to the rule execution management unit.

[0188] S117. The rule execution management unit creates a rule execution list based on the rule list.

[0189] A rule execution list is created based on multiple rules in a rule list. Within the rule execution list, the rules are arranged sequentially so that the electronic device can execute the corresponding rules in that order.

[0190] S118. The rule execution management unit returns the rule execution list to the lifecycle management unit.

[0191] S119, Lifecycle Management Unit Instructs Rule Processing Management Unit to Create Rule Processing Chain.

[0192] The rule processing chain can indicate the execution chain of preset rule order for treating injuries, and the electronic device can execute each rule in the rule processing chain in sequence.

[0193] S120, The rule processing management unit returns the rule processing chain to the lifecycle management unit.

[0194] S121, The rule processing management unit instructs the rule execution unit to execute the rule processing chain.

[0195] In one possible scenario, the execution order of the rules in the rule processing chain is as follows:

[0196] 1. Determine if the current Widget component is a whitelisted Widget component;

[0197] 2. Determine whether the time interval between two consecutive exposures of the Widget component is greater than the minimum time interval mentioned above;

[0198] 3. Are the electronic devices not in a low battery state?

[0199] 4. Are the electronic devices not in high-temperature mode?

[0200] Electronic devices can determine whether their state matches any of the rules in the rule list by following the execution order of the rules in the rule processing chain.

[0201] S122. The rule execution unit executes the rule processing chain to determine whether the state of the electronic device matches the i-th rule in the rule list.

[0202] The electronic device can determine whether its state matches a rule in the rule list by following the order of rules in the rule processing chain. If the electronic device's state matches a rule in the rule list, the matching result is returned to the rule processing management unit, which is to execute S123. If the electronic device's state does not match a rule in the rule list, the execution of the rule processing chain is returned to determine whether the electronic device's state matches the i-th rule in the rule list, which is to execute S122, until all rules in the rule list have been executed.

[0203] For example, as shown in Figure 5, the rule execution unit can first determine whether the state of the electronic device matches the first rule in the rule list, that is, whether the current Widget component is a Widget component in the whitelist.

[0204] If the current Widget component is a whitelisted Widget component, then it returns whether the state of the electronic device matches the second rule in the rule list, that is, whether the time interval between two consecutive exposures of the current Widget component is greater than the minimum time interval.

[0205] If the current widget is not a widget in the whitelist, it means that the electronic device's state matches the rule, and the matching result can be directly returned to the rule processing management unit, that is, S123 is executed. This matching result indicates that the exposure event should not be transmitted.

[0206] It should be noted that if the current widget is not a whitelisted widget, it means that the user does not care whether the current widget is exposed. Therefore, in this case, not transmitting the exposure event can reduce unnecessary resource consumption in electronic devices.

[0207] If it is determined that the time interval between two consecutive exposures of the current Widget component is greater than the minimum time interval, then the system returns to determine whether the state of the electronic device matches the third rule in the rule list, that is, whether the electronic device is in a low battery state.

[0208] If it is determined that the time interval between two consecutive exposures of the current Widget component is less than or equal to the minimum time interval, it means that the electronic device's state matches the rule, and the matching result can be directly returned to the rule processing management unit, that is, S123 is executed. This matching result indicates that the exposure event is not transmitted.

[0209] It's important to note that if the time interval between two consecutive exposures of the current widget component is less than or equal to the minimum time interval, it indicates that the two exposures occurred within a short period, possibly due to rapid screen swiping. This could be caused by user error or friction from other objects against the screen and does not accurately reflect the user's intent. Therefore, if the time interval between two consecutive exposures of the current widget component is less than or equal to the minimum time interval, the exposure event is not transmitted. This improves the accuracy of the determined exposure event.

[0210] If it is determined that the electronic device is not in a low battery state, then return to determine whether the electronic device's state matches the 4th rule in the rule list, that is, whether the electronic device is in high temperature mode.

[0211] If it is determined that the electronic device is in a low-battery state, it means that the electronic device's state matches the rule, and the matching result can be directly returned to the rule processing management unit, that is, S123 is executed. This matching result indicates that the exposure event should not be transmitted.

[0212] It should be noted that when electronic devices are low on power, they typically disable several lower-priority functions to extend their battery life. Therefore, by not transmitting exposure events when the battery is low, the remaining battery life can be extended, thus meeting user needs.

[0213] If it is determined that the electronic device is not in high-temperature mode, a matching result is returned to the rule processing management unit, which is to execute S123. This matching result indicates the transmission of the exposure event.

[0214] If it is determined that the electronic device is in high-temperature mode, a matching result is returned to the rule processing management unit, which is to execute S123. This matching result indicates that the exposure event should not be transmitted.

[0215] It should be noted that electronic devices are prone to malfunction when operating in high-temperature mode. Therefore, preventing the transmission of exposure events while the electronic device is in high-temperature mode can reduce the probability of malfunction.

[0216] S123. The rule execution unit returns the matching result to the rule processing management unit.

[0217] S124. The rule processing management unit returns the matching result to the lifecycle management unit.

[0218] S125. The lifecycle management unit determines whether to send an exposure event to the application providing the Widget based on the matching results.

[0219] As shown in S123 above, if the state of the electronic device matches all rules in the rule list, the returned matching result indicates that the exposure event is transmitted; if the state of the electronic device does not match any rule in the rule list, the returned matching result indicates that the exposure event is not transmitted.

[0220] If the matching result indicates that an exposure event should be transmitted, the lifecycle management unit can send the exposure event to the providing widget application. If the lifecycle management unit determines to send an exposure event to the providing widget application based on the matching result, it calls the Framework interface to send the exposure event, which is to execute S126.

[0221] If the matching result indicates that an exposure event is not being delivered, the lifecycle management unit will not send an exposure event to the application providing the widget.

[0222] S126. The lifecycle management unit calls the Framework interface through the Widget Manager.

[0223] It is understandable that data transfer between the Widget Manager and the application providing the Widget is done through the Framework interface. Therefore, when the lifecycle management unit passes exposure events to the application providing the Widget, the Framework interface should be called first.

[0224] S127. The Widget Manager returns the interface call result to the Lifecycle Management Unit.

[0225] In one possible scenario, if the Widget Manager successfully calls the Framework interface, the interface call result returned by the Widget Manager to the lifecycle management unit indicates a successful call to the Framework interface. In this case, the Widget Manager can call the Framework interface to send component exposure broadcasts to the application providing the Widget without having to call the Framework interface repeatedly.

[0226] In one possible scenario, such as a communication failure between the lifecycle management unit and the widget manager, where the widget manager fails to successfully call the framework interface, the interface call result returned by the widget manager to the lifecycle management unit indicates that the framework interface call was unsuccessful. In this case, the lifecycle management unit can call the framework interface again to ensure that the framework interface can be successfully called, thereby ensuring that component exposure broadcasts are sent to the widget application through the framework interface.

[0227] S128. The Widget Manager calls the Framework interface to send a component exposure broadcast to the application that provides the Widget.

[0228] The component exposure broadcast, also known as the App Widget Update broadcast, is used to indicate that the current widget component is visible, meaning that the current widget component has been exposed to the user. The App Widget Update broadcast can carry parameters such as the widget ID, the widget's host application identifier, and the onshow() function.

[0229] S129. Provide Widget application based on component exposure broadcast to determine whether the Widget component is exposed.

[0230] After receiving a component exposure broadcast, the widget provider can parse the broadcast to determine whether it indicates that the widget component should be exposed. For example, the widget provider can override the OnReceive() function of the App Widget Provider base class, and during the process of overriding the OnReceive() function, parse the parameters carried in the "intent" of "ACTION_APPWIDGET_UPDATA", such as the widget ID, the widget host application identifier, and the Onshow() function. If the "intent" carries the Onshow() function, the widget provider can determine that the widget component is in a visible state, that is, exposed to the user.

[0231] The above embodiments focus on describing the specific process by which an application providing a Widget in an electronic device determines whether a Widget component has been exposed. In one possible scenario, when a Widget component switches from a visible state to a hidden state, the application providing the Widget in the electronic device can also determine whether the Widget component is hidden by parsing the "intent" in "ACTION_APPWIDGET_UPDATA". This will be described in detail below with reference to the embodiment shown in Figure 6.

[0232] Figure 6 is a flowchart illustrating another method for determining the display state provided in an embodiment of this application. As shown in Figure 6, the method includes:

[0233] S201. In response to the user's action of hiding the Widget component, the Widget host application passes a second event to the event dispatch unit in the Widget lifecycle control module.

[0234] The Widget lifecycle control module may include an event dispatch unit. If the event dispatch unit determines that the current event is a hidden event, it may pass the hidden event to other units in the Widget lifecycle control module, such as passing the hidden event to the lifecycle management unit.

[0235] Widget components in the host application can have two states: visible and hidden. Widget components in the host application are not always visible. For example, a desktop application might display multiple screens: a first screen, a second screen, and a third screen. The weather widget might be displayed on the second screen. When the user swipes to the second screen, the weather widget appears there and is visible. When the user swipes to the first or third screen, the weather widget is not displayed there and is hidden. Switching from a visible to a hidden state is equivalent to hiding the widget once.

[0236] After a user performs any action within the Widget host application, the Widget host application transmits a second event to the event dispatch unit in the Widget lifecycle control module. This second event indicates the action performed by the user within the Widget host application. The Widget host application may include an exposure handling module. When a Widget component switches from a hidden state to a visible state, or vice versa, the exposure handling module can record the action and send the second event indicating the user's action to the event dispatch unit in the Widget lifecycle control module.

[0237] S202, The event distribution unit identifies whether the second event is an exposure event.

[0238] If the second event is the user's action of switching the Widget component from a hidden state to a visible state, then the second event is an exposure event; if the first event is the user's action of switching the Widget component from a visible state to a hidden state, then the second event is a hiding event.

[0239] If the second event is a hidden event, the event dispatch unit passes the hidden event to the lifecycle management unit in the Widget lifecycle control module, which is to execute S203.

[0240] S203. The event dispatch unit transmits hidden events to the lifecycle management unit.

[0241] The Lifecycle Management Unit is the core unit in the Widget Lifecycle Control Module. It receives external events, such as exposure, hiding, and removal events. The Lifecycle Management Unit can also schedule the Rule Processing Management Unit, Rule Execution Management Unit, and Rule Execution Unit within the Widget Lifecycle Control Module to process external events and, based on the processing results, determine whether to send a component hide broadcast.

[0242] S204. The lifecycle management unit determines whether to send a hidden event to the application that provides the Widget.

[0243] After receiving the hidden event from the event dispatch unit, the lifecycle management unit can first determine whether it is allowed to pass the hidden event to the application providing the Widget.

[0244] Understandably, the specific process of determining whether to allow the transmission of hidden events to the application providing the Widget is similar to the steps shown in S114 to S124 above, and will not be repeated here.

[0245] If it is determined that a hidden event should be sent to the application providing the Widget, then the framework interface is called to send a component hiding broadcast to the application providing the Widget, which is to execute S205.

[0246] S205. The lifecycle management unit calls the Framework interface through the Widget Manager.

[0247] It is understandable that data transfer between the Widget Manager and the application providing the Widget is done through the Framework interface. Therefore, when the lifecycle management unit passes hidden events to the application providing the Widget, the Framework interface should be called first.

[0248] S206. The Widget Manager returns the interface call results to the Lifecycle Management Unit.

[0249] In one possible scenario, if the Widget Manager successfully calls the Framework interface, the interface call result returned by the Widget Manager to the Lifecycle Management Unit indicates a successful call to the Framework interface. In this case, the Widget Manager can call the Framework interface to send a hidden exposure broadcast to the application providing the Widget without having to call the Framework interface repeatedly.

[0250] In one possible scenario, such as a communication failure between the lifecycle management unit and the widget manager, where the widget manager fails to successfully call the framework interface, the interface call result returned by the widget manager to the lifecycle management unit indicates that the framework interface was not successfully called. In this case, the lifecycle management unit can call the framework interface again to ensure that the framework interface can be successfully called, thereby ensuring that component hiding broadcasts are sent to the widget-providing application through the framework interface.

[0251] S207. The Widget Manager calls the Framework interface to send a component hiding broadcast to the application that provides the Widget.

[0252] The component hide broadcast, also known as the App Widget Update broadcast, is used to indicate that the current widget component is hidden, meaning it is concealed from the user. The App Widget Update broadcast can carry parameters such as the widget ID, the widget's host application identifier, and the Onhide() function.

[0253] S208. Provides Widget application-based component hiding broadcast to determine whether a Widget component is hidden.

[0254] After receiving a component hide broadcast, the widget provider can parse the broadcast to determine whether it indicates that the widget component should be hidden. For example, the widget provider can override the `OnReceive()` function of the `App Widget Provider` base class, and during this override, parse the parameters carried in the `intent` field of `ACTION_APPWIDGET_UPDATA`, such as the widget ID, the widget's host application identifier, and the `Onhide()` function. If the `intent` carries the `Onhide()` function, the widget provider can determine that the widget component is hidden, i.e., hidden from the user.

[0255] It's important to note that both component hide broadcasts and component show broadcasts are App Widget Update broadcasts. When a widget application receives an App Widget Update broadcast, it can determine the type of event being transmitted based on whether the function carried in the broadcast is Onhide() or Onshow().

[0256] For example, a Widget application can determine whether the event broadcast by the App Widget Update is an exposure event or a hidden event based on the embodiment shown in Figure 7.

[0257] As shown in Figure 7, it includes:

[0258] S21. Determine whether the first parameter carried by the "intent" parsed in the broadcast includes the first key value. The first parameter is used to indicate whether it carries a parameter indicating the current event type.

[0259] For example, a Widget application can override the OnReceive() function of the App Widget Provider base class to parse the intent and then determine whether the extras parameter (equivalent to the first parameter) in the intent contains the key value "WIDGET_LIFECYCLE".

[0260] If the first parameter contains the key value (equivalent to the first key value) "WIDGET_LIFECYCLE", then it further determines whether the value in "WIDGET_LIFECYCLE" is "Onshow", that is, it executes S22.

[0261] If the first parameter does not contain the key value "WIDGET_LIFECYCLE", then the super.onReceive() function is called, which is to execute S23.

[0262] S22. Determine if the value in "WIDGET_LIFECYCLE" is "Onshow".

[0263] If the value in "WIDGET_LIFECYCLE" is "Onshow", then the broadcast event is determined to be an exposure event, which means that S24 is executed.

[0264] If the value in "WIDGET_LIFECYCLE" is not "Onshow", then it is further determined that the value in "WIDGET_LIFECYCLE" is not "OnHide", that is, S25 is executed.

[0265] S23. Call the super.onReceive() function.

[0266] The `super.onReceive()` function can be used to create the functionality to receive broadcasts; it is a native function in the `App WidgetProvider` base class.

[0267] S24. The event transmitted by the broadcast is determined to be an exposure event.

[0268] S25. Determine whether the value in "WIDGET_LIFECYCLE" is "OnHide".

[0269] If the value in "WIDGET_LIFECYCLE" is "OnHide", then the broadcast event is determined to be a hidden event.

[0270] If the value in "WIDGET_LIFECYCLE" is not "OnHide", then the super.onReceive() function is called, which is to execute S23.

[0271] In this way, the Widget application can determine whether the currently transmitted event is a hidden event or an exposed event simply by parsing the value of the parameter carried in the same type of broadcast, reducing the complexity for electronic devices to determine hidden events and exposed events.

[0272] In some possible cases, based on the embodiments shown in Figures 4 to 7, the electronic device can also implement the function of modifying the size of the Widget component. This will be described in detail below with reference to the embodiment shown in Figure 8.

[0273] Figure 8 is a flowchart illustrating another method for determining the display state provided in an embodiment of this application. As shown in Figure 8, the method includes:

[0274] S301. In response to a user's operation of modifying the size of a Widget component, the Widget host application requests remoteViews from the Widget Manager.

[0275] Among them, remoteViews can be used to indicate information such as the size and shape of Widget components.

[0276] It is understood that the Widget component can change with the state of the electronic device or based on the user's operation, and the embodiments of this application do not limit this.

[0277] For example, the electronic device is a foldable electronic device. When the electronic device is in a folded state, a widget component can be displayed according to a first size. When the electronic device is in an unfolded state, the widget component is displayed according to a second size. The widget application can pre-store the first and second sizes. When the electronic device is in a folded state, the first size is sent to the widget host application so that the widget host application displays the widget component based on the first size. For example, when the electronic device is in a folded state, a weather widget 10A1 is displayed at the first size, as shown in Figure 9(a). When the electronic device is in an unfolded state, the second size is sent to the widget host application so that the widget host application displays the widget component based on the second size. For example, when the electronic device is in an unfolded state, a weather widget 10A1 is displayed at the second size, as shown in Figure 9(b).

[0278] For example, if a user presses a Widget component with two fingers and then slides it outwards, the size of the Widget component gradually increases according to a preset step size as the user slides. Alternatively, if a user presses a Widget component with two fingers and then slides it inwards, the size of the Widget component gradually decreases according to a preset step size as the user slides.

[0279] Understandably, the Widget host application needs to change the size of the Widget component based on remoteViews. The specific process by which the Widget host application obtains remoteViews can be found in S302 to S305 below.

[0280] S302, The Widget Manager sends a broadcast to the application that provides the Widget, requesting a resizing.

[0281] The Widget Manager can respond to a request to obtain remoteViews sent by the Widget Manager by broadcasting a request to the application providing the Widget to modify its size.

[0282] The broadcast message announcing a size change can include the `onAppWidgetOptionsChanged()` function. When the widget application receives this broadcast, it parses the `onAppWidgetOptionsChanged()` function from it, retrieves the `remoteViews`, and executes S303.

[0283] S303, provides Widget applications with access to remoteViews.

[0284] After the Widget application obtains the pre-stored remoteViews, it can return the remoteViews to the Widget Manager, which is equivalent to executing S304.

[0285] S304, Provides Widget applications to return remoteViews to the Widget Manager.

[0286] After receiving remoteViews, the Widget Manager can generate a resizing notification, include the remoteViews in the resizing notification, and send the resizing notification to the Widget host application, which is to execute S305.

[0287] S305, the Widget Manager sends a notification to the Widget Host Application that the size has been modified.

[0288] S306. The Widget host application modifies the size of the Widget component based on the size modification notification.

[0289] After the Widget host application receives a notification to modify the size, it can obtain remoteViews from the notification and then modify the size of the Widget component based on the remoteViews.

[0290] In this way, electronic devices can modify the size of Widget components.

[0291] Understandably, users can also delete Widget components.

[0292] In one possible scenario, multiple widgets may be generated based on the same widget application. For example, as shown in Figure 10(a), two weather widgets, Weather Widget 10A1 and Weather Widget 10B1, are displayed on the desktop. Both Weather Widget 10A1 and Weather Widget 10B1 are generated based on the weather application. The user long-presses Weather Widget 10B1, as shown in Figure 10(b). In response to the user's long-press action, a close control 10B11 is displayed in the upper right corner of Weather Widget 10B1, as shown in Figure 10(c). If the user clicks the close control 10B11, as shown in Figure 10(d), the weather widget 10B1 closes, as shown in Figure 10(e). This is equivalent to deleting only one widget generated by the weather application; one weather widget is still displayed on the desktop application.

[0293] In one possible scenario, only one widget component generated from the same widget-providing application is displayed on the widget host application. For example, as shown in Figure 11(a), a weather widget 10A1 is displayed on the desktop. The user long-presses the weather widget 10A1, as shown in Figure 11(b). In response to the user's long-press operation, a close control 10A11 is displayed in the upper right corner of the weather widget 10B1, as shown in Figure 11(c). If the user clicks the close control 10A11, as shown in Figure 11(d), the weather widget 10A1 closes, as shown in Figure 11(e). This is equivalent to deleting all widgets generated by the weather application, and no weather widgets are displayed on the desktop.

[0294] The following example, shown in Figure 12, illustrates in detail how to implement the function of deleting Widget components.

[0295] Figure 12 is a flowchart illustrating another method for determining the display state provided in an embodiment of this application. As shown in Figure 12, the method includes:

[0296] S401. In response to the user's operation of deleting a Widget component, the Widget host application sends a request to the Widget Manager to delete the Widget ID.

[0297] S402, The Widget Manager determines whether the currently deleted Widget component is the last Widget component based on the Widget ID.

[0298] For example, as shown in Figure 10(c), the weather component 10B1 to be deleted is not the last weather component on the desktop. Weather component 10A1 is still displayed on the desktop.

[0299] For example, as shown in Figure 11(c), the antenna assembly 10A1 to be deleted is the last weather component on the desktop.

[0300] Understandably, the widgets displayed by the widget host application are managed by the widget manager. Therefore, when a widget is displayed in the widget host application, the widget manager stores the widget ID corresponding to that widget. If the widget manager contains only one widget ID for a given widget, then that widget is the last widget displayed in the widget host application generated from the same widget provider. If the widget manager contains multiple widget IDs for a given widget, then that widget is not the last widget displayed in the widget host application generated from the same widget provider.

[0301] If the currently deleted Widget component is the last Widget component, the Widget Manager sends a deletion broadcast to the application that provided the Widget, which is to execute S403.

[0302] If the currently deleted Widget component is not the last Widget component, the Widget Manager sends an enable failure broadcast to the application that provided the Widget, which is to execute S404.

[0303] S403, The Widget Manager sends a broadcast of deletion to the application that provides the Widget.

[0304] The deletion broadcast can include the onDeleted() function. After receiving the deletion broadcast, the Widget application parses the onDeleted() function from the broadcast and performs the first cleanup operation, which is to execute S405.

[0305] S404, The Widget Manager sends a broadcast to the application that provides the Widget, indicating that the enable function is disabled.

[0306] The broadcast indicating that the enable function has been disabled can include the onDisable() function. When a Widget application receives this broadcast, it extracts the onDisable() function and performs the second cleanup operation, which is S406.

[0307] S405, Provides Widget applications to perform the first cleanup operation.

[0308] Since the broadcast indicating deletion indicates that the Widget component to be deleted is not the last component displayed on the Widget host application generated based on the same Widget application, the first cleanup operation may refer to releasing resources or stopping background services to clean up system resources, rather than releasing all Widget component resources.

[0309] S406, Provides Widget applications to perform a second cleanup operation.

[0310] Since the broadcast indication of enable failure is that the Widget component to be deleted is the last component displayed on the Widget host application generated based on the same Widget application, the second cleanup operation, unlike the first cleanup operation, can refer to the operation of releasing all Widget component resources.

[0311] In this way, electronic devices can perform the function of deleting Widget components.

[0312] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0313] It is understood that, in order to achieve the above functions, the electronic device includes hardware and / or software modules that perform the respective functions. Based on the algorithmic steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is implemented in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementation should not be considered beyond the scope of this application.

[0314] This application embodiment can divide an electronic device into functional modules based on the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one module. It should be noted that the module division in this application embodiment is illustrative and represents only one logical functional division; other division methods may be used in actual implementation. It should also be noted that the module names in this application embodiment are illustrative, and the names of the modules are not limited in actual implementation.

[0315] The method for determining the display state provided in this application can be applied to electronic devices. Optionally, the electronic device includes a terminal device, which can also be called a terminal, user equipment (UE), mobile station (MS), mobile terminal (MT), etc. The terminal device can be a mobile phone, smart TV, wearable device, tablet computer, computer with wireless transceiver function, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, etc. The embodiments of this application do not limit the specific technology or device form used in the terminal device.

[0316] For example, Figure 13 shows a schematic diagram of the structure of electronic device 100. Electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0317] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0318] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0319] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0320] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0321] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0322] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0323] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0324] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0325] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0326] Temperature sensor 180J is used to detect temperature. In some embodiments, electronic device 100 uses the temperature detected by temperature sensor 180J to execute a temperature handling strategy. For example, when the temperature reported by temperature sensor 180J exceeds a threshold, electronic device 100 performs thermal protection by reducing the performance of a processor located near temperature sensor 180J to reduce power consumption. In other embodiments, when the temperature is below another threshold, electronic device 100 heats battery 142 to prevent abnormal shutdown of electronic device 100 due to low temperature. In still other embodiments, when the temperature is below yet another threshold, electronic device 100 boosts the output voltage of battery 142 to prevent abnormal shutdown due to low temperature.

[0327] It should be noted that any electronic device mentioned in the embodiments of this application may include more or fewer modules in electronic device 100.

[0328] This application also provides a computer program product that, when executed by a processor, implements the method for determining the display state as described in any of the method embodiments of this application.

[0329] The computer program product can be stored in memory, for example, it is a program. The program is eventually converted into an executable object file that can be processed and executed after processes such as preprocessing, compilation, assembly and linking.

[0330] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer, implements the method for determining the display state as described in any of the method embodiments of this application. The computer program may be a high-level language program or an executable object program.

[0331] The computer-readable storage medium is, for example, memory. Memory can be volatile or non-volatile, or it can include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0332] In this application, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0333] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0334] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0335] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0336] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and other division methods may exist in actual implementation; for example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0337] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0338] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0339] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for determining a display state, characterized in that, The method is applied to an electronic device, and includes: in response to a first operation, a first application sends a first parameter to a second application, the first parameter indicating the display state of a first component, the display state including a hidden state and a visible state, the first application being an application that displays the first component, the second application being an application that provides display data to the first component, the first operation being used to modify the display state of the first component, the first component being a component generated based on a micro-widget; the second application determining the display state of the first component based on the first parameter; wherein, the electronic device includes a first module, the first module including a first unit and a second unit, the first application sending the first parameter to the second application includes: the first application sending the first parameter to the first unit in the first module; the first unit receiving the first parameter instructing the second unit to determine whether the state of the electronic device meets a preset condition; if the state of the electronic device meets the preset condition, the second unit instructing the first unit to send the first parameter to the second application.

2. The method according to claim 1, characterized in that, The preset conditions include: the first component is a component in a preset list; the time interval between two consecutive displays of the first component is less than a preset time interval; the battery level of the electronic device is higher than a preset battery threshold; and the temperature of the electronic device is lower than a preset temperature threshold.

3. The method according to claim 2, characterized in that, The preset conditions are stored in a cloud server. The second unit determines whether the state of the electronic device meets the preset conditions by: the second unit requesting the cloud server to obtain the preset conditions; the cloud server sending the preset conditions to the second unit; and the second unit determining whether the state of the electronic device meets the preset conditions.

4. The method according to claim 2, characterized in that, The preset conditions are stored in the second unit. The second unit determines whether the state of the electronic device meets the preset conditions, including: the second unit reads the pre-stored preset conditions; the second unit determines whether the state of the electronic device meets the preset conditions.

5. The method according to any one of claims 1 to 4, characterized in that, The first parameter has a first value, which indicates that the first component is in a visible state. The second application determines the display state of the first component based on the first parameter, including: the second application parses the first parameter to obtain the value of the first parameter; if the value of the first parameter is the first value, then the display state of the first component is determined to be visible.

6. The method according to claim 5, characterized in that, The first parameter may also take a second value, which is used to indicate that the first component is in a hidden state. The method may further include: if the first parameter takes the second value, then the display state of the first component is determined to be a hidden state.

7. The method according to any one of claims 1 to 4, characterized in that, The method further includes: if the display state of the first component is visible, updating the first component according to a preset period; if the display state of the first component is hidden, stopping updating the first component according to the preset period.

8. The method according to any one of claims 1 to 4, characterized in that, The method further includes: determining the number of times the first component is displayed based on the display state of the first component.

9. The method according to claim 8, characterized in that, The method further includes: the second application determining the number of times the first component is displayed based on the display state of the first component.

10. The method according to any one of claims 1 to 4, characterized in that, The first component is the Microwidget component, the first application is the Microwidget host application, and the second application is an application that provides display data for the Microwidget component.

11. The method according to any one of claims 1 to 4, characterized in that, The method further includes: in response to a second operation, the first application sending a second parameter to the second application, the second parameter indicating the addition of the first component; the second application sending first data to the first application based on the second parameter, the first data being data for adding the first component; and the first application adding the first component based on the first data.

12. The method according to claim 11, characterized in that, In response to the second operation, the first application sends a second parameter to the second application, including: in response to the second operation, the first application sends the second parameter and a third parameter to the second application, the third parameter being used to indicate updating the first component; the method further includes: the second application sending second data to the first application based on the third parameter, the second data being data for updating the first component; the first application updating the first component based on the second data.

13. The method according to any one of claims 1 to 4, characterized in that, The method further includes: the first application sending a third parameter to the second application at a preset period, the third parameter being used to indicate updating the first component; the second application sending second data to the first application based on the third parameter, the second data being data for updating the first component; and the first application updating the first component based on the second data.

14. The method according to any one of claims 1 to 4, characterized in that, The method further includes: in response to a third operation, the first application sends a third parameter to the second application, the third parameter being used to instruct the deletion of the first component; the second application clears the running data of the first component based on the third parameter.

15. An electronic device, characterized in that, include: One or more processors; Memory; And one or more computer programs, wherein the one or more computer programs are stored on the memory, and when the computer programs are executed by the one or more processors, cause the electronic device to perform the method as described in any one of claims 1 to 14.

16. A chip system, characterized in that, The chip system includes a processor for calling and running a computer program from memory, causing an electronic device on which the chip system is installed to perform the method as described in any one of claims 1 to 14.

17. A computer-readable storage medium comprising a computer program, characterized in that, When the computer program is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1 to 14.

Images