1. Implementation principle
Figure 1 ArkTS card implementation principle
Card user: the host application that displays the card content, and controls the display position of the card in the host. Currently, only system applications can be used as the card user.
Card provider: The application that provides the display content of the card, controls the display content of the card, the control layout and the control click event.
Card management service: It is used to manage the resident agent service of the cards added in the system, provide formProvider interface capabilities, and provide the management and use of card objects and the ability to refresh cards periodically.
Card rendering service: used to manage card rendering instances, and the rendering instances are bound to the card components on the card user one by one. The card rendering service runs the card page code widgets.abc for rendering, and sends the rendered data to the corresponding card component of the card user.
Figure 2 ArkTS card rendering service operating principle
Compared with JS cards, ArkTS cards support running logic codes in the cards. To ensure that ArkTS cards have problems that do not affect the use of card user applications, ArkTS cards have added a card rendering service to run the card page code widgets.abc. The card rendering service is managed by the card management service. Each card component of the card user corresponds to a rendering instance in the card rendering service. The rendering instances of the same application provider run in the same virtual machine environment, and the rendering instances of different application providers run in different virtual machines. In the running environment, resources and states between different application provider cards are isolated through the virtual machine running environment. During the development process, it is necessary to pay attention to the use of the globalThis object. Cards from the same application provider have the same globalThis object, and cards from different application providers have different globalThis objects.
2. Advantages of ArkTS cards
Cards are a quick access to applications. Compared with JS cards, ArkTS cards have the following advantages:
unified development paradigm, improved development experience and development efficiency.
OpenHarmony released a declarative paradigm UI development framework in 2022, and the card also continued the css/hml/json three-stage Web-like development method, which increased the learning cost for developers. After providing ArkTS card capabilities, unified The card and page development paradigm, the page layout can be directly reused in the card layout, improving the development experience and development efficiency.
Figure 3 Comparison of card engineering structures
The ability of the card is enhanced to make the card more versatile.
Added the ability of animation: ArkTS cards open the ability of attribute animation and explicit animation, making the interaction of cards more friendly.
Added the ability of custom drawing: ArkTS cards open the Canvas component, and cards can use the ability of custom drawing to build more diverse display and interaction effects.
Allow logic code to run in the card: After the open logic code runs, many business logics can be self-closed inside the card, which broadens the business application scenarios of the card.
3. Constraints of ArkTS cards
Compared with JS cards, ArkTS cards have richer capabilities, but it also increases the risk of using cards for malicious acts. Since the ArkTS card is displayed in the user application, the user application is generally a desktop application. In order to ensure the desktop experience and power consumption, the following constraints are imposed on the capabilities of the ArkTS card: loading so is not supported
.
The use of native language development is not supported.
Only some components, events, motion effects, data management, state management and API capabilities of the declarative paradigm are supported.
The event processing of the card and the event processing of the user are independent. It is recommended that in the scenario where the user supports left and right sliding, the card content does not use components with left and right sliding functions, so as to prevent gesture conflicts from affecting the interactive experience.
In addition, the current ArkTS card also has the following constraints:
importing modules is not currently supported.
Quick preview is not currently supported.
The breakpoint debugging capability is not currently supported.
Hot Reload is not supported for now.