A modular object is a cross-app capability exposure mechanism. An app encapsulates specific functions into an independent functional module through the ModularObjectExtensionAbility component (for the related C API definitions, see modular_object_extension_ability.h) and exposes a Proxy object externally. After other applications obtain the Proxy object, they can invoke these capabilities across processes. For example, a document editing app can provide document processing capabilities, and other applications can invoke these capabilities to implement collaborative document editing; an email app can provide email sending capabilities, and other applications can invoke these capabilities to implement bulk email sending.

In development based on ModularObjectExtensionAbility, you can use the Taihe tool to automatically generate Proxy/Stub code and type library metadata based on interface definitions, shielding the underlying IPC details. The client can also dynamically query and invoke remote interfaces at runtime through ModularObjectDispatcher.

Basic Concepts

Server: The app that provides the ModularObjectExtensionAbility component is called the server.
Client: The app that connects to and invokes the ModularObjectExtensionAbility component is called the client.
Stub object: an object created by the server, used to receive and process IPC requests sent by the client, as well as the business capability implementation.
Proxy object: an object held by the client, used to send IPC requests to the server. The client obtains this object by connecting to the ModularObjectExtensionAbility component.

Working Principles

The client connects to the server: The client initiates a connection request through the Connect API, specifying the bundleName, moduleName, and abilityName of the target ModularObjectExtensionAbility. Each connection creates a new ModularObjectExtensionAbility instance on the server.
The server returns a Proxy object: After the connection is established, the system loads the .so library of the corresponding Ability on the server and calls the OnNativeExtensionCreate entry function. Then the system triggers the OnCreateFunc and OnConnectFunc callbacks of the server in sequence. The developer returns a Stub object in the OnConnectFunc callback. The system converts the Stub into a Proxy object and returns it to the client.
The client communicates with the server through the Proxy: After receiving the Proxy object returned by the server in the OnConnectCallback callback, the client communicates with the server through this object. When communication is no longer needed, the client can disconnect through the Disconnect API. After the connection is disconnected, the system triggers the OnDisconnectFunc and OnDestroyFunc callbacks of the server in sequence.

The following table lists the mapping between the abbreviations and full API names involved in the preceding steps.

Expand

abbreviation	Full API Name
Connect	OH_AbilityRuntime_ConnectModularObjectExtensionAbility
Disconnect	OH_AbilityRuntime_DisconnectModularObjectExtensionAbility
OnNativeExtensionCreate	OH_AbilityRuntime_OnNativeExtensionCreate
OnCreateFunc	OH_AbilityRuntime_ModObjExtensionAbility_OnCreateFunc
OnConnectFunc	OH_AbilityRuntime_ModObjExtensionAbility_OnConnectFunc
OnDisconnectFunc	OH_AbilityRuntime_ModObjExtensionAbility_OnDisconnectFunc
OnDestroyFunc	OH_AbilityRuntime_ModObjExtensionAbility_OnDestroyFunc
OnConnectCallback	OH_AbilityRuntime_ConnectOptions_OnConnectCallback
Proxy	OHIPCRemoteProxy
Stub	OHIPCRemoteStub

Modular Object Development Guide Based on ModularObjectExtensionAbility (C/C++)

Using ModularObjectExtensionAbility to Implement Modular Objects (C/C++)

Send feedback

Was this page helpful?

Send feedback

Reach out to us through the community for any other questions.

Community Q&A Intelligent Assistant