This content originally appeared on DEV Community and was authored by 程序员一鸣
Foreword
this article is based on Api13
hongmeng's desktop card function, that is, service card, is the same as Android-side widgets and iOS-side widgets, except that they are called differently. They all add the core functions in the application or the functions with high user attention to the service card by triggering the desktop application, and then add them to the desktop, so as to achieve the timeliness of information display and the convenience effect of direct access to the application, it can be said that the user experience is a qualitative improvement.
The trigger method is also very simple. Whether you are Android, iOS or HarmonyOS, as long as you have adapted this function, you can add widgets/widgets/cards by pressing the application icon on the desktop. After all, we are articles related to Hongmeng, and the focus is on the effect of Hongmeng system.
In the following case, the card function has been developed so far. After we press the desktop icon for a long time, the card function will be displayed:
after clicking the card, the card effect page will be displayed. In this page, we can customize UI to support multiple card effects.
Click to add to the desktop, the card effect will be displayed on the desktop of the mobile phone. Users can view some important data intuitively according to the logic on the card, and can click to go directly to a certain function page, which can greatly improve the user experience.
Today, this article focuses on the relevant knowledge of service cards. The next article will take you from 0 to 1 to implement a service card.
Card Basics
From the past, we already know that the so-called card is to add important functions in the application to the desktop or lock screen page, which is a function to improve the user experience. At present, the card function is supported in both application development and meta-service development. One thing needs to be known is that the card only supports the addition of desktop and lock screen.
Development Mode
we know that at present, Hongmeng has provided two models, Stage and FA. Cards also support these two models. Since FA is not the main push in the version after API7, Stage model is still the first choice in the subsequent development.
After the model selects Stage, regarding UI development methods, here is also a brief description. Two methods are also provided. One is a card developed based on declarative paradigm ArkTS language, and the other is a card developed based on Web-like paradigm JS language. I remember that there was a key overview in the article "Understanding the Engineering Structure of the Project". As a developer of mobile applications, considering performance, in terms of high complexity, development efficiency and development trend, the declarative development method is definitely our first choice. Of course, the government also mainly pushes this method. Therefore, we still use the declarative paradigm ArkTS language to create cards. The main differences between the two are as follows:
card Type
when we create a card, we can find that there are two choices, one is Static Widget, that is, Static card, and the other is Dynamic Widget, that is, Dynamic card. After right-clicking the corresponding module, we can find the service card Seivice Widget, as shown in the following figure:
The two types of cards are the same in the overall running framework and rendering process. The main difference is that after the static card rendering service renders the card content, the card user will use the data rendered in the last frame as a static image for display. Secondly, the card instance in the card rendering service will release all the running resources of the card to save memory; this will lead to frequent refresh, which will make the static card running resources constantly create and destroy, increase the power consumption of the card.
Here are the differences between the two types:
static Card
regarding how static cards interact with components, FormLink is officially provided, which can be used for interaction between static cards and provider applications. Currently, three types of events are supported: router, message, and call.
Dynamic Card
in dynamic cards, the official postCardAction interface is used for interaction between the dynamic card and the provider application, which is consistent with static. It only supports router, message and call events, and can only be called in the click event of the card control.
Implementation Principle of Dynamic Card Event
the three event application scenarios in the dynamic card are, first, the router event, which is mainly used to jump to the specified UIAbility. It should be noted that if it is a non-system application, it is currently only supported to jump to the UIAbility within its own application. The second is the call event, which is mainly used to pull up the specified UIAbility to the background, and then apply for corresponding background long-time tasks through UIAbility, such as completing a music playing function; the last one is the message event, which can be used to pull up the formextensibility and call back the notification through the onFormEvent interface to complete the message delivery of the control click in the card, thus updating the card content.
Implementation principle
the specific implementation principle mainly involves four, namely, the card user, the card provider, the card management service and the card rendering service.
The card user is generally the desktop of the device, that is, the host application that displays the content of the card. It can control the display position of the card for interaction with the card, and can also complete the functions of adding, deleting and displaying the card.
The card provider, that is, the application or meta-service that creates the card, is the specific implementer of the card function, controls the UI and events of the card, and updates the data.
Card management service, which serves as a bridge between card providers and users, provides users with the ability to query, add and delete card information, and provides providers with notification capabilities such as card addition, deletion, refresh and click events. In fact, to put it bluntly, it is a resident agent service used to manage cards added in the system.
Card rendering service is mainly used to manage card rendering instances. The rendering instances are bound to the card components of the card user.
Card implementation schematic
related Summary
in the development of Hongmeng, although the service card is rich in functions, there are some restrictions. For example, it does not support features such as speed preview, breakpoint debugging, and Hot Reload, and it cannot use setTimeOut. In addition, the development process also faces other constraints, such as not supporting the import of dynamic shared packages, using native language development or loading native so. Currently, the service card only supports ArkUI-based development and does not support cross-platform development. It can only use some components, events, dynamics, data management, state management, and API capabilities of the declarative paradigm.
This article label: HarmonyOS/service card, reference: service card guidance for official documents.
This content originally appeared on DEV Community and was authored by 程序员一鸣
程序员一鸣 | Sciencx (2025-06-28T14:58:57+00:00) HarmonyOS Development: Understanding Desktop Cards in One Article. Retrieved from https://www.scien.cx/2025/06/28/harmonyos-development-understanding-desktop-cards-in-one-article/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.