Swan Next-oriented List self-adaptive refreshing method, system and equipment and medium

Abstract

The invention discloses a Next-oriented List self-adaptive refreshing method, system and device and a medium, and the method specifically comprises the steps: generating a trigger threshold value associated with the screen density of the device through a dynamic threshold value calculation module, and binding a scrolling event monitor based on a Scroller component; when the rolling event is monitored, acquiring the Y-axis offset of the List component in real time, and judging whether the List component reaches the boundary of the list or not through a grounding detection algorithm; when the Y-axis offset exceeds a trigger threshold value, activating a bidirectional refreshing animation engine, and calling pre-registered pull-down refreshing or pull-up loading callback according to the rolling direction; during the execution period of the network request, the loading animation of the refresh head component is maintained through the animation state machine until a data response is received; the size and position of the refresh head component are dynamically adjusted based on device screen density and resolution parameters. According to the invention, the self-adaptive refreshing function of the List component facing the Next is realized, and the refreshing operation on different devices is ensured to be accurate and smooth.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of mobile application development, and particularly relates to a List adaptive refresh method and system for HarmonyNext, a device and a medium. BACKGROUND

[0002] In the field of mobile application development, the List component is undoubtedly the core element of data display, which bears the important responsibility of presenting a large amount of information in an orderly and easy-to-read manner to users. With the continuous improvement of user requirements for mobile application interaction experience, the optimization of user experience of the List component has become a key area that developers must deeply research and continuously improve. Especially in the Harmony operating system, as a distributed operating system for all scenarios, the launch of the HarmonyNext version further emphasizes cross-device collaboration, smooth interaction, and highly personalized user experience, which puts forward more stringent and diversified requirements for the interaction experience of the List component.

[0003] Traditional list refresh methods, such as manual pull-to-refresh or pull-to-load more, have been widely used in mobile applications due to their intuitiveness and ease of use. Users can trigger data refresh or loading through simple sliding operations, greatly improving the convenience of operations. However, on the HarmonyNext platform, although it provides rich development interfaces and powerful function support, there is a certain gap in the complete encapsulation of the list refresh function. The native API does not directly provide a mature and perfect list refresh solution, which requires developers to implement the function logic of pull-to-refresh and pull-to-load more.

[0004] This situation not only significantly increases development costs, as developers need to invest additional time and effort to research, design, and implement these functions, but also may affect the consistency of user experience due to implementation differences. Different developers may use different implementation methods, resulting in differences in user interaction effects for the same refresh operation in different applications, which undoubtedly reduces user satisfaction and loyalty to the application.

[0005] First, during the list refresh process, accurately and timely obtaining the state information at the time of refresh is the key to ensuring that the refresh operation is triggered correctly. However, existing technologies often lack an efficient and accurate method to achieve this goal. Especially on devices with different screen densities and resolutions, the difficulty of implementation is greatly increased due to display differences. Developers need to perform a large amount of adaptation and debugging work for different devices to ensure accurate acquisition of state information, which undoubtedly increases the complexity and cost of development.

[0006] Secondly, the execution timing of pull-to-refresh and pull-to-load-more needs to be accurately calculated to avoid false triggering or missing triggering. However, in the prior art, this calculation often relies on fixed thresholds set by developers. These fixed thresholds are difficult to adapt to changes in different devices and user operation habits, leading to frequent problems of inaccurate refresh operations in actual applications. For example, on some devices, due to differences in screen size or touch sensitivity, users may need a larger sliding distance to trigger the refresh operation; while on other devices, false triggering may occur due to too low threshold settings. These problems seriously affect the smoothness and consistency of user experience.

[0007] Finally, in order to improve user experience and the degree of personalization of applications, developers often need to customize and encapsulate the refresh header component, including adjustments in style, animation effects, etc. However, the prior art lacks a unified and easily integrated solution to support this demand. Developers need to design and implement various details of the refresh header component themselves, and conduct a large amount of testing and optimization work to ensure its compatibility and stability. This not only increases the complexity and maintenance cost of the project, but also may lead to different styles of refresh header components between different applications, further affecting the consistency of user experience. SUMMARY

[0008] The purpose of the present application is to provide a List adaptive refresh method, system, device and medium for HarmonyOS Next, which realizes the adaptive refresh function of List component for HarmonyOS Next, ensures accurate and smooth refresh operation on different devices, and solves at least one of the above-mentioned prior art problems.

[0009] In a first aspect, the present application provides a List adaptive refresh method for HarmonyOS Next, which specifically includes: Generating a trigger threshold associated with the device screen density through a dynamic threshold calculation module, and binding a scroll event listener based on the Scroller component; When a scroll event is detected, the Y-axis offset of the List component is obtained in real time, and a bottom detection algorithm is used to determine whether the list boundary is reached; When the Y-axis offset exceeds the trigger threshold, activate the bidirectional refresh animation engine, and call the pre-registered pull-to-refresh or pull-to-load-more callback according to the scroll direction; During network request execution, maintain the loading animation of the refresh header component through an animation state machine until a data response is received; Based on the device screen density and resolution parameters, dynamically adjust the size and position of the refresh header component to complete the adaptation of heterogeneous devices.

[0010] In a second aspect, the present application provides a List adaptive refresh system for Harmony Next, which specifically comprises: A first refresh module for generating a trigger threshold associated with the device screen density through a dynamic threshold calculation module, and binding a scroll event listener based on a Scroller component; A second refresh module for real-time acquisition of the Y-axis offset of the List component when the scroll event is detected, and determination of whether the list boundary is reached through a bottom detection algorithm; A third refresh module for activating a bidirectional refresh animation engine when the Y-axis offset exceeds the trigger threshold, and calling a pre-registered pull-down refresh or pull-up load callback according to the scroll direction; A fourth refresh module for maintaining the loading animation of the refresh header component through an animation state machine during the network request execution until the data response is received; A fifth refresh module for dynamically adjusting the size and position of the refresh header component based on the device screen density and resolution parameters, and completing the heterogeneous device adaptation.

[0011] In a third aspect, the present application provides a computer device, comprising a memory and a processor, and a computer program stored in the memory, when the computer program is executed on the processor, the computer program realizes the List adaptive refresh method for Harmony Next as described in any one of the above methods.

[0012] In a fourth aspect, the present application provides a computer readable storage medium having a computer program stored thereon, when the computer program is run by a processor, the computer program realizes the List adaptive refresh method for Harmony Next as described in any one of the above methods.

[0013] Compared with the prior art, the present application has at least one of the following technical effects: 1. The present application realizes the List component adaptive refresh function for Harmony Next, and ensures the accurate and smooth refresh operation on different devices.

[0014] 2. The present application generates a trigger threshold associated with the device screen density through a dynamic threshold calculation module, and binds a scroll event listener, realizes the device adaptation of the trigger threshold, and improves the accuracy and response speed of the refresh operation.

[0015] 3. The present application realizes accurate bottom detection by real-time acquisition of the Y-axis offset of the List component and utilization of a bottom detection algorithm to determine the list boundary, and avoids false triggering or missed triggering of the refresh operation.

[0016] 4、The application activates the bidirectional refreshing animation engine when the Y-axis offset exceeds the trigger threshold, calls the pre-registered callback function according to the scrolling direction, realizes the automatic processing of pull-down refreshing and pull-up loading, and improves the user experience.

[0017] 5、The application maintains the loading animation of the refreshing header component through the animation state machine during network request execution until the data response is received, guarantees the visual feedback in the loading process, and enhances the waiting experience of the user.

[0018] 6、The application dynamically adjusts the size and position of the refreshing header component based on the device screen density and resolution parameters, realizes the perfect adaptation of heterogeneous devices, and ensures the consistent display effect of the refreshing header component on different devices.

[0019] 7、The application constructs a boundary condition test matrix, simulates a scrolling event generator, collects state response data of the refreshing header component for comparison and analysis, verifies the behavior consistency of the refreshing function under the boundary condition, and ensures the stability and reliability of the function. BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0021] Figure 1 is a flowchart of a List adaptive refreshing method for Harmony Next provided by an embodiment of the present application; Figure 2 is a structural schematic diagram of a List adaptive refreshing system for Harmony Next provided by an embodiment of the present application; Figure 3 is a structural schematic diagram of a computer device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0022] In the following description, specific details such as specific system structures, techniques, etc. are presented in order to thoroughly understand the embodiments of the present application. However, it should be clear to those skilled in the art that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits and methods are omitted to avoid unnecessary details that hinder the description of the present application.

