アドオンの設計に関するガイドに沿って、ユーザーの全体的なエクスペリエンスを改善します。
一般的なベスト プラクティス
開発するすべてのアドオンで、次のベスト プラクティスを使用することをおすすめします。
開始前にアドオンの所有権を判断する
アドオンは Apps Script プロジェクトで定義されます。このプロジェクトは、特定のアカウントが所有するか、共有ドライブに配置する必要があります。アドオンをコーディングする前に、プロジェクトを所有するアカウントと、パブリッシャーとして機能するアカウントを決定します。また、共同編集者として機能するアカウントを決定し、それらのアカウントがスクリプト プロジェクトとそれに関連付けられた Google Cloud プロジェクトにアクセスできることを確認します。
Google Workspace を拡張する、複製しない
アドオンは、拡張する Google Workspace アプリケーションに新しい機能を提供したり、複雑なタスクを自動化したりすることを目的としています。アプリ内にすでに存在する機能を単純に複製するアドオンや、ワークフローを大幅に改善しないアドオンは、公開のためのアドオン審査に合格しない可能性があります。
スコープを狭くする
スコープを明示的に定義する場合は、可能な限り制限の少ないスコープ セットを選択してください。たとえば、読み取りアクセス権のみが必要な場合は、https://www.googleapis.com/auth/calendar スコープを使用してユーザーのカレンダーへの完全アクセス権をアドオンがリクエストしないようにします。読み取り専用アクセスの場合は、https://www.googleapis.com/auth/calendar.readonly スコープを使用します。
ライブラリに過度に依存しない
Apps Script のライブラリを使用すると、すべての Apps Script コードが 1 つのスクリプト プロジェクトに含まれている場合よりも、アドオンの実行速度が遅くなる可能性があります。Apps Script ライブラリはアドオンで動作しますが、使用するとパフォーマンスが低下する可能性があります。不要なライブラリをプロジェクトに含めないようにし、アドオンのライブラリへの依存を減らす方法を検討します。
上記のレイテンシは、サーバーサイド ライブラリとして使用される Apps Script プロジェクトにのみ適用されます。jQuery などのクライアントサイド JavaScript ライブラリは、このレイテンシが発生することなく自由に使用できます。
Google Workspace アドオンのベスト プラクティス
以下のベスト プラクティスは、Google Workspace アドオンとカード サービスの使用にのみ適用されます。
使用するカードを減らす
アドオンで使用するカードが多すぎると、ナビゲーションの構成が複雑になり、管理が難しくなります。
必要以上にカードを作成しないようにします。
ウィジェット作成関数を使用する
Card などの複雑な UI オブジェクトを作成するコードを記述する場合は、そのコードを独自の関数に配置することを検討してください。この作成関数は、オブジェクトをビルドして返すだけです。これにより、UI を更新する必要があるときに、そのオブジェクトをすばやく再生成できます。カード サービスでビルダークラスを使用した後は、必ず build() を呼び出してください。
カードはシンプルに
カードにウィジェットが多すぎると、画面のスペースを占有しすぎて、使いづらくなる可能性があります。大きなカード セクションは、折りたたみ可能な UI 要素としてレンダリングされますが、これによりユーザーから情報が隠されます。アドオンを合理化し、ユーザーが必要とするものを正確に提供するようにします。
エラーカードを使用する
エラー状態のカードを作成する。アドオンでエラーが発生した場合は、エラー情報と、可能であれば修正方法を示すカードが表示されます。たとえば、承認に失敗したためにアドオンが Google 以外のサービスに接続できなかった場合は、その旨を示すカードを表示し、使用しているアカウント情報を確認するようユーザーに依頼します。
テストとテスト メッセージを作成する
作成したすべてのアドオンを十分にテストする必要があります。テストデータを使用してカードとウィジェットを作成するテスト関数を作成し、オブジェクトが想定どおりに作成されていることを確認します。
通常、アクション コールバック関数を使用する場合は、レスポンス オブジェクトを作成する必要があります。次のようなステートメントを使用して、レスポンスが正しく作成されていることを確認できます。
Logger.log(response.printJson());
作成したテスト関数は、[Run] メニューを使用して Apps Script エディタから直接実行できます。有効なアドオンが動作したら、テストできるように未公開バージョンをインストールしてください。
アドオンが拡張するホスト アプリケーションごとに適切なテストデータを使用します。たとえば、アドオンが Gmail を拡張する場合は、さまざまなメッセージ コンテンツが指定されたときにアドオンが想定どおりに機能することを確認するために、いくつかのテストメールとそのメッセージ ID が必要になる可能性があります。特定のメッセージのメール ID を取得するには、Gmail API users.messages.list メソッドを使用してメールを一覧表示するか、Apps Script の Gmail サービスを使用します。
カレンダー カンファレンスのベスト プラクティス
アドオンで サードパーティのカレンダー会議オプションを Google カレンダーに統合する場合は、次のベスト プラクティスも実施してください。
onCreateFunction ライトを点灯したままにする
マニフェストで定義した各 onCreateFunction は、ユーザーがそのタイプの会議ソリューションを作成しようとすると同期的に呼び出されます。これらの関数は、会議の作成に必要な最小限の作業のみを行うようにしてください。これらの関数で処理を行うことが多すぎると、アドオンのユーザー エクスペリエンスが低下する可能性があります。
会議データに適切な ConferenceData フィールドを使用する
ConferenceData オブジェクトを作成するときに、会議の詳細（アクセスコード、電話番号、ピン、URI など）を入力できます。この情報には、対応する EntryPoint フィールドを使用してください。これらの詳細は ConferenceData メモ フィールドに入力しないでください。
カレンダーの予定に会議の詳細を追加しない
アドオンで、作成されたサードパーティ製会議に関する情報をカレンダーの予定の説明に追加する必要はありません。カレンダーでは、必要に応じてこの処理が自動的に行われます。