| timestamp<sup>7+</sup> | number | Yes| No| Timestamp when data is written to the pasteboard (unit: ms). |
| localOnly<sup>7+</sup> | boolean | Yes| Yes| Whether the pasteboard content is for local access only. The default value is **false**. This attribute is not supported currently. You are advised to use **shareOption** instead.<br>- **true**: The pasteboard content is set for local access only.<br>- **false**: The pasteboard content can be shared between devices.|
| shareOption<sup>9+</sup> | [ShareOption](#shareoption9) | Yes| Yes| Where the pasteboard content can be pasted. If this attribute is set incorrectly or not set, the default value **CROSSDEVICE** is used.|
| timestamp<sup>7+</sup> | number | Yes| No| Timestamp when data is written to the pasteboard (unit: ms). |
| localOnly<sup>7+</sup> | boolean | Yes| Yes| Whether the pasteboard content is for local access only. The default value is **false**. The value will be overwritten by the value of the **shareOption** attribute. You are advised to use the **shareOption** attribute instead. **ShareOption.INAPP** and **ShareOption.LOCALDEVICE** set **localOnly** to **true**, and **ShareOption.CROSSDEVICE** sets **localOnly** to false.<br>- **true**: The pasteboard content is set for local access only.<br>- **false**: The pasteboard content can be shared between devices.|
| shareOption<sup>9+</sup> | [ShareOption](#shareoption9) | Yes| Yes| Where the pasteboard content can be pasted. If this attribute is set incorrectly or not set, the default value **CROSSDEVICE** is used.|
Implements a **PasteData** object. Paste data contains one or more data records ([PasteDataRecord](#pastedatarecord7)) and property description objects ([PasteDataProperty](#pastedataproperty7)).
Before calling any **PasteData** API, you must obtain a **PasteData** object.
Before calling any API in **PasteData**, you must use **[createData()](#pasteboardcreatedata9)** or **[getData()](#getdata9)** to create a **PasteData** object.
The **localOnly** and **shareOption** attributes of [PasteDataProperty](#pastedataproperty7) are mutually exclusive. The **shareOption** attribute prevails, and its value affect the value of **localOnly**.
ArkUI is a UI development framework for building OpenHarmony applications. It provides effortlessly natural UI syntax and UI development infrastructure including UI components, animation mechanisms, and event interaction, to meet the visualized GUI development requirements of application developers.
## Basic Concepts
ArkUI provides a comprehensive infrastructure for UI development of OpenHarmony applications, including simple UI syntax, a diverse array of UI features (components, layouts, animations, and interaction events), and a powerful previewer.
-**Component**: the smallest unit for UI building and display. You build a UI that meets your needs through flexible combinations of components.
-**Page**: the smallest unit for ArkUI application scheduling. You can design multiple pages for your application, manage their files on a per-page basis, and schedule page redirection through [page routing](../reference/apis/js-apis-router.md) APIs, so as to implement decoupling of application functions.
## Basic Concepts
## Key Features
-**UI**: user interface. You can design multiple pages for your application, manage their files on a per-page basis, and schedule page redirection through [routing](arkts-routing.md) APIs, so as to implement decoupling of application functions.
-**UI components**: ArkUI comes with a diverse array of built-in polymorphic components, including basic components (such as text, image, and button), container components with one or more child components, drawing components allowing for customization, and media components that provide video playback capabilities. By being polymorphic, a component provides variant forms to adapt to different types of devices and platforms.
-**Component**: the smallest unit for UI building and display, for example, a list, grid, button, radio button, progress indicator, and text. You build a UI that meets your needs through flexible combinations of components.
-**Flexible layouts**: Creating a responsive UI in ArkUI is easy, with the carefully-designed layout approaches: Besides the basic linear and flexible layouts, you also have access to the advanced list, grid, and column grid layouts as well as the atomic layouts that auto-adapt to screen resolutions.
-**Animation**: Apart from animations embedded in components, ArkUI offers additional animation features: attribute animation, transition animation, and custom animation.
## Two Development Paradigms
-**Drawing**: ArkUI offers advanced drawing capabilities that allow you to draw custom shapes with a range of editors, from images to fill colors and texts.
ArkUI comes with two development paradigms: [ArkTS-based declarative development paradigm](arkts-ui-development-overview.md)(declarative development paradigm for short) and [JS-compatible web-like development paradigm](../ui/ui-js-overview.md)(web-like development paradigm for short). You can choose whichever development paradigm that aligns with your practice.
-**Interaction**: ArkUI allows users to interact with your application UI properly, regardless of the system platform and input device. By default, the UI accepts input from touch gestures, remote controls, keyboards, and mouse devices, with support for event callbacks where you can define interaction logic of your own.
-**Declarative development paradigm**: uses [ArkTS](../quick-start/arkts-get-started.md) – a superset of TypeScript with declarative UI syntax, providing UI drawing capabilities from three dimensions: component, animation, and state management.
-**Platform API channel**: ArkUI provides an API extension mechanism through which platform capabilities are encapsulated to produce JavaScript (JS) APIs in a unified style.
-**Web-like development paradigm**: uses the classical three-stage programming model, in which OpenHarmony Markup Language (HML) is used for building layouts, CSS for defining styles, and JS for adding processing logic. This development paradigm has a low learning curve for frontend web developers, allowing them to quickly transform existing web applications into ArkUI applications.
-**Two development paradigms**: ArkUI comes with two development paradigms: [ArkTS-based declarative development paradigm](./ui-ts-overview.md)(declarative development paradigm for short) and [JS-compatible web-like development paradigm](./ui-js-overview.md)(web-like development paradigm for short). You can choose whichever development paradigm that aligns with your practice.
The declarative development paradigm is a better choice for building new application UIs for the following reasons:
| Development Paradigm | Description | Applicable To | Target Audience |
| Declarative development paradigm | Uses [ArkTS](../quick-start/arkts-get-started.md) – a superset of TypeScript with declarative UI syntax, providing UI drawing capabilities from three dimensions: component, animation, and status management. The programming mode used is closer to natural semantics. You can intuitively describe the UI without caring about how the framework implements UI drawing and rendering, leading to simplified and efficient development.| Applications involving technological sophistication and teamwork| Mobile application and system application developers|
| Web-like development paradigm| Uses the classical three-stage programming model, in which OpenHarmony Markup Language (HML) is used for building layouts, CSS for defining styles, and JS for adding processing logic. UI components are associated with data through one-way data-binding. This means that when data changes, the UI automatically refreshes with the new data. This development paradigm has a low learning curve for frontend web developers, allowing them to quickly transform existing web applications into ArkUI applications.| Small- and medium-sized applications and service widgets with simple UIs | Frontend web developers |
-**Higher development efficiency**: In the declarative development paradigm, the programming mode used is closer to natural semantics. You can intuitively describe the UI without caring about how the framework implements UI drawing and rendering, leading to simplified and efficient development.
## Framework Structure
-**Higher application performance**: As shown below, the two development paradigms share the UI backend engine and language runtime. However, the declarative development paradigm does not require the JS framework for managing the page DOM. As such, it has more streamlined rendering and update links and less memory usage.
-**Future proof**: The declarative development paradigm will continue to develop as the preferred development paradigm in OpenHarmony, providing increasingly more diverse and powerful capabilities.
As shown above, the two development paradigms share the UI backend engine and language runtime. The UI backend engine implements the six basic capabilities of ArkUI. The declarative development paradigm does not require the JS Framework for managing the page DOM. As such, it has more streamlined rendering and update links and less memory usage. This makes the declarative development paradigm a better choice for building application UIs.
**Figure 1** ArkUI framework
## Relationship Between UI and Ability Framework
OpenHarmony provides two [application models](../application-models/application-model-description.md): FA model and stage model. The table below describes the relationship between these two models and the two development paradigms of ArkUI.
**FA Model**
## Development Paradigm Support by Application Type
| Application | Web-like development paradigm| UI development: HML, CSS, and JS<br>Service entries: files with fixed file names, which are **app.ets** (Page ability), **service.ts** (Service ability), and **data.ts** (Data ability)<br>Service logic: JS and TS|
| | Declarative development paradigm | UI development: ArkTS<br>Service entries: files with fixed file names, which are **app.ets** (Page ability), **service.ts** (Service ability), and **data.ts** (Data ability)<br>Service logic: JS and TS|
| Service widget| Web-like development paradigm| UI development: HML, CSS, and JSON (action)<br>Service entry: **form.ts**<br>Service logic: JS and TS|
| | Declarative development paradigm | Not supported |
The support for development paradigms varies according to the OpenHarmony [application model](../application-models/application-model-composition.md) and page form. For details, see the following table.
| Application | Web-like development paradigm | Not supported |
| | Declarative development paradigm| UI development: ArkTS<br>Service entries: derived from **ohos.app.ability.UIAbility**/**ExtensionAbility**<br>Service logic: TS|
| Service widget| Web-like development paradigm | UI development: HML, CSS, and JSON (action)<br>Service entries: derived from **FormExtensionAbility**<br>Service logic: TS|
| | Declarative development paradigm| Not supported |
| Application Model | Page Form | Supported Development Paradigm |