[0023] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0024] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0025] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0026] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0027] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0028] In this application embodiment, the entity executing the process includes a terminal device. This terminal device includes, but is not limited to, devices capable of executing the methods disclosed in this application, such as servers, computers, smartphones, and tablets. Figure 1 A flowchart illustrating an embodiment of the adaptive List refresh method for HarmonyOS Next disclosed in this invention is shown below in detail: S101 generates a trigger threshold associated with the device screen density through a dynamic threshold calculation module, and binds a scroll event listener based on the Scroller component.

[0029] In this embodiment, under the Hongmeng Next operating system, the traditional list refreshing method has many problems, such as inaccurate refreshing operation and inconsistent user experience due to screen density differences on different devices. To solve these problems, this embodiment proposes to generate a trigger threshold associated with the device screen density through a dynamic threshold calculation module, and bind a scroll event listener based on the Scroller component, to achieve more accurate and smooth list refreshing function.

[0030] Specifically, when the application starts, the system API provided by Hongmeng Next is used to obtain the screen density information of the current device. Screen density is usually measured in dpi (dots per inch). Different devices may have different screen density values, such as 160dpi, 240dpi, 320dpi, etc. According to the obtained screen density information, the dynamic threshold calculation module generates a trigger threshold using a specific calculation strategy. For example, a base threshold can be set, and then the base threshold can be adjusted according to the ratio of the screen density to a standard screen density (such as 160dpi). Assuming that the base threshold is 50 pixels, and the current device screen density is 240dpi, which is 1.5 times the standard screen density, then the trigger threshold generated by the dynamic threshold calculation module can be set to 50 pixels multiplied by 1.5, that is, 75 pixels. In this way, the generated trigger threshold is associated with the device screen density, and can adapt to the display effect and operation habits of different devices.

[0031] The calculated trigger threshold is stored in the memory of the application for subsequent use in the scroll event listening process. At the same time, considering that the device may experience some changes that affect the screen density during operation (such as screen rotation causing resolution changes, although the screen density is theoretically unchanged, but the actual display effect may be affected), a timing detection mechanism is set to periodically (such as every 1 minute) obtain the device screen density information again, and recalculate the trigger threshold for updating, to ensure that the threshold always matches the current device state.

[0032] In the application initialization phase, the List component associated Scroller component instance is obtained through the component management system of the Hongmeng Next. The Scroller component is a component in the Hongmeng Next for processing scroll-related functions, which can provide detailed information of the scroll event, such as scroll direction, scroll distance, etc. A scroll event listener object is defined, which is responsible for receiving and processing the scroll event generated by the Scroller component. The scroll event listener needs to implement a specific callback interface, which defines the method that needs to be called when the scroll event occurs. The created scroll event listener object is bound to the Scroller component through the binding method (such as setOnScrollListener) provided by the Scroller component. In this way, when the user performs a scroll operation on the List component, the Scroller component will detect the scroll event and pass the event information to the bound scroll event listener. Before binding the listener, the listener is initialized and some necessary parameters are set, such as the trigger threshold generated by the dynamic threshold calculation module before. Store these parameters in the listener object to facilitate access and use when processing the scroll event later.

[0033] When the user performs a scroll operation on the List component, the Scroller component will detect the scroll event and pass the event information (such as scroll direction, scroll distance, etc.) to the bound scroll event listener. After receiving the scroll event information, the scroll event listener first parses the event information to obtain the scroll direction (pull up or pull down) and the current scroll distance (i.e. Y-axis offset). Compare the obtained scroll distance with the trigger threshold generated by the dynamic threshold calculation module before. If the scroll distance exceeds the trigger threshold and the scroll direction meets the conditions of pull-down refresh or pull-up load (pre-set according to business logic), the listener will trigger the corresponding subsequent processing process, such as calling the callback function of pull-down refresh or pull-up load, etc.

[0034] In this embodiment, the function of generating trigger threshold associated with device screen density through dynamic threshold calculation module and binding scroll event listener based on Scroller component is realized. In actual application, different devices can automatically generate appropriate trigger threshold according to their screen density, ensuring the accuracy and consistency of refresh operation on different devices. At the same time, by binding the scroll event listener, the user's scroll operation information can be obtained in time and accurately, providing a reliable basis for subsequent pull-down refresh and pull-up load functions, thereby improving user experience and application stability.

[0035] S102, when the scroll event is detected, the Y-axis offset of the List component is obtained in real time, and whether the list boundary is reached is determined through the bottom detection algorithm.

[0036] In this embodiment, when developing adaptive refreshing of list components under the Harmony Next operating system, accurately obtaining the scroll state of the List component is crucial for implementing smooth and accurate refreshing operations. Among them, real-time acquisition of the Y-axis offset of the List component and determination of whether the list boundary is reached are two key links. Due to the differences in screen size, resolution of different devices and length of list content, traditional fixed threshold or simple determination method is difficult to meet the diversified needs, which may cause refreshing operation to be triggered or missed, affecting user experience. Therefore, this embodiment aims to provide an accurate and reliable solution to real-time acquisition of the Y-axis offset of the List component when listening to the scroll event, and to determine whether the list boundary is reached through the bottom detection algorithm.

[0037] Specifically, when the scroll event listener receives a scroll event, the event information is parsed. The scroll event information of Harmony Next usually includes scroll direction, scroll distance and other data. Among them, the scroll distance information will clearly distinguish the offset of X-axis and Y-axis. From the parsed scroll event information, the Y-axis offset is directly extracted. This Y-axis offset represents the scroll distance of the List component in the vertical direction relative to the initial position, which is an important basis for subsequent determination of whether the list boundary is reached. The extracted Y-axis offset is stored in a variable inside the listener. In the process of continuous occurrence of scroll events, the value of the variable is updated every time a new scroll event is received, ensuring that the latest Y-axis offset is always saved.

[0038] Through the API provided by Harmony Next, the total height of all list items in the List component is obtained, so as to obtain the total height of the list. This total height reflects the vertical length of all the contents contained in the List component. Similarly, using the system API, the height of the visible area of the List component on the current screen is obtained. The height of the visible area determines the size of the part of the list that the user can directly see on the current screen.

[0039] When the user performs an up-scroll operation (which can be determined by the scroll direction information), the current real-time acquired Y-axis offset is compared with the total height of the list and the height of the visible area. If the Y-axis offset plus the height of the visible area is greater than or equal to the total height of the list (considering a certain tolerance range, for example, set a very small offset threshold, when the difference is less than the threshold, it is also determined that the bottom is reached), it is considered that the List component has been scrolled to the bottom of the list, meeting the condition of pulling to load more.

[0040] When the user performs a pull-down scrolling operation, check whether the Y-axis offset is less than or equal to a very small negative value threshold (a reasonable negative value range is set considering the possibility of slight fluctuations during scrolling). If this condition is met, it is considered that the List component has scrolled to the top of the list, meeting the conditions for pull-down refresh.

[0041] The result of the bottom detection algorithm is stored in a flag variable. For example, when it is determined that the bottom of the list is reached, the flag is set to indicate that "pull-up loading" is available; when it is determined that the top of the list is reached, the flag is set to indicate that "pull-down refresh" is available. Subsequently, whether to activate the corresponding refresh animation engine and call the corresponding callback function can be determined according to this flag.

[0042] In this embodiment, when a scrolling event is detected, the Y-axis offset of the List component is obtained in real time, and the function of accurately determining whether the list boundary is reached is realized through the bottom detection algorithm. This scheme can adapt to changes in screen size, resolution and list content length of different devices, avoiding the false triggering or missed triggering problems caused by the traditional fixed threshold determination method, and improving the accuracy of list refresh operation and the smoothness of user experience. At the same time, it provides a reliable basis for the subsequent implementation of pull-down refresh and pull-up load functions.

[0043] S103, when the Y-axis offset exceeds the trigger threshold, activate the bidirectional refresh animation engine, and simultaneously call the pre-registered pull-down refresh or pull-up load callback according to the scrolling direction.

