UI interface rebound method and device, and vehicle-mounted terminal

Abstract

The application provides a UI interface rebound method and device and a vehicle-mounted terminal. The method comprises the following steps: in response to a first vehicle control signal input for a first UI interface, displaying a second UI interface and sending the first vehicle control signal to a corresponding first vehicle controller; when a control result corresponding to the first vehicle control signal is failure, updating a value of a first state variable in an observer module to a first cache value used for recording a real state of a control object of the first vehicle controller, so that the observer module displays the first UI interface according to the real state recorded by the first state variable.

Description

Technical Field

[0001] This application relates to electronic technology, including but not limited to UI interface rebound methods and devices, and vehicle-mounted terminals. Background Technology

[0002] There are often requirements that when a switch or setting item is clicked on the user interface (UI) of the vehicle terminal, the UI should be updated first. If the control result of the vehicle control signal issued by the corresponding function is a failure, the UI needs to bounce back to the state before the operation.

[0003] However, the relevant UI bounce solutions require multiple cross-process communications to achieve the UI bounce, and cross-process communication consumes system resources. Summary of the Invention

[0004] In a first aspect, embodiments of this application provide a UI interface bounce method, the method comprising: in response to a first vehicle control signal input to a first UI interface, displaying a second UI interface and sending the first vehicle control signal to a corresponding first vehicle controller; in response to a failure of the control result corresponding to the first vehicle control signal, updating the value of a first state variable in the observer module to a first cache value used to record the actual state of the controlled object of the first vehicle controller, so that the observer module bounces back and displays the first UI interface according to the actual state recorded by the first state variable.

[0005] It is understood that this application embodiment provides a UI interface bounce method for an in-vehicle terminal. In this method, when the operation result corresponding to the first vehicle control signal input to the first UI interface fails, the value of the first state variable in the observed module is updated to a first cached value. The first cached value records the actual state of the controlled object corresponding to the first vehicle control signal. In this way, the value of the first state variable in the observed module observed by the observer module is the actual state of the controlled object, thereby enabling the first UI interface to bounce back. It can be seen that since this UI interface bounce method uses the observer pattern, the UI interface bounce can be achieved by updating the first state variable in the observed module based on the pre-cached actual state value (i.e., the first cached value), without having to call the get interface in the error callback to communicate across processes with the first vehicle controller to obtain the actual state of the corresponding controlled object. Therefore, the number of times the get interface is called is reduced, thereby reducing the frequency of cross-process communication and saving the system resource overhead caused by cross-process communication.

[0006] Secondly, embodiments of this application provide a UI interface bounce-back device, the device comprising: a display module configured to display a second UI interface in response to a first vehicle control signal input to a first UI interface; a first sending module configured to send the first vehicle control signal to a first vehicle controller in response to the first vehicle control signal; and a first updating module configured to update the value of a first state variable in the observer module to a first cached value used to record the actual state of the controlled object of the first vehicle controller when the control result corresponding to the first vehicle control signal is a failure, so that the observer module bounces back and displays the first UI interface according to the actual state recorded by the first state variable.

[0007] Thirdly, embodiments of this application provide an in-vehicle terminal, including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the program to implement the method described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor or an in-vehicle terminal, implements the method described in the first aspect.

[0009] Fifthly, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed by a processor or vehicle terminal, implement the method described in the first aspect of this application.

[0010] Sixthly, embodiments of this application provide a computer program that causes a processor or vehicle terminal to perform the method described in the first aspect.

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

[0012] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application. Obviously, the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0013] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0014] Figure 1 Schematic diagram of the implementation process of the UI interface bounce method provided in the embodiments of this application Figure 1 ;

[0015] Figure 2 A partial implementation flow diagram of the initialization provided in the embodiments of this application. Figure 1 ;

[0016] Figure 3 A partial implementation flow diagram of the initialization provided in the embodiments of this application. Figure 2 ;

[0017] Figure 4 A schematic diagram illustrating a further implementation of step 101 provided in an embodiment of this application;

[0018] Figure 5 A schematic diagram of the architecture for implementing the UI interface bounce method provided in an embodiment of this application;

[0019] Figure 6 Schematic diagram of the implementation process of the UI interface bounce method provided in the embodiments of this application Figure 2 ;

[0020] Figure 7 This is a schematic diagram of the UI interface bounce device provided in the embodiments of this application;

[0021] Figure 8 This is a schematic diagram of the structure of the vehicle-mounted terminal provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the specific technical solutions of this application will be further described in detail below with reference to the accompanying drawings of the embodiments of this application. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application.

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

[0024] In the following description, references to "some embodiments," "this embodiment," "this application embodiment," and examples, etc., describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subset of all possible embodiments and may be combined with each other without conflict.

