Introduction
When Harmonyizing plug-ins, in addition to the two methods of using dependency_overrides to configure the Harmony adapter library mentioned in the previous article Existing Flutter projects support Harmony II, if the third-party plug-in itself uses the form of a joint plug-in, you can also add the implementation of the Harmony platform in the following way:
dependencies:
image_picker: ^1.1.2
image_picker_ohos:
git:
url: "https://gitcode.com/openharmony-sig/flutter_packages.git"
path: "packages/image_picker/image_picker_ohos"
This is also a very elegant way. You don't need to modify the plug-in code. You can directly add the Harmony adapter library to the project configuration.
What are federated plugins?
Federated plugins are packages that separate support for different platforms. So, a federated plugin can use a separate package for iOS, Android, web, or even for cars (for example, on IoT devices). In addition to these benefits, it also allows domain experts to extend existing platform plugins on the platforms they know best.
Federated plugins require the following packages:
App-oriented package
This package is the direct dependency of the user's plugin. It specifies the API used by the Flutter app.
Platform package
One or more packages containing platform-specific code. The app-oriented package calls these platform packages - they are not included in the app unless they have some special platform functionality that the end user needs.
Platform interface package
The package that integrates the app-oriented package with the platform package. This package declares the interface that the platform package needs to implement for the application-oriented package to use. Using a single platform interface package ensures that all platform packages implement the required functions in their own way.
What is an unintegrated joint plugin?
In contrast, an integrated joint plugin, that is, the implementation of the plugin on a certain platform, is integrated into the main package, which is the "application-oriented package". If the plugin has already integrated the ohos implementation, such as fluwx, it can be used directly without adding the Harmony platform implementation.
If the plugin does not integrate the ohos implementation, such as image_picker, you need to add the Harmony platform implementation. ：
This method is called "non-endorsed federated plugin", in the above configuration,
image_picker is a federated plugin, here we use the latest version of the official community directly, observe the pubspec.yaml file of the plugin, through its structure we can find the characteristics of the federated plugin, the dependencies of the plugin are:
dependencies:
image_picker_platform_interface: ^2.10.0
...
image_picker_android: ^0.8.7
image_picker_ios: ^0.8.8
image_picker_platform_interface It is an abstract layer that defines platform-related interfaces. Below are the implementations of each platform. By splitting them into packages and loading them in a dependent manner, the same principle can be followed by adding another implementation package of the Harmony platform to complete the Harmony adaptation, which is the image_picker_ohos in the above case:
image_picker_ohos:
git:
url: "https://gitcode.com/openharmony-sig/flutter_packages.git"
path: "packages/image_picker/image_picker_ohos"
Notes
It should be noted that not all plugins are suitable for this method. There are two situations in which this is not suitable:
The plugin is not a joint plugin, that is, the implementations of all platforms are aggregated in one package. In this case, it is recommended to use dependence_override to override the plugin dependency
Although the plugin is a joint plugin, Harmony adaptation requires modifying the abstract layer code. A typical example is the use of Platform.ohos, an API that is only available in the Harmony Flutter SDK. In this case, it is also recommended to use dependence_override
Top comments (0)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.