[0044] In this embodiment, when the application is initialized, a bidirectional refresh animation engine instance is created. The animation engine has various animation effects, such as rotation, scaling, color change, etc., which are used to display dynamic visual effects during the refresh process. At the same time, some initial parameters of the animation engine are set, such as the playing speed of the animation, the number of cycles, etc.

[0045] When the comparison result of the Y-axis offset and the trigger threshold meets the pull-down refresh or pull-up load more conditions, an activation instruction is sent to the bidirectional refresh animation engine. After receiving the instruction, the animation engine starts playing the corresponding animation according to the pre-set animation effect and parameters. For example, if it is a pull-down refresh operation, the animation engine will display a rotating arrow animation, indicating that the data is being pulled down and refreshed; if it is a pull-up load more operation, the animation engine will display a progress bar gradually filling animation, indicating that more data is being loaded.

[0046] During the animation playing process, the animation engine updates the state information of the animation in real time, such as the current playing progress, whether it is completed, etc. These state information can be used for subsequent logical judgment and user interaction feedback.

[0047] In the application development process, the developer will define the callback function of the pull-to-refresh and the pull-to-load in advance. These callback functions contain specific business logic, such as sending a data request to the server, updating local data, etc. During the initialization of the application, these callback functions are registered in the callback management module of the system, so that they can be quickly called when needed.

[0048] According to the comparison result of the Y-axis offset and the trigger threshold, the scrolling direction is determined. If it is a pull-to-refresh operation, the pre-registered pull-to-refresh callback function is obtained from the callback management module and called. When calling the callback function, some necessary parameters are passed, such as the state information of the current list, user operation information, etc., so that the callback function can execute the corresponding business logic according to these information. For example, the callback function may send a request to the server to obtain the latest data, and update the list data after receiving the server response.

[0049] If it is a pull-to-load more operation, the pre-registered pull-to-load callback function is also obtained from the callback management module and called. The callback function may request the next page of data from the server, and append the obtained data to the end of the list.

[0050] During the execution of the callback function, its execution state is monitored. If the callback function executes successfully, for example, successfully obtains data and updates the list, the state of the animation engine can be updated as needed, such as stopping playing the loading animation, displaying a refresh success or load success prompt, etc. If the callback function fails to execute, for example, the network request times out or the server returns an error message, the state of the animation engine is updated, a refresh failure or load failure prompt is displayed, and a retry option may be provided.

[0051] In this embodiment, the function of accurately activating the bidirectional refresh animation engine when the Y-axis offset exceeds the trigger threshold, and calling the pre-registered pull-to-refresh or pull-to-load callback according to the scrolling direction is realized. This scheme can adapt to different device screen characteristics, user operation habits, and changes in list content length, ensuring that the refresh animation and callback function call match the actual user operation, improving the accuracy of the list refresh operation and the smoothness of the user experience. At the same time, the pre-registration of the callback function simplifies the development process, reduces the development cost, and ensures the uniformity and consistency of the refresh operation between different applications.

[0052] S104, during the execution of the network request, the loading animation of the refresh header component is maintained through the animation state machine until the data response is received.

[0053] In this embodiment, when developing the list component adaptive refresh under the Harmony Next operating system, maintaining the loading animation of the refresh header component during network request execution is an important step to improve user experience. If the loading animation cannot be stably and smoothly displayed during the network request process, the user may feel anxious due to the lack of explicit feedback during the waiting time, and even suspect whether the application is running normally. Moreover, the performance differences of different devices and the uncertainty of network conditions increase the difficulty of maintaining the loading animation. The existing technology lacks a perfect mechanism to ensure the continuous and stable display of the loading animation during the network request, resulting in uneven animation display effects in different applications or different scenarios. Therefore, this embodiment aims to provide a specific and feasible solution to maintain the loading animation of the refresh header component through an animation state machine during network request execution until a data response is received.

[0054] Specifically, during the application initialization phase, an animation state machine instance is created. This animation state machine is the core component that manages the loading animation state, responsible for coordinating the play, pause, stop, and other operations of the animation. Different states are defined for the animation state machine, such as "start state", "play state", "pause state", "stop state", etc. Each state corresponds to a different phase and behavior of the loading animation.

[0055] The transition rules between different states are clearly defined. For example, when the network request starts, the animation state machine transitions from the "start state" to the "play state"; when the network request is paused or an exception occurs, it may transition to the "pause state"; when the network request is completed (whether successful or failed), it transitions to the "stop state".

[0056] The loading animation resources (such as animation frame sequences, animation effect parameters, etc.) corresponding to the refresh header component are associated with the animation state machine. In this way, when the animation state machine enters the "play state", it can accurately load and play these animation resources.

[0057] A network request listening mechanism is set up in the application. When the user triggers the pull-to-refresh or pull-to-load-more operation, and the corresponding callback function starts to execute the network request, the listening mechanism can timely capture the network request start event. Once the network request start event is detected, an instruction is sent to the animation state machine, causing it to transition from the initial state (such as the "start state") to the "play state". After receiving the instruction, the animation state machine starts playing the loading animation according to the pre-defined state transition rules. When entering the "play state", the playback parameters of the animation are dynamically set according to the performance of the device and the network condition, such as playback speed, loop count, etc. For example, for devices with lower performance, the playback speed can be appropriately reduced to ensure the smoothness of the animation; for poor network conditions, the loop count of the animation can be increased to make the user feel a more obvious loading process.

[0058] During the network request execution, a timer is set to periodically check the state of the animation state machine. The timer triggers the check operation at certain time intervals, such as every 100 milliseconds. During the regular check process, it is determined whether there are external factors that may affect the playback of the animation. For example, if the device receives a system-level notification or other high-priority tasks, causing the application to temporarily lose focus, the animation state machine may enter the "pause state". At this time, the current playback progress of the animation needs to be recorded, so that it can continue to play from the paused position after the application regains focus. The animation state machine continuously pays attention to the progress of the network request while playing the animation. Although it does not directly involve the synchronization mechanism at the code level, through logical association, it ensures that the playback of the animation and the progress of the network request are relatively synchronized in time. For example, if the network request is expected to take a long time to complete, the animation state machine can control the animation to continue playing, avoiding the situation where the animation suddenly stops or stalls.

[0059] Similarly, by setting a listening mechanism, the end of the network request event is captured in real time, including request success and request failure. When the network request end event is detected, a stop instruction is sent to the animation state machine. The animation state machine changes from the "play state" to the "stop state" according to the instruction. After the animation stops, the corresponding processing is performed according to the result of the network request. If the network request is successful, the refresh header component may display a refresh success or load success prompt, and at the same time the animation state machine can be reset to the initial state and wait for the start of the next network request. If the network request fails, the refresh header component may display an error prompt, and the animation state machine can also be reset and provide an interactive option for the user to retry the refresh. At this time, the animation state machine enters the corresponding state transition process again according to the user operation.

[0060] In this embodiment, the function of maintaining the loading animation of the refresh header component through the animation state machine during the network request execution until the data response is received is realized. This scheme can adapt to the performance differences of different devices and the uncertainty of network conditions, ensure the continuous and stable display of the loading animation during the network request process, and improve the user experience when waiting for data loading. At the same time, through the centralized management and control of the animation state by the animation state machine, the logic of the animation playback is simplified, the development complexity is reduced, and the consistency of the animation display in different application scenarios is ensured.

[0061] S105, based on the device screen density and resolution parameters, dynamically adjusts the size and position of the refresh header component, and completes the heterogeneous device adaptation.

[0062] In this embodiment, during the application startup or initialization phase, the screen density and resolution parameters of the current device are obtained through the system interface provided by the Hongmeng Next operating system. Screen density is usually expressed in terms of pixels per inch (DPI), which reflects the density of pixels on the screen; resolution is expressed in terms of screen width pixels and height pixels, which clearly defines the display size of the screen.

[0063] According to common screen sizes and design specifications, the reference size of the refresh header component in different scenarios is determined in advance. For example, a basic height and width value can be set as a reference for size adjustment on different devices. This reference size should take into account the rationality of the refresh header component in displaying information and interacting, to ensure normal display and operation on most standard devices.

[0064] The position rules of the refresh header component in the list are determined. Generally, when pulling down to refresh, the refresh header component is located at the top of the list, and when pulling up to load more, the refresh header component is located at the bottom of the list. However, for more accurate adaptation, the relative position relationship of the refresh header component with the list edge and other interface elements can be further defined, such as a fixed pixel distance from the top or bottom of the list, or dynamically adjusting the position according to the height of the list content.