[0025] The descriptions such as "first," "second," and "third" appearing in the embodiments of this application do not have a specific meaning (such as no order, nor do they indicate a special limitation on the number of devices in the embodiments of this application), but are merely for the purpose of clearly describing the embodiments of this application and do not constitute any limitation on the embodiments of this application.

[0026] The “UI interface” mentioned in this application embodiment can also be simply referred to as “UI”, which stands for “user interface”.

[0027] As mentioned in the background technology, there are often requirements that when a switch or setting item is clicked on the UI of the vehicle terminal, the UI should be updated first. If the control result of the vehicle control signal issued by the corresponding function is a failure, the UI needs to bounce back to the state before the operation.

[0028] In the relevant bounce-back scheme, during UI initialization, the get signal interface is called to obtain the current real signal value of the vehicle and set the corresponding UI state; the subscribe interface is called to subscribe to the real-time signal state, and the UI state is refreshed according to the vehicle control signal value in the subscription callback; when the user clicks the UI, the set interface is called and an error callback is added. In the error callback, the get interface is called to obtain the real state of the control object of the corresponding vehicle controller. Based on this, the UI bounces back to the UI interface before operation, and this UI interface is adapted to the real state of the corresponding control object.

[0029] The inventors of this application discovered the following technical problems with the above solution during research and analysis: When a function calls the signal sending interface and receives a failure callback, it calls the `get` interface to bounce the UI back. However, this method of using the `get` interface to implement UI bounce requires communication with the vehicle controller to obtain the actual state value of the controlled object. If there are many functions and numerous switches or settings that need to handle UI bounce, the `get` interface needs to be called in multiple error callbacks. Therefore, this implementation method has the following drawbacks: Firstly, it increases the system resource overhead caused by cross-process communication; secondly, if the UI involves many vehicle control signals, the `get` interface needs to be written in multiple error callbacks, resulting in bloated and unconventional code; thirdly, if two UIs that do not exist simultaneously depend on the same vehicle control signal, and one UI is operated while immediately switching to another, if the vehicle control signal does not provide timely feedback, it will cause display asynchrony.

[0030] In view of this, the embodiments of this application provide the following UI interface bounce method, which is applied to vehicle control applications, such as vehicle settings applications, air conditioning applications, seat applications, energy management applications, vehicle health applications, and other vehicle control applications.

[0031] Figure 1Schematic diagram of the implementation process of the UI interface bounce method provided in the embodiments of this application Figure 1 ;like Figure 1 As shown, the method may include the following steps 101 to 103:

[0032] Step 101, in response to a first vehicle control signal input to the first UI interface, display the second UI interface; and,

[0033] Step 102: In response to the first vehicle control signal, send the first vehicle control signal to the corresponding first vehicle controller;

[0034] Step 103: In response to the failure of the control result corresponding to the first vehicle control signal, the value of the first state variable in the observer module is updated to the first cache value used to record the real state of the controlled object of the first vehicle controller, so that the observer module can bounce back and display the first UI interface according to the real state recorded by the first state variable.

[0035] It is understood that this application embodiment provides a UI interface bounce method for an in-vehicle terminal. In this method, when the operation result corresponding to the first vehicle control signal input to the first UI interface fails, the value of the first state variable in the observed module is updated to a first cached value. The first cached value records the actual state of the controlled object corresponding to the first vehicle control signal. In this way, the value of the first state variable in the observed module observed by the observer module is the actual state of the controlled object, thereby enabling the first UI interface to bounce back. It can be seen that since this UI interface bounce method uses the observer pattern, the UI interface bounce can be achieved by updating the first state variable in the observed module based on the pre-cached actual state value (i.e., the first cached value), without having to call the get interface in the error callback to communicate across processes with the first vehicle controller to obtain the actual state of the corresponding controlled object. Therefore, the number of times the get interface is called is reduced, thereby reducing the frequency of cross-process communication and saving the system resource overhead caused by cross-process communication.

[0036] In some embodiments, such as Figure 2 As shown, the UI interface bounce method further includes the following steps 201 to 203:

[0037] Step 201: Initialization is performed before responding to the first vehicle control signal.

[0038] In this embodiment, the initialization includes the initialization of the UI interface. In some embodiments, the initialization is a process performed when a vehicle control application starts up.

[0039] Step 202: During the initialization process, obtain the actual state value of the controlled object of the first vehicle controller.

[0040] In this embodiment, the controlled object of the first vehicle controller refers to an entity or system that needs to be managed, adjusted, or intervened in, and this entity or system is operable. For example, the controlled object of the first vehicle controller can be various functions of the vehicle, including windows, lights, windshield wipers, air conditioning, seats, etc. The controlled object of the first vehicle controller can also be understood as the target object that the user wants to control.

