Stage Widget Development

Widget Overview

A widget is a set of UI components that display important information or operations specific to an application. It provides users with direct access to a desired application service, without the need to open the application first.

A widget usually appears as a part of the UI of another application (which currently can only be a system application) and provides basic interactive features such as opening a UI page or sending a message.

Before you get started, it would be helpful if you have a basic understanding of the following concepts:

• Widget provider: an atomic service that provides the widget content to display and controls how widget components are laid out and how they interact with users.
• Widget host: an application that displays the widget content and controls the widget location.
• Widget Manager: a resident agent that provides widget management features such as periodic widget updates.

NOTE

The widget host and provider do not need to be running all the time. The Widget Manager will start the widget provider to obtain widget information when a widget is added, deleted, or updated.

You only need to develop the widget provider. The system automatically handles the work of the widget host and Widget Manager.

The widget provider controls the widget content to display, the layout of components used in the widget, and click events bound to the components.

When to Use

Carry out the following operations to develop the widget provider based on the stage model:

1. Implement lifecycle callbacks by using the FormExtension APIs.
2. Create a FormBindingData instance.
3. Update a widget by using the FormProvider APIs.
4. Develop the widget UI page.

Available APIs

The FormExtension class has the following APIs. For details, see FormExtension.

Table 1 FormExtension APIs

The FormExtension class also has a member context, that is, the FormExtensionContext class. For details, see FormExtensionContext.

Table 2 FormExtensionContext APIs

The table below describes the FormProvider APIs. For details, see FormProvider.

Table 3 FormProvider APIs

How to Develop

Creating a FormExtension Instance

To create a widget in the stage model, you need to implement lifecycle callbacks using the FormExtension APIs. The code snippet is as follows:

1. Import the required modules.

   import FormExtension from '@ohos.application.FormExtension'
   import formBindingData from '@ohos.application.formBindingData'
   import formInfo from '@ohos.application.formInfo'
   import formProvider from '@ohos.application.formProvider'
   

2. Implement lifecycle callbacks for the widget.

   export default class FormAbility extends FormExtension {
       onCreate(want) {
           console.log('FormAbility onCreate');
           // Persistently store widget information for subsequent use, such as widget instance retrieval or update.
           let obj = {
               "title": "titleOnCreate",
               "detail": "detailOnCreate"
           };
           let formData = formBindingData.createFormBindingData(obj);
           return formData;
       }
       onCastToNormal(formId) {
           // Called when the widget host converts the temporary widget into a normal one. The widget provider should do something to respond to the conversion.
           console.log('FormAbility onCastToNormal');
       }
       onUpdate(formId) {
           // Override this method to support scheduled updates, periodic updates, or updates requested by the widget host.
           console.log('FormAbility onUpdate');
           let obj = {
               "title": "titleOnUpdate",
               "detail": "detailOnUpdate"
           };
           let formData = formBindingData.createFormBindingData(obj);
           formProvider.updateForm(formId, formData).catch((error) => {
               console.log('FormAbility updateForm, error:' + JSON.stringify(error));
           });
       }
       onVisibilityChange(newStatus) {
           // Called when the widget host initiates an event about visibility changes. The widget provider should do something to respond to the notification.
           console.log('FormAbility onVisibilityChange');
       }
       onEvent(formId, message) {
           // If the widget supports event triggering, override this method and implement the trigger.
           console.log('FormAbility onEvent');
       }
       onDestroy(formId) {
           // Delete widget data.
           console.log('FormAbility onDestroy');
       }
       onConfigurationUpdated(config) {
           console.log('FormAbility onConfigurationUpdated, config:' + JSON.stringify(config));
       }
   }
   

Configuring the Widget Configuration File

• Configure Extension ability information under extensionAbilities in the module.json5 file. The internal field structure is described as follows:

For a Form Extension ability, you must specify metadata. Specifically, set name to ohos.extension.form (fixed), and set resource to the index of the widget configuration information.

Example configuration:

 ```json

"extensionAbilities": [{ "name": "FormAbility", "srcEnty": "./ets/FormAbility/FormAbility.ts", "label": "$string:form_FormAbility_label", "description": "$string:form_FormAbility_desc", "type": "form", "metadata": [{ "name": "ohos.extension.form", "resource": "$profile:form_config" }] }] ```

• Configure the widget configuration information. resource in metadata specifies the index of the widget configuration information. For example, $profile:form_config means that form_config.json in the resources/base/profile/ directory of the development view is used as the widget profile configuration file.

  The internal field structure is described as follows:

 Example configuration:

 ```json

{ "forms": [{ "name": "widget", "description": "This is a widget.", "src": "./js/widget/pages/index/index", "window": { "autoDesignWidth": true, "designWidth": 720 }, "isDefault": true, "colorMode": "auto", "supportDimensions": ["22"], "defaultDimension": "22", "updateEnabled": true, "scheduledUpdateTime": "10:30", "formConfigAbility": "ability://ohos.samples.FormApplication.MainAbility" }] } ```

Persistently Storing Widget Data