[0065] Based on the obtained screen density parameters, the reference size of the refresh header component is converted. Since different screen density devices have different visual effects when displaying elements of the same size, the reference size needs to be scaled according to the screen density. For example, for high-density screens, the size of the refresh header component can be appropriately increased to ensure that it is displayed clearly and easily on the screen; for low-density screens, the size can be appropriately reduced to avoid occupying too much space.

[0066] During the size conversion process, minimum and maximum size limits are set. If the converted size is less than the minimum value, the size is set to the minimum value to ensure that the refresh header component is not too small to be recognized when displayed; if the converted size is greater than the maximum value, the size is set to the maximum value to prevent the component from being too large to affect the display of other content in the list. At the same time, the boundary conditions of the screen edge are considered to ensure that the adjusted size does not cause the refresh header component to exceed the screen display range.

[0067] According to the resolution parameters of the device, combined with the previously defined position rules, the specific position of the refresh header component in the list is calculated. For example, for the pull-down refresh operation, the pixel distance of the refresh header component from the top of the list can be calculated according to the screen height and the height of the list content. This distance needs to take into account the display area changes of the list content under different resolutions to ensure that the refresh header component appears in the appropriate position on devices with various resolutions, facilitating user operation.

[0068] In addition to the calculation of absolute position, the relative position relationship of the refresh header component and other interface elements can also be considered. For example, if there are fixed header or bottom navigation bars in the list, the relative distance of the refresh header component from these elements can be dynamically adjusted according to their size and position, ensuring the layout coordination and consistency of the entire interface.

[0069] After completing the dynamic adjustment of the size and position of the refresh header component, a variety of devices with different screen densities and resolutions are selected for testing. During the testing process, the focus is on whether the display effect and interactive operation of the refresh header component on various devices are normal, such as whether it can be displayed completely, whether it is easy to click, and whether the layout with other content in the list is coordinated.

[0070] According to the test results, collect the problems and user feedback. For the problems found, optimize and adjust the size conversion logic, position calculation algorithm, etc. For example, if the position of the refresh header component on some devices is still not accurate enough, the position rules can be further refined or the calculation parameters can be adjusted; if the display effect of the component size on some devices is not good, the size limit and conversion strategy can be re-examined. Through multiple tests and optimizations, the dynamic adjustment scheme is continuously improved to ensure that the refresh header component can achieve good adaptation effect on various heterogeneous devices.

[0071] In this embodiment, the function of dynamically adjusting the size and position of the refresh header component based on device screen density and resolution parameters is realized, and the heterogeneous device adaptation is completed. This scheme can automatically adapt to the screen characteristics of different devices, ensure that the refresh header component can be correctly displayed and operated on various devices, and improve the compatibility and consistency of user experience of the application. At the same time, it reduces the workload of developers for manual adjustment of different devices, reduces the development cost and maintenance difficulty.

[0072] In some embodiments, in the step S101, the trigger threshold value associated with the device screen density is generated by the dynamic threshold calculation module, and the Scroller component is bound with a scroll event listener based on the Scroller component, specifically including: The screen density parameter is obtained through the device information interface, and the device-adaptive trigger threshold value is calculated according to the multiplication relationship between the preset physical length reference value and the screen density parameter; A Scroller instance is created, and the Scroller instance and the List component of Harmony Next are associated; The trigger threshold value and the Scroller instance are associated and bound, and a scroll event listener is registered on the Scroller instance.

[0073] In this embodiment, during the application startup or initialization phase, a request is initiated to the system to obtain the screen density parameter using the device information interface provided by the Harmony Next operating system. After the system returns the screen density parameter, the returned data is parsed. The screen density parameter is usually presented in the form of pixels per inch (DPI), which reflects the density of pixels on the screen.

[0074] According to actual needs and user experience design, a physical length reference value is preset. This reference value is determined based on common operating distances in real life or user operation comfort, for example, it can be set to 1 centimeter. This physical length reference value is the basis for subsequent calculation of the trigger threshold.

[0075] According to the product relationship between the preset physical length reference value and the obtained screen density parameter, the device adaptive trigger threshold is calculated. Since the screen density determines the number of pixels corresponding to the same physical length on different devices, the physical length can be converted to pixel distance on the device screen through this product relationship. For example, if the preset physical length reference value is 1 centimeter and the screen density is 300 DPI, then the calculated trigger threshold is 300 pixels.

[0076] To ensure that the calculated trigger threshold is within a reasonable range, set the minimum and maximum limits of the threshold. If the calculated threshold is less than the minimum value, set the threshold to the minimum value to avoid the trigger condition being too sensitive, causing the user to trigger the refresh with a slight swipe; if the calculated threshold is greater than the maximum value, set the threshold to the maximum value to prevent the trigger condition being too harsh, requiring the user to swipe significantly to trigger the refresh. At the same time, the calculation result is verified to ensure that the threshold meets the expected business logic and user experience requirements.

[0077] Create a Scroller instance in the application. Scroller component is the core component in Harmony Next system for handling scrolling operations, it can provide scrolling related functions and methods, such as smooth scrolling, scroll state management, etc. Create Scroller instance by calling the constructor function of Scroller class provided by the system, pass in the necessary parameters (such as scroll direction, etc., can be set according to actual needs). Associate the created Scroller instance with the Harmony Next List component. This association can be achieved by setting the relevant properties of the List component or calling specific association methods. After association, the Scroller instance can control the scrolling behavior of the List component, such as setting the scrolling speed, distance, etc. parameters, so that the List component can perform scrolling operations in the expected way.

[0078] The calculated device adaptive trigger threshold is associated and bound with the Scroller instance. This binding can be achieved by storing the trigger threshold information in the Scroller instance, so that the Scroller instance can obtain the threshold when processing the scroll event later, and determine whether to trigger the pull-to-refresh or pull-to-load-more condition according to the threshold.

[0079] A scroll event listener is registered on the Scroller instance. The scroll event listener is a callback mechanism that can listen to scroll-related events of the Scroller instance. When the user performs a scroll operation on the List component, the Scroller instance triggers the corresponding scroll event, and the registered listener can capture these events and execute the predefined callback function. In the callback function, the scroll distance, direction, and other information can be obtained, and combined with the previously bound trigger threshold, to determine whether to trigger the pull-to-refresh or pull-to-load-more operation.

[0080] In this embodiment, the functions of generating a trigger threshold associated with the device screen density through a dynamic threshold calculation module, and binding a scroll event listener based on the Scroller component are implemented. This scheme can automatically adjust the trigger threshold according to the screen density of different devices, ensuring that users can trigger the list refresh function with similar operation experience on various devices, improving the compatibility and consistency of user experience of the application. At the same time, through the cooperation of the Scroller component and the scroll event listener, the user's scroll operation can be sensed in real time, and the refresh demand can be responded in time, improving the smoothness of the application interaction and the response speed.

[0081] In some embodiments, in the step S102, when the scroll event is detected, the Y-axis offset of the List component is obtained in real time, and whether the list boundary is reached is determined through a bottom detection algorithm, specifically including: The vertical displacement data of the Scroller component is captured in real time through the scroll event listener, and the total height of the list content and the height of the visible area are obtained; The vertical displacement data and the height of the visible area are added to obtain the current visible bottom position, and the difference between the total height of the list content and the current visible bottom position is calculated; The difference is compared with the preset boundary determination threshold in real time, and a bottom touch state identifier is generated when the difference is less than or equal to the boundary determination threshold; The scroll direction parameter is detected to obtain a scroll direction identifier; The bottom touch state identifier and the scroll direction identifier are logically associated, and a double-state determination result containing the boundary position and the scroll direction is output.

[0082] In this embodiment, when the user performs a scroll operation on the List component, the scroll event listener is triggered, and at this time, the vertical displacement data of the Scroller component is captured in real time through the processing logic inside the listener. The vertical displacement data reflects the distance that the List component has scrolled in the vertical direction, and it is the basis for subsequent calculation and judgment.

