最佳做法

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

请遵循这些插件设计指南,提升用户的整体体验。

常见的最佳做法

对于您开发的所有插件,我们都建议您遵循以下最佳做法。

在开始前确定插件所有权

插件由 Apps 脚本项目定义,此类项目必须归特定帐号所有或位于共享云端硬盘中。在对插件进行编码之前,请先确定哪个帐号应拥有该项目,以及哪个帐号充当其发布者。此外,还要确定哪些帐号要充当协作者,并确保这些帐号有权访问脚本项目及其关联的 Cloud Platform 项目

扩展 Google Workspace,请勿复制

插件旨在为其扩展的 Google Workspace 应用提供新功能,或自动执行复杂任务。如果插件仅仅是应用中的功能,或者对工作流没有明显的改进,则不太可能通过发布审核以进行发布。

缩小范围

明确定义范围时,请始终尽可能选择权限范围最小的范围。例如,如果插件仅需要读取权限,请勿让其插件使用 https://www.googleapis.com/auth/calendar 范围请求访问用户日历的完全访问权限。对于只读权限,请使用 https://www.googleapis.com/auth/calendar.readonly 范围。

避免过度依赖库

与 Apps 脚本代码全部包含在单个脚本项目中相比,使用 Apps 脚本会导致插件运行速度变慢。虽然 Apps 脚本库可以在插件中使用,但如果您在使用插件,它们的性能可能会下降。请避免在项目中添加不必要的库,并设法减少对插件的依赖。

上述延迟时间仅适用于用作服务器端库的 Apps 脚本项目。您可以随意使用客户端 JavaScript 库(例如 jQuery),不会遇到此延迟。

Google Workspace 插件最佳做法

以下最佳做法仅适用于 Google Workspace 插件和卡片服务的使用。

只需使用几张卡

如果插件使用的卡片过多,导航配置就会变得复杂且难以管理。

避免冲动创建不必要的卡片。

使用微件创建函数

在编写创建 Card 或其他复杂界面对象的代码时,不妨考虑将该代码放入它自己的函数中。此创建函数应仅构建并返回对象。这样,每当必须刷新界面时,您都可以快速重新生成该对象。记得在卡片服务中使用构建器类后调用 build()

让卡片保持简单

如果指定卡片包含的微件过多,可能会填满过多的屏幕,变得不那么实用。虽然大型卡片部分会呈现为可折叠的界面元素,但这会对用户隐藏信息。目标是简化您的插件,并准确提供用户需要的内容。

使用错误卡片

针对错误情况创建卡片。如果您的插件产生了错误,它应该会显示一个卡片,其中包含错误信息和有关如何修正它的说明(如果可能)。例如,如果您的插件因授权失败而无法连接到非 Google 服务,则显示提示此信息的卡片,并要求用户验证正在使用的帐号信息。

编写测试和测试消息

您应全面测试您创建的所有插件。构建测试函数,以便使用测试数据创建卡片和微件,然后验证对象是否按预期创建。

使用操作回调函数时,您通常必须构建一个响应对象。您可以使用如下所示的语句来验证响应是否正确构建:

    Logger.log(response.printJson());

使用 Run 菜单直接从 Apps 脚本编辑器运行测试函数。如果您有可行的插件,请务必安装未发布的版本,以便对其进行测试。

使用适合该插件扩展的每个主机应用的测试数据。例如,如果插件扩展了 Gmail,您可能需要有几个测试电子邮件及其邮件 ID,从而确保在提供不同的邮件内容时,该插件能按预期运行。您可以使用 Gmail API Users.messages.list 方法或使用 Apps 脚本的 Gmail 服务获取指定邮件的邮件 ID。

日历会议最佳做法

如果您的插件将第三方日历会议选项集成到了 Google 日历中,请遵循以下其他最佳做法:

保持 onCreateFunction 指示灯亮起

当用户尝试创建该类型的会议解决方案时,系统会同步调用您在清单中定义的每个 onCreateFunction。请确保这些函数仅执行创建会议所需的最低限度的工作。在这些函数中执行过多操作可能会导致插件的用户体验变慢。

使用适当的 ConferenceData 字段存储会议数据

构建 ConferenceData 对象时,您可以使用会议详细信息(访问代码、电话号码、PIN 码、URI 等)填充这些对象。请务必对此信息使用相应的 EntryPoint 字段。请勿将这些详细信息放在 ConferenceData 备注字段中。

请勿在 Google 日历活动中附加会议详细信息

该插件无需将已创建的第三方会议的相关信息添加到 Google 日历活动说明中。Google 日历会在必要时自动执行此操作。