[0041] In some embodiments, step 202 may further include: during the initialization process, obtaining the real state value of the control object of the first vehicle controller by calling the second interface function in the signal class corresponding to the first vehicle control signal.

[0042] Furthermore, in some embodiments, the method further includes: during the initialization process, assigning the actual state value of the control object of the first vehicle controller to the first cached value in the signal class corresponding to the first vehicle control signal; wherein the first cached value and the second interface function are in the same signal class.

[0043] Step 203: Update the value of the first state variable in the observed module to the actual state value of the controlled object of the first vehicle controller, so that the observer module displays the corresponding UI interface according to the actual state value recorded by the first state variable.

[0044] Based on this, users can learn about the actual state of the corresponding controlled object through the currently displayed UI interface.

[0045] In some embodiments, step 203 may further include: updating the value of the first state variable in the observed module to the actual state value of the controlled object of the first vehicle controller by invoking a first method in the observed module.

[0046] Furthermore, in some embodiments, the first method can update the value of the first state variable in any thread.

[0047] In some embodiments, such as Figure 3 As shown, the method further includes the following steps 301 and 302:

[0048] Step 301: During the initialization process, the third interface function in the signal class corresponding to the first vehicle control signal is called to subscribe to the state changes of the control object of the first vehicle controller.

[0049] In some embodiments, the signal class corresponding to the first vehicle control signal further includes a fourth interface function; the method further includes: canceling the subscription to the state change of the control object of the first vehicle controller by calling the fourth interface function.

[0050] Step 302: Upon receiving the state change value sent by the first vehicle controller, update the first cached value to the state change value, and call the first method in the observed module to update the value of the first state variable to the state change value.

[0051] It should be noted that the state change value refers to the state value corresponding to the change in the actual state of the controlled object of the first vehicle controller. This state change value is used to characterize the actual state of the controlled object of the first vehicle controller.

[0052] Understandable, Figure 3 In the illustrated embodiment, during initialization, it is also necessary to subscribe to the state changes of the controlled object of the first vehicle controller. This ensures that when the state of the controlled object changes, the corresponding state change value is received promptly, meaning the latest state of the controlled object is known immediately. Based on this, not only is the first cache value updated to record the latest state of the controlled object of the first vehicle controller, but the value of the first state variable is also updated to record the latest state. This guarantees that the value of the first state variable in the observed module is updated promptly and that the first cache value always records the actual state of the controlled object of the first vehicle controller.

[0053] In some embodiments, the method further includes: during initialization (e.g., during UI initialization), the observer module calls a second method in the observed module to observe changes in the value of the first state variable, and updates the currently displayed UI when the value of the first state variable changes.

[0054] For example, in some embodiments, the observer module is a UI thread. For instance, the observer module is the UI main thread, which is used to draw and update UI elements.

[0055] It is understandable that before the value of the first state variable changes, it indicates that the controlled object of the first vehicle controller is in the first state. After the value of the first state variable changes, it indicates that the controlled object of the first vehicle controller is in the second state. Therefore, before the value of the first state variable changes, the user can know that the controlled object of the first vehicle controller is in the first state through the displayed UI interface. After the value of the first state variable changes, the UI interface is updated adaptively, and the user can know that the controlled object of the first vehicle controller is in the second state through the displayed updated UI interface.

[0056] For example, the controlled object of the first vehicle controller is a car window. Before the value of the first state variable changes, it indicates that the car window is in a closed state. After the value of the first state variable changes, it indicates that the car window is in an open state. Before the value of the first state variable changes, the user can know that the car window is in a closed state through the displayed UI interface. After the value of the first state variable changes, the UI interface is updated adaptively, and the user can know that the car window is in an open state through the displayed updated UI interface.

[0057] It is understood that the second method is used to observe data changes in the observed module, including changes in the value of the first state variable.

[0058] In some embodiments, the observed module has the characteristics of sticky events. This ensures that regardless of whether the observer module registers before or after the value of the first state variable changes, it receives the latest value of the first state variable, thereby ensuring that the state of the controlled object displayed on the UI meets the requirements.

[0059] For example, in the UI initialization process described in the above embodiments, the observer module calls the second method in the observed module to observe the change in the value of the first state variable, and updates the currently displayed UI when the value of the first state variable changes. Because the observed module has the characteristic of sticky events, regardless of whether the observer module is registered before or after UI initialization, it can be guaranteed that the observer module receives the latest value of the first state variable, thereby ensuring that the displayed UI meets the requirements.

[0060] In some embodiments, the observed module further includes a third method for removing the observer module to prevent memory leaks. In some embodiments, the method further includes removing the observer module by calling the third method when the UI interface corresponding to the observer module is destroyed.