[0083] The total height of the list content is obtained through the interface or method provided by the Harmony Next operating system. The total height of the list content refers to the total height occupied by all items in the List component arranged in the vertical direction, which determines the maximum range that the list can be scrolled. At the same time, the height of the visible area parameter is obtained, which refers to the height of the part of the List component that can be displayed on the current screen, i.e., the height of the list content that the user can actually see. These two height parameters are the key basis for subsequent calculation and judgment of boundary states.

[0084] The captured vertical displacement data is added to the height of the visible area parameter. The vertical displacement data represents the distance that the List component has scrolled in the vertical direction from the initial position, and the height of the visible area parameter represents the height of the list content that can be displayed on the current screen. The sum of the two is the current visible bottom position. This position represents the position of the lowest point of the list content that can be seen on the current screen in the overall list.

[0085] The difference between the total height of the list content and the current visible bottom position is calculated. The total height of the list content minus the current visible bottom position gives the height of the content in the list that is not yet displayed in the visible area, i.e., the remaining height of the list content. This remaining height is one of the important indicators for judging whether the list boundary has been reached.

[0086] According to actual needs and user experience design, a boundary determination threshold is pre-set. This threshold is determined based on factors such as the display effect of the list content, the fault tolerance of user operations, etc., for example, it can be set to 10% of the height of the visible area. The boundary determination threshold is used to judge whether the list is approaching or has reached the boundary state.

[0087] The calculated remaining height of the list content (difference) is compared with the pre-set boundary determination threshold in real time. During the scrolling process, this comparison operation is continuously performed to ensure that the changes in the list boundary state can be responded to in a timely manner.

[0088] When the difference is less than or equal to the boundary determination threshold, it indicates that the remaining height of the list content is very small, and the user is about to scroll to the bottom of the list. At this time, a bottom touch state identifier is generated. The bottom touch state identifier is a flag used to indicate whether the list has reached or is close to the boundary state. It can be a Boolean value (e.g., true indicates reaching the boundary, and false indicates not reaching the boundary) or a specific state code for subsequent logical processing.

[0089] In the scroll event listener, in addition to capturing the vertical displacement data, the scroll direction parameter can also be obtained by listening to the relevant properties or methods of the scroll event. The scroll direction parameter reflects the direction of the user's scrolling the List component, such as scrolling up or scrolling down. According to the obtained scroll direction parameter, it is converted into a scroll direction identifier. The scroll direction identifier can be a simple string (e.g., "up" for scrolling up and "down" for scrolling down) or an enumeration value to explicitly indicate the direction of scrolling. This identifier is very important in subsequent logical processing, as it can help determine whether the user is approaching the bottom of the list (pull-up scrolling) or moving away from the bottom of the list (pull-down scrolling).

[0090] The bottom touch state identifier and the scroll direction identifier are logically associated. In the logical processing process, only when the bottom touch state identifier indicates reaching the boundary (e.g., true) and the scroll direction identifier indicates scrolling up (e.g., "up"), is the user considered to have truly triggered the pull-up load more condition. This is because only when the user scrolls up and approaches the bottom of the list, does the pull-up load more operation need to be performed.

[0091] According to the result of logical association, a double-state determination result containing the boundary position and the scroll direction is output. This determination result can be an object or structure containing multiple fields, such as "bottom touch state" and "scroll direction", for subsequent refresh logic processing. By outputting this determination result, the application can decide whether to trigger the pull-up load more operation according to the actual situation, thereby improving the interaction accuracy and user experience of the application.

[0092] In this embodiment, the Y-axis offset of the List component is obtained in real time when the scroll event is detected, and the bottom touch detection algorithm is used to determine whether the list has reached the boundary. This scheme can accurately and timely determine the boundary state and scroll direction of the list, providing a reliable basis for the implementation of pull-up load more and other functions, improving the interaction smoothness and response speed of the application, and enhancing the consistency and satisfaction of user experience.

[0093] In some embodiments, in step S103, when the Y-axis offset exceeds the trigger threshold, the bidirectional refresh animation engine is activated, and a pre-registered pull-to-refresh or pull-to-load callback is called according to the scroll direction, which specifically includes: When the Y-axis scroll offset exceeds the trigger threshold, a direction recognition unit is started, and the scroll direction is determined according to the offset sign. According to the scroll direction, the corresponding animation engine component is activated, and the scroll direction and the pre-registered callback function are associated and mapped through the callback mapping module. After the animation engine component is started, the corresponding business callback function in the associated mapping relationship is executed, and the visual feedback state of the animation engine component is maintained.

[0094] In this embodiment, when the Y-axis scroll offset exceeds the trigger threshold, the direction recognition unit is immediately started. The direction recognition unit is a logic module specially used for judging the scroll direction, which can determine the scroll direction according to the sign of the offset. In the coordinate system, it is usually stipulated that the downward scroll is the positive direction and the upward scroll is the negative direction. The direction recognition unit reads the current Y-axis offset, and quickly and accurately determines whether the user is scrolling upward or downward by judging whether the offset is positive or negative.

[0095] According to the scroll direction determined by the direction recognition unit, the corresponding animation engine component is activated. Two animation engine components are pre-configured in the system, one for pull-to-refresh animation and the other for pull-to-load animation. For example, if the direction recognition unit determines that the user is scrolling downward, the pull-to-refresh animation engine component is activated; if the user is scrolling upward, the pull-to-load animation engine component is activated. After the animation engine component is activated, it will start to prepare to execute the corresponding animation effect, such as the rotation of the loading indicator, the elastic rebound of the content, etc.

[0096] Through the callback mapping module, the scroll direction and the pre-registered callback function are associated and mapped. During the application development process, the developer will pre-register a series of callback functions, which correspond to different business logics respectively, and these logics need to be executed when the pull-to-refresh or pull-to-load operation is triggered. The callback mapping module finds the callback function corresponding to the scroll direction and associates them. For example, when the pull-to-refresh animation engine component is activated, the callback mapping module will establish a mapping relationship between the "downward scroll" scroll direction and the pre-registered pull-to-refresh callback function.

[0097] Immediately after the animation engine component is started, the corresponding business callback function in the associated mapping relationship is executed. For example, if it is a pull-to-refresh operation, after the pull-to-refresh animation engine component is activated, the system will call the pre-registered pull-to-refresh callback function according to the mapping relationship established previously. This callback function can perform some data loading operations, such as obtaining the latest data from the server or updating the locally cached data. By executing the business callback function in a timely manner, the application can quickly respond and execute the corresponding business logic when the user triggers the refresh or load operation.

[0098] At the same time of executing the business callback function, the visual feedback state of the animation engine component is maintained. The animation engine component not only prompts the user that the refresh or load operation is in progress, but also enhances the smoothness and interest of the user experience. During the execution of the business callback function, the animation engine component continuously displays the corresponding animation effects, such as the continuous rotation of the loading indicator, the slow rebound of the content, and the like. Until the business callback function is executed and it is judged according to the business logic that the refresh or load operation has been completed, the animation effect of the animation engine component is stopped, and the normal list display state is restored.

[0099] In this embodiment, the function of accurately activating the bidirectional refresh animation engine when the Y-axis offset exceeds the trigger threshold and calling the pre-registered pull-to-refresh or pull-to-load callback according to the scrolling direction is realized. This scheme can quickly respond to the user's scrolling operation, provide intuitive visual feedback, ensure the correct execution of the business logic, and improve the interactive smoothness of the application and the user experience. In addition, through the design of the direction recognition unit and the callback mapping module, the association between the animation engine and the business callback is clearer and more efficient, facilitating the development and maintenance of the application.

[0100] In some embodiments, in the step S104, during the network request execution, the loading animation of the refresh header component is maintained through the animation state machine until the data response is received, specifically including: When the network request task is started, a loading start instruction is sent to the animation state machine, so that the animation state machine migrates from the initial static state to the loading state; During the loading state continues, the animation frame update event is triggered periodically to drive the refresh header component to execute the preset loop animation sequence; A bidirectional communication channel between the network request task and the animation state machine is established to real-time monitor the progress state and abnormal events of the network request; When the network response completion signal is received, the animation state machine is automatically migrated from the loading state to the completion state, and a visual confirmation animation is triggered; After maintaining the completion state for a preset time, a final state reset operation is performed to restore the refresh header component to the initial static state.

[0101] In this embodiment, when the user triggers a pull-to-refresh or pull-to-load-more operation, the application will start a corresponding network request task. This network request task is responsible for requesting new data from the server, such as obtaining the latest list item information. When starting the network request task, the application will record the start time of the request, the address of the request, and other related information to facilitate subsequent tracking and management of the request.