A widget provider is usually started when it is needed to provide information about a widget. The Widget Manager supports multi-instance management and uses the widget ID to identify an instance. If the widget provider supports widget data modification, it must persistently store the data based on the widget ID, so that it can access the data of the target widget when obtaining, updating, or starting a widget.

       onCreate(want) {
           console.log('FormAbility onCreate');

           let formId = want.parameters["ohos.extra.param.key.form_identity"];
           let formName = want.parameters["ohos.extra.param.key.form_name"];
           let tempFlag = want.parameters["ohos.extra.param.key.form_temporary"];
           // Persistently store widget data for subsequent use, such as widget instance retrieval or update.
           // The storeFormInfo API is not implemented here.
           storeFormInfo(formId, formName, tempFlag, want);

           let obj = {
               "title": "titleOnCreate",
               "detail": "detailOnCreate"
           };
           let formData = formBindingData.createFormBindingData(obj);
           return formData;
       }

You should override onDestroy to implement widget data deletion.

       onDestroy(formId) {
           console.log('FormAbility onDestroy');

           // You need to implement the code for deleting the persistent widget data.
           // The deleteFormInfo API is not implemented here.
           deleteFormInfo(formId);
       }

For details about how to implement persistent data storage, see Lightweight Data Store Development.

The Want object passed in by the widget host to the widget provider contains a flag that specifies whether the requested widget is normal or temporary.

• Normal widget: a widget persistently used by the widget host

• Temporary widget: a widget temporarily used by the widget host

Data of a temporary widget will be deleted on the Widget Manager if the widget framework is killed and restarted. The widget provider, however, is not notified of the deletion and still keeps the data. Therefore, the widget provider needs to clear the data of temporary widgets proactively if the data has been kept for a long period of time. If the widget host has converted a temporary widget into a normal one, the widget provider should change the widget data from temporary storage to persistent storage. Otherwise, the widget data may be deleted by mistake.

Updating Widget Data

When an application initiates a scheduled or periodic update, the application obtains the latest data and calls updateForm to update the widget. The code snippet is as follows:

onUpdate(formId) {
    // Override this method to support scheduled updates, periodic updates, or updates requested by the widget host.
    console.log('FormAbility onUpdate');
    let obj = {
        "title": "titleOnUpdate",
        "detail": "detailOnUpdate"
    };
    let formData = formBindingData.createFormBindingData(obj);
    // Call the updateForm() method to update the widget. Only the data passed through the input parameter is updated. Other information remains unchanged.
    formProvider.updateForm(formId, formData).catch((error) => {
        console.log('FormAbility updateForm, error:' + JSON.stringify(error));
    });
}

Developing the Widget UI Page

You can use HML, CSS, and JSON to develop the UI page for a JavaScript-programmed widget.

NOTE

Only the JavaScript-based web-like development paradigm is supported when developing the widget UI.

• HML file:

<div class="container">
    <stack>
        <div class="container-img">
            <image src="/common/widget.png" class="bg-img"></image>
        </div>
        <div class="container-inner">
            <text class="title">{{title}}</text>
            <text class="detail_text" onclick="routerEvent">{{detail}}</text>
        </div>
    </stack>
</div>

• CSS file:

.container {
 flex-direction: column;
 justify-content: center;
 align-items: center;
}

.bg-img {
 flex-shrink: 0;
 height: 100%;
}

.container-inner {
 flex-direction: column;
 justify-content: flex-end;
 align-items: flex-start;
 height: 100%;
 width: 100%;
 padding: 12px;
}

.title {
 font-size: 19px;
 font-weight: bold;
 color: white;
 text-overflow: ellipsis;
 max-lines: 1;
}

.detail_text {
 font-size: 16px;
 color: white;
 opacity: 0.66;
 text-overflow: ellipsis;
 max-lines: 1;
 margin-top: 6px;
}

• JSON file:

{
  "data": {
    "title": "TitleDefault",
    "detail": "TextDefault"
  },
  "actions": {
    "routerEvent": {
      "action": "router",
      "abilityName": "MainAbility",
      "params": {
        "message": "add detail"
      }
    }
  }
}

Now you've got a widget shown below.

Developing Widget Events

You can set router and message events for components on a widget. The router event applies to ability redirection, and the message event applies to custom click events. The key steps are as follows:

1. Set the onclick field in the HML file to routerEvent or messageEvent, depending on the actions settings in the JSON file.
2. Set the router event.
   • action: "router", which indicates a router event.
   • abilityName: target ability name, for example, MainAbility, which is the default main ability name in DevEco Studio for the stage model.
   • params: custom parameters of the target ability. Set them as required. The value can be obtained from parameters in want used for starting the target ability. For example, in the lifecycle function onCreate of the main ability in the stage model, you can obtain want and its parameters field.
3. Set the message event.
   • action: "message", which indicates a message event.
   • params: custom parameters of the message event. Set them as required. The value can be obtained from message in the widget lifecycle function onEvent.

The code snippet is as follows:

• HML file:

<div class="container">
    <stack>
        <div class="container-img">
            <image src="/common/widget.png" class="bg-img"></image>
        </div>
        <div class="container-inner">
            <text class="title" onclick="routerEvent">{{title}}</text>
            <text class="detail_text" onclick="messageEvent">{{detail}}</text>
        </div>
    </stack>
</div>

• JSON file:

{
  "data": {
    "title": "TitleDefault",
    "detail": "TextDefault"
  },
  "actions": {
    "routerEvent": {
      "action": "router",
      "abilityName": "MainAbility",
      "params": {
        "message": "add detail"
      }
    },
    "messageEvent": {
      "action": "message",
      "params": {
        "message": "add detail"
      }
    }
  }
}