[0061] The following describes further optional implementation methods and related terms for steps 101 to 103.

[0062] Step 101: In response to the first vehicle control signal input to the first UI interface, display the second UI interface.

[0063] In this embodiment, the method for inputting the first vehicle control signal is not limited. For example, the user can input the first vehicle control signal by clicking on a certain interface element (such as a switch or setting item) of the first UI interface. Alternatively, the user can also input the first vehicle control signal by voice.

[0064] In this embodiment of the application, the first vehicle control signal is not limited. After the first vehicle control signal is received by the corresponding first vehicle controller, the first vehicle controller responds to the first vehicle control signal and controls the state of the corresponding vehicle component or the operating state of the vehicle system, that is, controls the state of the corresponding controlled object.

[0065] For example, in a vehicle settings application, users can control / set driving modes and / or control / set vehicle safety systems through the application's UI. The input control information is the vehicle control signal, or the in-vehicle terminal can generate the corresponding vehicle control signal based on the input control information. Similarly, in an air conditioning application, users can control one or more of the following through the application's UI: the air conditioning's operating status (e.g., on or off), temperature, fan speed, and airflow direction. The input control information is the vehicle control signal, or the in-vehicle terminal can generate the corresponding vehicle control signal based on the input control information. Furthermore, in a seat application, users can control one or more of the following through the seat application's UI: whether the seat is heated, ventilated, has a massage function, or its position. The input control information is the vehicle control signal, or the in-vehicle terminal can generate the corresponding vehicle control signal based on the input control information. Of course, the above examples are merely illustrative of vehicle control signals and do not constitute a limitation on the type of the first vehicle control signal.

[0066] It's understandable that users can learn the actual state of the controlled object through the first UI interface, and the desired state of the controlled object through the second UI interface. In other words, the user expects the controlled object (i.e., the target object) to be in a certain state by inputting a first control signal. For example, the user can learn through the first UI interface that the air conditioner is currently off (i.e., the actual state). At this time, the user inputs a first vehicle control signal through the first UI interface, which instructs the air conditioner to be turned on. The display then switches from the first UI interface to the second UI interface. The user learns through the second UI interface that the air conditioner is currently on, but in reality, the air conditioner may still be off. Therefore, we call the air conditioner state represented by the second UI interface the user's desired state, that is, the state the user expects the air conditioner to be in by inputting the first control signal.

[0067] In some embodiments, the first vehicle control signal is used to cause the first vehicle controller to control the corresponding controlled object to enter the user's desired state.

[0068] In some embodiments, such as Figure 4 As shown, in step 101, in response to a first vehicle control signal input to the first UI interface, the second UI interface is displayed, which may further include the following steps 401 and 402:

[0069] Step 401: In response to the first vehicle control signal, determine the corresponding user expectation value, which is used to characterize the user expectation state.

[0070] For example, the signal value carried by the first vehicle control signal includes the user's expected value. Alternatively, there may be a certain correspondence between the signal value carried by the first vehicle control signal and the user's expected value; therefore, based on this correspondence and the signal value carried by the first vehicle control signal, the corresponding user's expected value can be determined.

[0071] Step 402: Update the value of the first state variable in the observed module to the user expectation value, so that the observer module displays the second UI interface according to the user expectation value recorded by the first state variable.

[0072] It is understandable that, in the above Figure 4 In the embodiment shown, when the user inputs a first vehicle control signal to the first UI interface, the value of the first state variable in the observer module is first updated to the user's expected value, so that the observer module can observe the user's expected value, and then display the second UI interface according to the user's expected value, so that the user can know the state of the controlled object through the second UI interface (but the state is the user's expected state); in this way, the requirement of making the UI interface change first when the UI interface receives the vehicle control signal is met.

[0073] Furthermore, in some embodiments, step 402 includes: updating the value of the first state variable in the observed module to the user-expected value by invoking a first method in the observed module.

[0074] Furthermore, in some other embodiments, step 402 includes: updating the value of the first state variable to the user-expected value by calling the first interface function in the signal class corresponding to the first vehicle control signal.

[0075] Furthermore, in some embodiments, updating the value of the first state variable to the user-expected value by calling the first interface function in the signal class corresponding to the first vehicle control signal includes: calling a first method in the observed module through the first interface function to update the value of the first state variable to the user-expected value. In some embodiments, the first method can update the value of the first state variable in any thread.

[0076] Furthermore, in some other embodiments, the first interface function does not need to call the first method to set the value of the first state variable, but instead sets the value of the first state variable internally. That is, updating the value of the first state variable to the user-expected value by calling the first interface function in the signal class corresponding to the first vehicle control signal includes: setting the value of the first state variable internally by the first interface function, that is, updating the value of the first state variable to the user-expected value.

