在您的插件中更新 Capacitor 到 3.0
对于正在更新到 Capacitor 3 的插件,有几个必需的和推荐的更改。
规划核心 API
目前,核心团队很难在不潜在地影响插件的情况下对 Capacitor 内部进行更改。由于 Capacitor 2 中大多数类和方法的 iOS 和 Android 版本都是公开的,我们观察到了一些我们认为是内部使用的 Capacitor API 被不当地使用。
在 Capacitor 3 的开发过程中,我们将评估这个问题,并为插件创建一个官方的公共 API,该 API 将在此处记录。
Android
使用新的 @CapacitorPlugin 注解
@NativePlugin 注解已被弃用。我们现在推荐使用新的 @CapacitorPlugin 注解,它将支持新的权限 API。
name 属性保持不变。requestCodes 和 permissionRequestCode 属性已被移除。permissions 属性需要替换为 @Permission 注解列表,每个注解包含一个清单字符串列表及其对应的 alias,在新权限 API 在您的插件中实现之前,您可以暂时忽略 alias。
-@NativePlugin(
+@CapacitorPlugin(
name = "FooBar",
- requestCodes = {
- FooBarPlugin.REQUEST_SOME_METHOD,
- FooBarPlugin.REQUEST_SOME_OTHER_METHOD
- },
- permissionRequestCode = FooBarPlugin.REQUEST_ALL_PERMISSIONS,
- permissions = { Manifest.permission.FOO, Manifest.permission.BAR }
+ permissions = {
+ @Permission(strings = { Manifest.permission.FOO }, alias = "foo"),
+ @Permission(strings = { Manifest.permission.BAR }, alias = "bar")
+ })
)
public class FooBarPlugin extends Plugin {
static final int REQUEST_SOME_METHOD = 10051;
static final int REQUEST_SOME_OTHER_METHOD = 10052;
Android 请求码
Capacitor 3.0 实现了 AndroidX Activity Result API,并移除了手动定义的请求码。插件不再需要提供请求码并重写 handleOnActivityResult 或 handleRequestPermissionsResult,而应使用 @ActivityCallback 或 @PermissionCallback 注解提供回调方法。在启动新的 Activity 或权限请求时,可以引用这些回调。
-static final int IMAGE_REQUEST = 10052;
@PluginMethod
public void chooseImage(PluginCall call) {
Intent intent = new Intent(Intent.ACTION_PICK);
intent.setType("image/*");
- startActivityForResult(call, intent, IMAGE_REQUEST);
+ startActivityForResult(call, intent, "chooseImageResult");
}
+@ActivityCallback
+private void chooseImageResult(PluginCall call, ActivityResult result) {
+ if (result.getResultCode() == Activity.RESULT_CANCELED) {
+ call.reject("Activity canceled");
+ } else {
+ Intent data = result.getData();
+ // 对结果数据进行处理
+ call.resolve("Success!");
+ }
+}
使用 WebColor.parseColor() 替代 Color.parseColor()
Android 将带有 alpha 通道的十六进制颜色字符串解析为 ARGB,而在 iOS 和 Web 中则解析为 RGBA。如果您在跨平台共享带有 alpha 通道的颜色,请务必使用新的 WebColor 实用工具。WebColor.parseColor() 的功能类似于原生 Android 的 Color.parseColor() 函数,但将字符串解析为 RGBA 格式。
String colorStringWithAlpha = "#FF000088"; // 半透明红色
int color = WebColor.parseColor(colorStringWithAlpha);
如果您的颜色没有 alpha 通道,则两个函数将返回相同的结果。
将默认 compileSdkVersion 和 targetSdkVersion 更改为 30
在 android/build.gradle 中将 compileSdkVersion 和 targetSdkVersion 的默认值更改为 30。
android {
- compileSdkVersion project.hasProperty('compileSdkVersion') ? rootProject.ext.compileSdkVersion : 29
+ compileSdkVersion project.hasProperty('compileSdkVersion') ? rootProject.ext.compileSdkVersion : 30
defaultConfig {
minSdkVersion project.hasProperty('minSdkVersion') ? rootProject.ext.minSdkVersion : 21
- targetSdkVersion project.hasProperty('targetSdkVersion') ? rootProject.ext.targetSdkVersion : 29
+ targetSdkVersion project.hasProperty('targetSdkVersion') ? rootProject.ext.targetSdkVersion : 30
...
}
...
}
iOS
弱引用
Capacitor 3 中更新了对象之间的关系以修复内存泄漏。其结果是插件对层级结构中更高层对象的引用现在是 weak(弱引用),在 Swift 中这意味着它 们是可选项。您最可能在访问 bridge 时遇到此更改,但它也适用于其他属性,如 webView。调用 bridge 上的方法基本不变,只是现在需要使用可选链:
-bridge.presentVC(myViewController, animated: true, completion: nil)
+bridge?.presentVC(myViewController, animated: true, completion: nil)
此更改的最大影响是来自 bridge 的所有返回值也将是可选的。安全地处理和展开可选项可能 需要额外的步骤。
if bridge?.isSimEnvironment {
// 错误:无法编译。布尔值是可选的(因为 `bridge` 是可选的)
// 必须先展开才能进行求值。
}
if bridge?.isSimEnvironment == true {
// 一般:与可选项进行显式比较对布尔值有效,
// 但可能不适用于所有数据类型。
}
if let isSim = bridge?.isSimEnvironment, isSim {
// 正确:在检查值之前使用可选绑定来展开可选项。
}
Bridge 更改
除了引用从 strong 变为 weak 之外,bridge 本身的 API 也已更新(现在通过更正式的协议暴露)。许多属性和方法已重命名,但通过保留和弃用旧接口,在可能的情况下提供了向后兼容性。在大多数情况下,Xcode 将能够自动建议新的替代方案。您应该迁移任何现有代码,以便您的插件可以在没有编译器警告的情况下构建。

CAPPluginCall 参数
Capacitor 在 CAPPluginCall 上包含一组便捷方法(getString、getDate 等),用于访问从 JavaScript 传递到插件方法的数据。这些方法已为 Capacitor 3 进行了更新。
get()已被移除。如果您想直接访问参数,请读取options字典。hasOption已被弃用。请使用类型化的访问器之一来检查值。- 任何接受默认值的访问器现在需要非可选的默认值,但返回非可选的结果。这可能会改变局部变量的可选性,但应减少强制展开的使用,这在 Swift 中是一种反模式。
- 关于日期和空值的行为已略有更改并更好地记录。在此处查找更多信息。
- Obj-C 便捷访问器已被拆分,以避免与 Swift 实现冲突。如果您使用 Obj-C 开发,需要通过将
#import <Capacitor/CAPBridgedJSTypes.h>添加到您的.m文件中来单独导入它们。
PluginCall 和 CAPPluginCall 的更改
使用 resolve() 和 reject()
我们认为 resolve() 和 reject() 更好地反映了插件方法预期的 Promise 式流程。它们应优先于(现已弃用的)success() 和 error(),即使在回调风格的插件方法中也是如此。