[0102] After the network request task is started, a load start instruction is immediately sent to the animation state machine. The animation state machine is a logical module used to manage the animation state of the refresh header component, and it has multiple states, such as an initial static state, a loading state, a completion state, etc. The load start instruction is like a "start signal" that tells the animation state machine that the animation of the refresh header component needs to start execution.

[0103] After receiving the load start instruction, the animation state machine will migrate from the initial static state to the loading state. In the initial static state, the refresh header component is usually displayed in a static style, such as without animation effects or displaying a simple prompt icon. After migrating to the loading state, the animation state machine will prepare to execute the logic related to the loading animation, preparing for subsequent animation frame updates.

[0104] During the duration of the loading state, a period for animation frame updates is set. This period can be adjusted according to actual needs and requirements of the animation effect, such as setting it to update the animation frame every 16 milliseconds to ensure the smoothness of the animation.

[0105] According to the set period, an animation frame update event is triggered periodically. This event will notify the animation state machine to update the animation of the refresh header component. The animation state machine will determine the animation style that the current frame should display according to the preset loop animation sequence. For example, the preset loop animation sequence may be a rotating loading indicator, and each frame will display the style of the loading indicator after rotating a certain angle.

[0106] After the animation state machine determines the animation style of the current frame, it will drive the refresh header component to execute the animation. The refresh header component will update its display content according to the instructions of the animation state machine, thereby realizing the animation effect. In the loading state, the refresh header component will continuously execute the preset loop animation sequence, giving the user an intuitive feedback that data is being loaded.

[0107] To achieve the coordination between the network request task and the animation state machine, a bidirectional communication channel between them is established. This communication channel can be realized through the message passing mechanism or callback function provided by the system. Through the bidirectional communication channel, the network request task and the animation state machine can send and receive information to each other, for example, the network request task can send the request progress information to the animation state machine, and the animation state machine can send the animation state change information to the network request task.

[0108] During the loading state duration, the animation state machine listens to the progress state and abnormal events of the network request in real time through the bidirectional communication channel. The progress state includes the amount of data already obtained, the proportion of request completion, etc., and the abnormal events include network connection failure, server returns error information, etc. The animation state machine will adjust its own state and animation display according to the received progress state and abnormal event information. For example, if the network request progress is slow, the animation state machine may appropriately adjust the playback speed of the animation to reflect the actual situation of loading; if an abnormal event occurs, the animation state machine may switch to an error prompt animation state.

[0109] When the network request task is completed and the data is successfully obtained from the server, a network response completion signal will be sent to the animation state machine. This signal indicates that the data loading process has ended, and the animation state of the refresh header component needs to be changed accordingly. After receiving the network response completion signal, the animation state machine will automatically migrate its state from the loading state to the completion state. In the completion state, the animation of the refresh header component will change to prompt the user that the data loading has been completed. For example, the loading indicator may stop rotating and display a completion icon.

[0110] At the same time, the animation state machine will trigger a visual confirmation animation. The visual confirmation animation is an animation effect used to enhance user experience, which can attract the user's attention in a short time and let the user know that the data loading has been successfully completed. For example, the visual confirmation animation can be a flashing prompt box or a simple celebration animation.

[0111] In the completion state, the animation state machine will maintain the state for a preset duration. This preset duration can be set according to actual needs and requirements of the animation effect, for example, set to 1 second. During the time of maintaining the completion state, the user can clearly see the prompt information that the data loading is completed.

[0112] When the completion state is maintained for a preset duration, the animation state machine can perform a state reset operation. The state reset operation migrates the animation state machine from the completion state back to the initial idle state, and refreshing the header component also restores the display style in the initial idle state. For example, refreshing the header component hides the loading indicator and the completion icon, and restores to a simple prompt icon or a blank state, waiting for the next network request and animation execution.

[0113] In this embodiment, the function of maintaining the loading animation of the refresh header component through the animation state machine during network request execution until receiving the data response is implemented. This scheme can ensure that the refresh header component always displays appropriate animation effects during network request, providing clear and intuitive operation feedback to the user. At the same time, through the establishment of a two-way communication channel, the network request task and the animation state machine work cooperatively, which can respond to changes in network request state in time, adjust the animation display, and improve the smoothness of application interaction and user experience. In addition, the design of the state reset operation enables the refresh header component to return to the initial state after completing a network request, preparing for the next operation and ensuring the stability and maintainability of the system.

[0114] In some embodiments, in step S105, the size and position of the refresh header component are dynamically adjusted based on the device screen density and resolution parameters to complete heterogeneous device adaptation, specifically including: Obtain the device screen density parameter and the resolution parameter through the device information interface, and calculate the conversion scale factor of the device independent pixel and the physical pixel; According to the conversion scale factor, dynamically adjust the size parameter of the refresh header component, the size parameter including the height value and the font size value; Based on the screen height value in the resolution parameter, real-time calculation of the vertical positioning offset of the refresh header component; In the interface rendering stage, automatically apply the adjusted size parameter and the vertical positioning offset to the refresh header component instance; Establish a screen direction change listener, and when detecting device landscape / portrait screen switching, recalculate the size parameter and the vertical positioning offset of the refresh header component.

[0115] In this embodiment, during the application startup or initialization stage, the device screen density parameter and the resolution parameter are obtained through the device information interface provided by the HarmonyOS Next operating system. The obtained screen density parameter is usually in units of dpi (dots per inch), and the resolution parameter is in units of pixels, such as screen width and height pixel values.

[0116] According to the screen density parameter and the resolution parameter, a conversion scale factor between device-independent pixels (dp) and physical pixels (px) is calculated. Device-independent pixels are a virtual unit of pixels that can be scaled according to different screen densities to ensure consistent size on different devices. The conversion scale factor is calculated as follows: conversion scale factor = screen density reference value (usually 160 dpi) / actual screen density of the device. For example, if the actual screen density of the device is 320 dpi, the conversion scale factor is 160 / 320 = 0.5. This conversion scale factor will be used for subsequent adjustments to the refresh header component size parameters.

[0117] In the application design phase, an initial size parameter is set for the refresh header component, including a height value and a font size value. These initial parameters are usually in device-independent pixels. According to the previously calculated conversion scale factor, the size parameters of the refresh header component are dynamically adjusted. Multiply the initial size parameters (in device-independent pixels) by the conversion scale factor to obtain the physical pixel size actually displayed on the device. For example, if the initial height value is 50 dp and the conversion scale factor is 0.5, the actual height value is 50*0.5 = 25px; if the initial font size value is 16 dp, the actual font size value is 16*0.5 = 8px. Through this adjustment, the size of the refresh header component can be relatively consistent on devices with different screen densities.

[0118] The screen height value is extracted from the resolution parameter, which is in pixels and represents the total number of pixels in the vertical direction of the device screen. According to the layout design of the application, the layout rules of the refresh header component in the vertical direction are determined. For example, it may be desired that the refresh header component is located a certain distance below the top of the screen, or its position is calculated based on the layout of other interface elements. Based on the screen height value and the layout rules, the vertical positioning offset of the refresh header component is calculated in real time. For example, if it is desired that the refresh header component is 10% of the screen height away from the top of the screen, the vertical positioning offset = screen height value * 10%. This offset will be used to determine the vertical position of the refresh header component on the interface.

[0119] In the interface rendering phase, the application will prepare the rendering environment, including obtaining the rendering context, initializing the rendering resources, etc. The size parameters (height value and font size value) and the vertical positioning offset of the refresh header component, which have been dynamically adjusted previously, are automatically applied to the refresh header component instance. The application system will correctly draw the refresh header component according to these parameters during the rendering process, so that it has the appropriate size and position. For example, the rendering system will determine the size of the refresh header component's bounding box according to the size parameters, and determine its vertical coordinate on the screen according to the vertical positioning offset, so that the refresh header component is accurately drawn on the interface.

[0120] To respond in time and adjust the parameters of the refresh header component when the device switches between landscape and portrait screens, a screen orientation change listener is established. The screen orientation change listener is a mechanism for listening to changes in the device screen orientation, which can detect in real time whether the device screen is in a landscape state or a portrait state. When the user rotates the device, causing the screen orientation to change, the screen orientation change listener detects this event and notifies the application to perform corresponding processing.