[0077] Step 102: In response to the first vehicle control signal, send the first vehicle control signal to the corresponding first vehicle controller.

[0078] In some embodiments, the first vehicle control signal is sent to the first vehicle controller by calling the first interface function in the signal class corresponding to the first vehicle control signal.

[0079] Step 103: In response to the failure of the control result corresponding to the first vehicle control signal, the value of the first state variable in the observer module is updated to the first cache value used to record the real state of the controlled object of the first vehicle controller, so that the observer module can bounce back and display the first UI interface according to the real state recorded by the first state variable.

[0080] In some embodiments, the observed module is a class in the signal class corresponding to the first vehicle control signal.

[0081] The following examples illustrate possible implementation schemes for the UI interface bounce method described in one or more of the above embodiments.

[0082] 1. In one implementation of the UI bounce method, each vehicle control signal can be abstracted into a signal class. This signal class contains the following signal operation interfaces (i.e., interface functions or interfaces): initialization (init) interface, set (set) interface, get (get) interface, subscribe (subscribe) interface, and unsubscribe (unsubscribe) interface. This signal class also contains a cacheValue object to cache the current vehicle control signal value and a LiveData object specifically used to distribute the current signal state. This state includes the actual signal state and the signal state of the user operation (the user's expected value when the UI is clicked). LiveData is a class in the Android architecture component used to hold observable data. LiveData holds data and notifies all active observers when the data changes. Each LiveData is an observable; when the value of the vehicle control signal it records changes, observeForever notifies the observers.

[0083] LiveData includes the following methods:

[0084] observeForever: Used to observe changes in data within a LiveData object;

[0085] removeObserver: Used to remove observers that are observing changes to data in a LiveData object;

[0086] postValue: Updates the value of LiveData in any thread.

[0087] It should be noted that the `init` interface is used to complete the initialization of the vehicle control application; the `set` interface can be understood as an example of the first interface function; the `get` interface can be understood as an example of the second interface function; the `subscribe` interface can be understood as an example of the third interface function; the `unsubscribe` interface can be understood as an example of the fourth interface function; `cacheValue` can be understood as an example of the first cached value; the `LiveData` object can be understood as the instantiated `LiveData` class, which is an example of the observed module; `observeForever` can be understood as an example of the second method; `removeObserver` can be understood as an example of the third method; and `postValue` can be understood as an example of the first method.

[0088] 2. When the vehicle control application initializes, the signal class calls the get interface once to obtain the current real vehicle signal value and assigns it to cacheValue. Then, it calls LiveData's postValue to refresh the value of LiveData. Simultaneously, it calls the signal class's subscribe interface to subscribe to changes in the vehicle control signal and obtain the real state after the vehicle status changes. If the vehicle control application receives a signal change callback, it calls LiveData's postValue to refresh the value of LiveData and refresh the value of cacheValue at the same time. This ensures that LiveData can obtain and observe the current vehicle control signal value, and cacheValue always stores the current real vehicle signal value.

[0089] 3. When the UI of a vehicle control application is initialized, the UI thread calls LiveData's observeForever to observe signal changes. Since the callback thread is the UI thread, the signal value can be received directly in the observer callback to set the UI state. Also, since LiveData object observation is a sticky event, regardless of whether the UI is initialized first or later, it can be guaranteed that the observer will receive the signal value and it will be the latest value in the signal class. When the UI is destroyed, LiveData's removeObserver is called to remove the observer object to prevent memory leaks.

[0090] 4. When the UI is clicked, the set interface of the corresponding signal class is called. The set interface internally sets the value of LiveData. First, the value of LiveData is set to the value expected by the user (in this way, since the UI layer has already observed the value of LiveData, the state of the UI will be synchronized regardless of where it is). If set fails or times out, the value of LiveData is set to cacheValue, which is the current real signal value of the vehicle. The UI layer only needs to observe the change of the LiveData value to display the corresponding UI to achieve display synchronization and bounce effect.

[0091] Understandably, the above implementation method makes the code logic clear and troubleshooting easier because one vehicle control signal corresponds to one signal class. Furthermore, the UI bounce effect is achieved through the observer pattern, thereby reducing the frequency of cross-process communication and saving system resource overhead.

[0092] Figure 5 This is a schematic diagram of the architecture for implementing the UI interface bounce method provided in an embodiment of this application; as shown below. Figure 5 As shown, the architecture 500 includes a controller 501, a signal control layer 502, and a UI presentation layer 503; wherein,

[0093] Controller 501 is the control unit for vehicle functions, responsible for interacting with the signal control layer to exchange vehicle control signals; Controller 501 can also be understood as the vehicle controller.

[0094] The signal control layer 502 is used to manage the vehicle control signals contained in the current application; therefore, this signal control layer can be called the SignalManager. Figure 5 For example, the vehicle control signals managed by the signal management layer 502 include signal 1 (Sginal1), signal 2 (Sginal2), and signal 3 (Sginal3). However, in this embodiment, the number of vehicle control signals managed by the signal management layer 502 is not limited. Figure 5 As shown, in the signal control layer, each vehicle control signal corresponds to a signal class, which contains a liveData object, cacheValue, init interface, set interface, get interface, subscribe interface, and unsubscribe interface. In some embodiments, different vehicle control signals control different functions.

[0095] The UI presentation layer 503 is the interface for interaction between the vehicle system and the user (as shown in Page 1 and Page 2), used to provide feedback on the signal status of the controller 501 and the user's operation status.

[0096] Figure 6 Schematic diagram of the implementation process of the UI interface bounce method provided in the embodiments of this application Figure 2 ;like Figure 6 As shown, when the user opens the application (APP) 601, the APP's SignalManager is initialized by calling the init interface. During initialization, SignalManagerManager instantiates the signal class of the vehicle control signal, adds the obtained signal object, and calls the get interface in the signal class during the initialization process. Through this get interface, it communicates with the controller 501 to obtain the real state of the control object corresponding to the vehicle control signal 602. Simultaneously, the APP calls the subscribe interface in the signal class to subscribe to changes in the vehicle control signal 602. If the signal changes, the values ​​of LiveData and cacheValue are refreshed. Furthermore, since the changes in the LiveData value are subscribed to, when the LiveData value is refreshed and changes, the APP refreshes the UI interface according to the LiveData value.

[0097] When the user clicks on the UI, APP 601 obtains the signal object (obtained by instantiating the vehicle control signal class) through SignalManager, calls the set interface in the vehicle control signal class, and transmits the vehicle control signal input by the user to controller 501. Simultaneously, it refreshes the LiveData value, first setting it to the user's desired value. Since the UI thread observes the refresh of the LiveData value, it refreshes the UI accordingly. If an error callback determines that the set operation failed or timed out, the LiveData value is then refreshed using cacheValue. The UI layer only needs to observe the change in the LiveData value to display the corresponding UI, thus achieving synchronized display and bounce effects.

[0098] Understandably, the above solution features concise code, clear logic, and easier troubleshooting; it solves problems such as threading (the callback thread for vehicle control signals is generally a non-UI thread), memory leaks, and null pointer exceptions; it avoids wasting system resources by frequently calling the get interface for cross-process communication, and uses cacheValue in combination with the subscription interface to cache signal values, ensuring that the current vehicle control signal can always be directly obtained.

[0099] It should be noted that, in the embodiments of this application, LiveData can be replaced by other observer patterns without changing the architecture.

[0100] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps; or steps from different embodiments may be combined into a new technical solution.

[0101] Based on the foregoing embodiments, this application provides a UI interface bounce device.

[0102] Figure 7 This is a schematic diagram of the UI interface bounce device provided in the embodiments of this application; as shown. Figure 7 As shown, the UI interface bounce device 700 includes a display module 701, a first sending module 702, a first updating module 703, an observer module 704, and an observed module 705; wherein:

[0103] Display module 701 is configured to display a second UI interface in response to a first vehicle control signal input to the first UI interface;

[0104] The first transmitting module 702 is configured to transmit the first vehicle control signal to the first vehicle controller in response to the first vehicle control signal;

[0105] The first update module 703 is configured to update the value of the first state variable in the observer module to a first cache value used to record the real state of the controlled object of the first vehicle controller when the control result corresponding to the first vehicle control signal is a failure, so that the observer module can bounce back and display the first UI interface according to the real state recorded by the first state variable.

[0106] In some embodiments, the first vehicle control signal is used to cause the first vehicle controller to control the corresponding controlled object to enter the user-expected state; the display module 701 is configured to: in response to the first vehicle control signal, determine the corresponding user-expected value, the user-expected value being used to characterize the user-expected state; and update the value of the first state variable in the observed module to the user-expected value, so that the observer module subscribing to the observed module displays the second UI interface according to the user-expected value recorded by the first state variable.

[0107] Furthermore, in some embodiments, updating the value of the first state variable in the observed module to the user-expected value includes: updating the value of the first state variable to the user-expected value by calling the first interface function in the signal class corresponding to the first vehicle control signal.

[0108] Furthermore, in some embodiments, updating the value of the first state variable to the user-expected value by calling the first interface function in the signal class corresponding to the first vehicle control signal includes: calling the first method in the observed module through the first interface function to update the value of the first state variable to the user-expected value.

[0109] In some embodiments, the first sending module 702 is configured to: in response to the first vehicle control signal, send the first vehicle control signal to the first vehicle controller by calling the first interface function in the signal class corresponding to the first vehicle control signal.

[0110] In some embodiments, the UI interface rebound device 700 further includes an initialization module and an acquisition module; wherein, the initialization module is configured to perform initialization before responding to the first vehicle control signal; the acquisition module is configured to acquire the real state value of the controlled object of the first vehicle controller during the initialization process; the first update module 703 is further configured to update the value of the first state variable in the observed module to the real state value of the controlled object of the first vehicle controller, so that the observed module displays the corresponding UI interface according to the real state value recorded by the first state variable.

[0111] Furthermore, in some embodiments, obtaining the true state value of the control object of the first vehicle controller during the initialization process includes: obtaining the true state value of the control object of the first vehicle controller by calling the second interface function in the signal class corresponding to the first vehicle control signal during the initialization process.

[0112] Furthermore, in some embodiments, updating the value of the first state variable in the observed module to the actual state value of the controlled object of the first vehicle controller includes: updating the value of the first state variable in the observed module to the actual state value of the controlled object of the first vehicle controller by calling a first method in the observed module.

[0113] In some embodiments, during initialization, the first cache value in the signal class corresponding to the first vehicle control signal is the actual state value of the control object of the first vehicle controller.

[0114] In some embodiments, the UI interface bounce device 700 further includes a subscription module; wherein, the subscription module is configured to subscribe to the state changes of the control object of the first vehicle controller by calling the third interface function in the signal class corresponding to the first vehicle control signal during the initialization process; upon receiving the state change value sent by the first vehicle controller, updating the first cached value to the state change value, and calling the first method in the observed module to update the value of the first state variable to the state change value.

[0115] In some embodiments, the observer module 704 is further configured to: during the initialization process, call the second method in the observed module to observe the change in the value of the first state variable, and update the currently displayed UI interface when the value of the first state variable changes.

[0116] In some embodiments, the observed module 705 is a class in the signal class corresponding to the first vehicle control signal.

[0117] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0118] It should be noted that the module division in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, exist as separate physical units, or have two or more units integrated into one unit. The integrated units can be implemented in hardware, as software functional units, or a combination of software and hardware.