[0121] After the application receives the notification of the landscape-portrait screen switching event, it reacquires the screen density parameters and resolution parameters of the device (as the landscape-portrait screen switching may cause these parameters to change), and then recalculates the conversion scale factor, the size parameters of the refresh header component, and the vertical positioning offset according to the above steps. For example, in the landscape state, the height value and width value of the screen change, and the corresponding vertical positioning offset also needs to be recalculated to ensure that the refresh header component still has appropriate size and position in the new screen orientation.

[0122] In this embodiment, the function of dynamically adjusting the size and position of the refresh header component based on the device screen density and resolution parameters is achieved, and the heterogeneous device adaptation is completed. This scheme can ensure that the refresh header component can display appropriate size and position on devices with different screen densities, resolutions, and landscape-portrait screen states, improving the compatibility and user experience of the application on different devices. Whether the user uses a high-resolution large-screen mobile phone, a low-resolution small-screen mobile phone, or a tablet computer, the refresh header component can be presented in the best state to provide clear and accurate prompts for the user's refresh operation.

[0123] In some embodiments, in the above steps S101-S105, the method further comprises: Constructing a boundary condition test matrix, generating a critical value set according to the trigger threshold based on the boundary condition test matrix; Creating a simulated scroll event generator, configuring event parameters in the simulated scroll event generator, the event parameters including scroll direction, speed, and displacement; Injecting the critical value set into the simulated scroll event generator to generate a test event sequence containing boundary conditions; Transmitting the test event sequence to the refresh header component to execute the test event, while collecting state response data of the refresh header component; Comparing and analyzing the state response data with the pre-constructed expected behavior model to output a behavior consistency report under the boundary condition.

[0124] In this embodiment, first, analyze the boundary condition dimensions that the refresh header component may involve, including scroll position (such as the top and bottom of the list, as well as positions related to the refresh header component trigger threshold), scroll speed (fast, medium, slow), scroll direction (up, down), etc.

[0125] For each test dimension, divide the specific boundary range. For example, for scroll position, determine the specific position threshold that triggers the display, hiding, and start of the refresh of the refresh header component; for scroll speed, according to actual use scenarios and common operation habits, divide the fast, medium, and slow interval ranges.

[0126] With test dimensions as rows and boundary ranges as columns, construct a boundary condition test matrix. Each cell in the matrix represents a specific boundary condition combination, such as "scroll position is trigger refresh threshold, scroll speed is fast, scroll direction is up". By constructing the test matrix, you can comprehensively cover the boundary condition situations that the refresh header component may face.

[0127] Analyze the working principle and trigger mechanism of the refresh header component to determine the trigger threshold for its trigger refresh, display, or hide operations. These trigger thresholds may include scroll displacement thresholds (such as triggering refresh when scrolling a certain distance from the top of the list), time thresholds (such as completing a specific scroll operation within a certain time), etc. According to the trigger threshold, extract the critical value related to it. The critical value is the key value that triggers the state change of the refresh header component, for example, the scroll displacement threshold itself is a critical value, when the scroll displacement reaches or exceeds the value, the refresh header component will enter the corresponding state. Organize all the extracted critical values into a set, which is the critical value set. The critical value set provides an important basis for subsequent generation of test event sequences, ensuring that the test can accurately cover the boundary conditions of the refresh header component.

[0128] In the test environment, create a simulated scroll event generator. This simulated scroll event generator is a tool for simulating user scroll operations, which can generate scroll events according to pre-set rules. Configure event parameters for the simulated scroll event generator, including scroll direction, speed, and displacement. The scroll direction can be up or down, and different parameter values can be set to simulate different scroll directions; the scroll speed can be set according to actual needs, such as fast, medium, or slow; the displacement indicates the distance of the scroll, which can be set to different values according to test requirements. By configuring these event parameters, you can flexibly generate various scroll events to meet the needs of boundary condition testing.

[0129] The previously generated threshold set is injected into the simulated scroll event generator. The simulated scroll event generator determines the trigger conditions and parameters of the scroll events based on the values in the threshold set. For example, when the scroll displacement reaches a certain displacement threshold in the threshold set, the simulated scroll event generator generates a corresponding scroll event.

[0130] Based on the injected threshold set and the configured event parameters, the simulated scroll event generator generates a series of test events containing boundary conditions. These test events are arranged in a certain order and logic to form a test event sequence. Each event in the test event sequence corresponds to a specific combination of boundary conditions, such as a fast upward scroll first, and then generating a trigger refresh event when the scroll displacement reaches the trigger refresh threshold. By generating a test event sequence, the behavior of the refresh head component under various boundary conditions can be systematically tested.

[0131] The generated test event sequence is transmitted to the refresh head component to be tested. The transmission method can be realized through the interface provided by the test framework or by simulating user operations to ensure that the test events can accurately act on the refresh head component.

[0132] During the test process, the state response data of the refresh head component is collected in real time. The state response data includes the display state of the refresh head component (such as whether to display, the display style), the trigger state (such as whether to trigger refresh, refresh progress), position information (such as the coordinate position on the interface), etc. By collecting these state response data, the actual behavior of the refresh head component under the action of the test event can be understood.

[0133] Before testing, an expected behavior model is pre-constructed according to the design requirements and functional specifications of the refresh head component. The expected behavior model describes the behavior that the refresh head component should exhibit under various boundary conditions, such as when the refresh head component should display and trigger refresh at a specific scroll position and speed. The collected state response data is compared and analyzed with the pre-constructed expected behavior model. By comparing the actual state response data of the refresh head component under each test event with the description in the expected behavior model, it is determined whether the behavior of the refresh head component meets the expectations.

[0134] According to the results of the comparison and analysis, a behavior consistency report under boundary conditions is output. The report records the actual behavior, expected behavior, and whether they are consistent of the refresh head component under each test event in detail. For inconsistent cases, the report will point out the specific differences and possible reasons, providing a basis for subsequent optimization and improvement.

[0135] In this embodiment, the system test of the List component refresh head component boundary condition under the Hongmeng Next operating system is realized. This test method can comprehensively cover the boundary condition situation that the refresh head component may face, and ensure that its behavior under various boundary conditions meets the expectations. By generating test event sequences, collecting state response data and comparing and analyzing, problems existing in the refresh head component can be found in time, targeted improvement suggestions are provided for developers, the stability and reliability of the refresh head component are improved, and the user experience is improved.

[0136] Referring to Figure 2 , an embodiment of the present application provides a Hongmeng Next-oriented List adaptive refresh system 2, which specifically comprises: A first refresh module 201 is configured to generate a trigger threshold value associated with a device screen density through a dynamic threshold value calculation module, and bind a scroll event listener based on a Scroller component; A second refresh module 202 is configured to, when a scroll event is listened to, acquire a Y-axis offset of a List component in real time, and determine whether a list boundary is reached through a bottom detection algorithm; A third refresh module 203 is configured to, when the Y-axis offset exceeds the trigger threshold value, activate a bidirectional refresh animation engine, and simultaneously call a pre-registered pull-down refresh or pull-up load callback according to a scroll direction; A fourth refresh module 204 is configured to, during network request execution, maintain a loading animation of a refresh head component through an animation state machine until a data response is received; A fifth refresh module 205 is configured to dynamically adjust a size and a position of the refresh head component based on a device screen density and a resolution parameter, and complete heterogeneous device adaptation.

[0137] It can be understood that the contents in the Hongmeng Next-oriented List adaptive refresh method embodiment as shown in the Figure 1 are all applicable to the present Hongmeng Next-oriented List adaptive refresh system embodiment, the present Hongmeng Next-oriented List adaptive refresh system embodiment specifically realizes the same functions as the Hongmeng Next-oriented List adaptive refresh method embodiment as shown in the Figure 1 , and achieves the same beneficial effects as the Hongmeng Next-oriented List adaptive refresh method embodiment as shown in the Figure 1 .

[0138] It should be noted that the information interaction, execution process and the like between the above systems, since based on the same concept as the method embodiment, the specific functions and the technical effects brought by it can be specifically referred to the method embodiment part, and will not be repeated here.