[0119] It should be noted that, in the embodiments of this application, if the above-described methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause the vehicle terminal to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0120] This application provides a vehicle-mounted terminal.

[0121] Figure 8 This is a schematic diagram of the structure of the vehicle-mounted terminal provided in the embodiments of this application; as shown below. Figure 8 As shown, the vehicle terminal 800 includes a memory 801 and a processor 802. The memory 801 stores a computer program that can run on the processor 802. When the processor 802 executes the program, it implements the steps in the method provided in the above embodiments.

[0122] It should be noted that the memory 801 is configured to store instructions and applications executable by the processor 802, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data and video communication data) in the processor 802 and the various modules in the vehicle terminal 800. It can be implemented by flash memory or random access memory (RAM).

[0123] This application also provides a computer-readable storage medium for storing computer programs.

[0124] Optionally, the computer-readable storage medium can be applied to the vehicle terminal in the embodiments of this application, and the computer program causes the processor or vehicle terminal to execute the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.

[0125] This application also provides a computer program product, including computer program instructions.

[0126] Optionally, the computer program product can be applied to the vehicle terminal in the embodiments of this application, and the computer program instructions cause the processor or vehicle terminal to execute the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0127] This application also provides a computer program.

[0128] Optionally, the computer program can be applied to the vehicle terminal in the embodiments of this application. When the computer program runs on the processor or the vehicle terminal, it causes the processor or the vehicle terminal to execute the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0129] It should be noted that the descriptions of the vehicle-mounted terminal, storage medium, computer program product, and computer program embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the vehicle-mounted terminal, storage medium, computer program product, and computer program embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0130] It should be understood that the phrases "one embodiment," "an embodiment," or "some embodiments" mentioned throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment," "in one embodiment," or "in some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential 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. The sequence numbers of the above-described embodiments are merely for descriptive purposes and do not represent the superiority or inferiority of the embodiments. The descriptions of the various embodiments above tend to emphasize the differences between the various embodiments; their similarities or commonalities can be referred to mutually, and for the sake of brevity, they will not be repeated here.