[0139] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional units and modules is exemplified, and in actual application, the above functions can be completed by different functional units and modules according to needs, that is, the internal structure of the system is divided into different functional units or modules to complete all or part of the above described functions. Each functional unit or module in the embodiment can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of software functional unit. In addition, the specific names of each functional unit or module are only for convenient distinction, and do not limit the protection scope of the present application. The specific working process of the unit or module in the system can refer to the corresponding process in the foregoing method embodiment, which will not be repeated here.

[0140] With reference to Figure 3 The embodiment of the present application also provides a computer device 3, comprising a memory 302 and a processor 301 and a computer program 303 stored in the memory 302, and when the computer program 303 is executed on the processor 301, the computer program 303 realizes the List adaptive refresh method for the Horizontally Next.

[0141] The computer device 3 can be a desktop computer, a notebook computer, a palm computer and a cloud server and the like. The computer device 3 can include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art can understand that, Figure 3 The computer device 3 is only an example and does not constitute a limitation on the computer device 3, and can include more or fewer components than shown, or combine certain components, or different components, for example, can also include an input and output device, a network access device and the like.

[0142] The processor 301 can be a central processing unit (CPU), and the processor 301 can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0143] The memory 302 may, in some embodiments, be an internal storage unit of the computer device 3, such as a hard disk or a memory of the computer device 3. The memory 302 may, in other embodiments, also be an external storage device of the computer device 3, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, and the like, equipped on the computer device 3. Further, the memory 302 may, in addition, include both an internal storage unit and an external storage device of the computer device 3. The memory 302 is used to store an operating system, application programs, a Boot Loader, data, and other programs, such as program codes of the computer program, and the like. The memory 302 may, in addition, be used to temporarily store data that has been output or is to be output.

[0144] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program. When the computer program is run by a processor, the computer program implements the List adaptive refresh method for the HONOROS.

[0145] In the embodiment, the integrated unit, if realized in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the present application can implement all or part of the processes in the above-mentioned embodiment methods through a computer program to instruct relevant hardware to complete, and the computer program can be stored in a computer readable storage medium. The computer program, when executed by a processor, can implement the steps of each method embodiment described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or some intermediate forms. The computer readable medium at least includes any entity or device capable of carrying the computer program code to a photographing device / terminal device, a recording medium, a computer memory, a Read-Only Memory (ROM), a Random Access Memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. For example, a U disk, a mobile hard disk, a magnetic disk or an optical disk, and the like. In some jurisdictions, according to legislation and patent practice, the computer readable medium can not be an electrical carrier signal and a telecommunication signal.

[0146] In the above-described embodiments, the description of each embodiment has its own focus, and the parts not described or recorded in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0147] Those skilled in the art can understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized 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 realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0148] In the embodiments disclosed in the present application, it should be understood that the disclosed apparatus / terminal device and method can be implemented in other ways. For example, the apparatus / terminal device embodiments described above are merely illustrative. For example, the division of the modules or units is merely a logical function division, and there can be another division manner in actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0149] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, i.e. they can be located in one place or distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.

Claims

1. A List adaptive refresh method for the HongMeng Next, characterized in that, The method specifically comprises: The method specifically comprises: When the scroll event is monitored, the Y-axis offset of the List component is obtained in real time, and whether the list boundary is reached is determined through a bottom touch detection algorithm; When the Y-axis offset exceeds the trigger threshold, a bidirectional refresh animation engine is activated, and a pre-registered pull-down refresh or pull-up load callback is called according to the scroll direction; During network request execution, the loading animation of the refresh header component is maintained through an animation state machine until a data response is received; Based on the device screen density and resolution parameters, the size and position of the refresh header component are dynamically adjusted to complete the adaptation of heterogeneous devices.

2. The method of claim 1, wherein, The method specifically comprises: The device information interface is used to obtain the screen density parameter, and the device-adaptive trigger threshold is calculated according to the product relationship between the preset physical length reference value and the screen density parameter; A Scroller instance is created, and the Scroller instance and the List component of the Hongmeng Next are associated; The trigger threshold and the Scroller instance are associated and bound, and a scroll event listener is registered on the Scroller instance.

3. The method of claim 1, wherein, The method specifically comprises: The vertical displacement data of the Scroller component is captured in real time through the scroll event listener, and the total height of the list content and the height parameter of the visible area are obtained; The vertical displacement data and the height parameter of the visible area are added to obtain the current visible bottom position, and the difference between the total height of the list content and the current visible bottom position is calculated; The difference is compared with the preset boundary determination threshold in real time, and a bottom touch state identifier is generated when the difference is less than or equal to the boundary determination threshold; The scroll direction identifier is obtained by detecting the scroll direction parameter; The bottom touch state identifier and the scroll direction identifier are logically associated, and a double-state determination result containing the boundary position and the scroll direction is output.

4. The method of claim 1, wherein, The method specifically comprises: When it is detected that the Y-axis scroll offset exceeds the trigger threshold, a direction recognition unit is started, and the scroll direction is determined according to the offset sign; According to the scroll direction, the corresponding animation engine component is activated, and the scroll direction and the pre-registered callback function are associated and mapped through a callback mapping module; After the animation engine component is started, the corresponding business callback function in the associated mapping relationship is executed, and the visual feedback state of the animation engine component is maintained.

5. The method of claim 1, wherein, The method specifically comprises: When the network request task is started, a loading start instruction is sent to the animation state machine, so that the animation state machine migrates from the initial static state to the loading state; During the loading state duration, the periodic triggering of animation frame update events drives the refresh header component to execute a preset loop animation sequence; A two-way communication channel is established between the network request task and the animation state machine to real-time monitor the progress state and abnormal events of the network request; When a network response completion signal is received, the animation state machine is automatically migrated from the loading state to the completion state, and a visual confirmation animation is triggered; After maintaining the completion state for a preset duration, a final state reset operation is performed to restore the refresh header component to the initial static state.

6. The method of claim 1, wherein, The device screen density and resolution parameters are used to dynamically adjust the size and position of the refresh header component to complete the heterogeneous device adaptation, specifically including: The device screen density parameter and resolution parameter are obtained through the device information interface, and a conversion scale factor of device independent pixels and physical pixels is calculated; Based on the conversion scale factor, the size parameter of the refresh header component is dynamically adjusted, including the height value and font size value; Based on the screen height value in the resolution parameter, the vertical positioning offset of the refresh header component is calculated in real time; In the interface rendering stage, the adjusted size parameter and vertical positioning offset are automatically applied to the refresh header component instance; A screen direction change listener is established, and when a device landscape / portrait screen switching is detected, the size parameter and vertical positioning offset of the refresh header component are recalculated.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: A boundary condition test matrix is constructed, and based on the boundary condition test matrix, a critical value set is generated according to a trigger threshold; An artificial scroll event generator is created, and event parameters are configured in the artificial scroll event generator, including the scroll direction, speed, and displacement; The critical value set is injected into the artificial scroll event generator to generate a test event sequence containing boundary conditions; The test event sequence is transmitted to the refresh header component to execute the test event, and the state response data of the refresh header component is collected; The state response data and the pre-constructed expected behavior model are compared and analyzed to output a behavior consistency report under the boundary condition.

8. A List adaptive refresh system for the HONOR OF NEXT, characterized in that, The system specifically includes: A first refresh module for generating a trigger threshold associated with the device screen density through a dynamic threshold calculation module, and binding a scroll event listener based on the Scroller component; A second refresh module for real-time obtaining the Y-axis offset of the List component when the scroll event is detected, and determining whether the list boundary is reached through a bottom detection algorithm; A third refresh module for activating the bidirectional refresh animation engine when the Y-axis offset exceeds the trigger threshold, and calling the pre-registered pull-down refresh or pull-up load callback according to the scroll direction; A fourth refresh module for maintaining the loading animation of the refresh header component through the animation state machine during the network request execution until the data response is received; A fifth refresh module for dynamically adjusting the size and position of the refresh header component based on the device screen density and resolution parameters to complete the heterogeneous device adaptation.

9. A computer device, comprising: It includes: A memory and a processor, and a computer program stored in the memory, when the computer program is executed on the processor, the List adaptive refresh method for the Harmony Next is realized as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A computer readable storage medium having stored thereon a computer program, the computer program, when executed by a processor, implementing the List adaptive refresh method for the Next of the horde as claimed in any one of claims 1 to 7.

Images