[0131] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three kinds of relationships. For example, object A and / or object B can represent three situations: object A exists alone, object A and object B exist simultaneously, and object B exists alone.

[0132] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0133] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple modules or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or modules can be electrical, mechanical, or other forms.

[0134] The modules described above as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules. They may be located in one place or distributed across multiple network units. Some or all of the modules may be selected to achieve the purpose of this embodiment according to actual needs.

[0135] In addition, each functional module in the various embodiments of this application can be integrated into one processing unit, or each module can be a separate unit, or two or more modules can be integrated into one unit; the integrated modules can be implemented in hardware or in the form of hardware plus software functional units.

[0136] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0137] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause the vehicle terminal to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0138] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0139] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0140] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0141] The above description is merely an 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 UI interface bounce method, characterized in that, The method includes: In response to a first vehicle control signal input to the first UI interface, a second UI interface is displayed, and the first vehicle control signal is sent to the corresponding first vehicle controller; When the control result corresponding to the first vehicle control signal is a failure, the value of the first state variable in the observer module is updated to the first cache value used to record the real state of the controlled object of the first vehicle controller, so that the observer module can bounce back and display the first UI interface according to the real state recorded by the first state variable.

2. The method according to claim 1, characterized in that, The first vehicle control signal is used to enable the first vehicle controller to control the corresponding controlled object to enter the user's desired state; The step of displaying a second UI interface in response to a first vehicle control signal input to a first UI interface includes: In response to the first vehicle control signal, a corresponding user expectation value is determined, wherein the user expectation value is used to characterize the user expectation state; The value of the first state variable in the observed module is updated to the user expectation value, so that the observer module displays the second UI interface according to the user expectation value recorded by the first state variable.

3. The method according to claim 2, characterized in that, Updating the value of the first state variable in the observed module to the user's expected value includes: By calling the first interface function in the signal class corresponding to the first vehicle control signal, the value of the first state variable is updated to the user's expected value.

4. The method according to claim 3, characterized in that, The step of updating the value of the first state variable to the user's expected value by calling the first interface function in the signal class corresponding to the first vehicle control signal includes: The first method in the observed module is called through the first interface function to update the value of the first state variable to the user's expected value.

5. The method according to claim 1, characterized in that, Sending the first vehicle control signal to the corresponding first vehicle controller includes: The first vehicle control signal is sent to the first vehicle controller by calling the first interface function in the signal class corresponding to the first vehicle control signal.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: Initialization is performed before responding to the first vehicle control signal; During the initialization process, the actual state value of the control object of the first vehicle controller is obtained; The value of the first state variable in the observed module is updated to the actual state value of the controlled object of the first vehicle controller, so that the observer module displays the corresponding UI interface according to the actual state value recorded by the first state variable.

7. The method according to claim 6, characterized in that, During the initialization process, obtaining the actual state value of the controlled object of the first vehicle controller includes: During initialization, the actual state value of the control object of the first vehicle controller is obtained by calling the second interface function in the signal class corresponding to the first vehicle control signal.

8. The method according to claim 6, characterized in that, Updating the value of the first state variable in the observed module to the actual state value of the controlled object of the first vehicle controller includes: By calling the first method in the observed module, the value of the first state variable in the observed module is updated to the actual state value of the controlled object of the first vehicle controller.

9. The method according to any one of claims 6-8, characterized in that, The method further includes: During initialization, the actual state value of the control object of the first vehicle controller is assigned to the first cached value in the signal class corresponding to the first vehicle control signal.

10. The method according to claim 9, characterized in that, The method further includes: During the initialization process, the state changes of the control object of the first vehicle controller are subscribed to by calling the third interface function in the signal class corresponding to the first vehicle control signal. Upon receiving a state change value sent by the first vehicle controller, the first cached value is updated to the state change value, and the first method in the observed module is invoked to update the value of the first state variable to the state change value.

11. The method according to any one of claims 6-10, characterized in that, The method further includes: During initialization, the observer module calls the second method in the observed module to observe the change in the value of the first state variable, and updates the currently displayed UI when the value of the first state variable changes.

12. The method according to any one of claims 1-11, characterized in that, The observed module is a class in the signal class corresponding to the first vehicle control signal.

13. The method according to any one of claims 1-11, characterized in that, The observed module has the characteristics of sticky events.

14. A UI interface rebound device, characterized in that, The device includes a display module, a first sending module, a first updating module, an observer module, and an observed module; in ，： The display module is configured to display a second UI interface in response to a first vehicle control signal input to the first UI interface. The first transmitting module is configured to transmit the first vehicle control signal to the first vehicle controller in response to the first vehicle control signal; The first update module is configured to update the value of the first state variable in the observed module to a first cache value used to record the real state of the controlled object of the first vehicle controller when the control result corresponding to the first vehicle control signal is a failure, so that the observed module will bounce and display the first UI interface according to the real state recorded by the first state variable.

15. A vehicle-mounted terminal, comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the method of any one of claims 1-13.

16. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor or vehicle terminal, they implement the method of any one of claims 1-13.

Images