Gravio Action App Package開発ガイド (現在Gravio StudioでのGUIでの開発はサポートされていません。)

目次

• 1. Action App Packageとは
• 1.1 従来の仕組みからの進化
• 1.2 Appパッケージの利点
• 2. Action App Packageの構造
• 2.1 基本ディレクトリ構成
• 2.2 各ディレクトリの役割
• 3. Action App Packageの作成手順
• 3.1 作成の基本フロー
• 3.2 ファイルの配置ルール
• 4. パッケージ間の参照制御
• 4.1 App内のアクション参照
• 4.2 グローバルアクションとの関係
• 5. 他のHubへの配布方法
• 5.1 パッケージのエクスポート
• 5.2 配布時の注意点
• 6. 既知の制限と非互換ポイント
• 7. 将来の展望
• 7.1 ベースプロパティの取り扱い改善
• 7.2 グローバル・App連携の強化

1. Action App Packageとは (現在このPackage形式はGravio Studioからは作成できません。)

Action App Package（以下、Appパッケージ）は、Gravioのアクション、トリガー、関連リソースを一つのパッケージにまとめて管理・配布するための仕組みです。アクションフローを効率的に開発し、他のHubシステムへ簡単に展開できることを目的としています。

1.1 従来の仕組み(機能パッケージ)からの進化

Appパッケージの開発に至るまでには、いくつかの段階がありました：

• ポータビリティを実現
• アプリ内にトリガーやアクションの実行に必要なすべてのファイルを内包
• 異なるHub環境へ移植しても動作できる設計

1.2 Appパッケージの利点

Appパッケージには以下のような利点があります：

• 移植性の向上：パッケージ全体を他のHubに移動して、追加設定なしで動作させることができます
• アクセス制御：パッケージ内のリソースは外部から分離され、整理された状態を維持します
• 配布の容易さ：ファイル変更なしで他のHubに展開できるため、配布が簡単です
• 名前空間の分離：パッケージ内の各リソースはグローバル環境と分離された名前空間を持ちます

2. Action App Packageの構造

2.1 基本ディレクトリ構成

Appパッケージは以下のディレクトリ構成で実装されています：

actmgr/actions/
+- [アプリ名].app/
   +- actions/      # アクションファイル
   |  +- a.acs
   |  +- b.acs
   +- data/         # リソースファイル
   |  +- sounds/
   |     +- a.mp3
   +- triggers/     # トリガー設定
   |  +- events/
   |  |  +- xxx.json
   |  +- timers/
   |  +- calendars/
   +- bases/        # ベースプロパティ
   |  +- xxx.basp
   +- layers/       # レイヤー情報（開発中）

2.2 各ディレクトリの役割

• actions/：Appパッケージ内のアクションファイル（.acs）を格納します
• data/：アクションが参照する各種リソースファイルを格納します
• triggers/：イベントトリガー、タイマートリガー、カレンダートリガーなどの設定を格納します
• bases/：コンポーネントが使用するベースプロパティを格納します
• layers/：レイヤー関連情報を格納します（※現在開発中）

3. Action App Packageの作成手順

3.1 作成の基本フロー

Appパッケージを新規作成する基本的な手順は以下の通りです：

1. actmgr/actions ディレクトリに拡張子 .app でディレクトリを作成します
2. 必要なサブディレクトリ構造を作成します：
3. actions/
4. data/
5. triggers/events/
6. triggers/timers/
7. triggers/calendars/
8. bases/
9. layers/ （※現時点では将来対応）
10. 既存のアクションやリソースファイルを適切なディレクトリに配置します
11. Trigger Managerでリロードを実行し、パッケージを有効化します

3.2 ファイルの配置ルール

ファイルの配置には以下のルールがあります：

1. アクションファイル：.acs ファイルは actions/ ディレクトリに配置します
2. トリガーファイル：各種トリガーファイルを triggers/ の適切なサブディレクトリに配置します
3. ベースプロパティ：使用するベースプロパティを bases/ ディレクトリに配置します
4. リソースファイル：コンポーネントから参照するファイルを data/ 以下の適切なディレクトリに配置します

重要なのは、ファイルの内容を変更せずにそのままコピーするだけで動作することです。IDはグローバル環境と分離されるため、ID重複の問題は発生しません。

4. パッケージ間の参照制御

4.1 App内のアクション参照

Appパッケージ内のトリガーやアクションは、原則として同一パッケージ内のリソースのみを参照します：

• トリガー内でアクションIDを指定した場合、同一App内のアクションのみを参照します
• Call/Jumpコンポーネントで別のアクションを指定した場合も同一App内を検索します
• ベースプロパティの参照は同一App内のものを優先します
• ファイル参照はApp内の data/ ディレクトリを基点として解決されます

4.2 グローバルアクションとの関係

グローバル環境とAppパッケージの間には以下の関係があります：

• グローバルトリガーからAppパッケージ内のアクションを実行するには、appname/actionid 形式で指定します
• App内のトリガーが起動するアクションはApp内のもののみです（同じIDのグローバルアクションは起動しません）
• 内部的には、App内のアクションIDは appname/actionid 形式に変換されて処理されます

5. 他のHubへの配布方法

5.1 パッケージのエクスポート

Appパッケージを他のHubに配布する手順は以下の通りです：

1. .app ディレクトリ全体をアーカイブします
2. アーカイブファイルを配布先のHubに転送します
3. 配布先のHubで actmgr/actions/ ディレクトリに展開します
4. Trigger Managerのリロード機能を実行してパッケージを有効化します

5.2 配布時の注意点

• ファイル内容の変更は不要です（そのままの状態で動作します）
• 配布先のHubで同じトリガー条件が満たされると、パッケージのアクションが実行されます
• 現時点ではレイヤー情報の移植は完全にはサポートされていません

6. 既知の制限と非互換ポイント

Appパッケージには以下の制限や非互換ポイントがあります：

• ファイル参照の相対パス：.. などを使用して data ディレクトリの外を参照するケースでは、グローバルアクションとApp内アクションで参照先が異なります
• ベースプロパティの固定化：ベースプロパティも含めてパッケージ化するため、環境固有の設定（SMTPサーバーなど）が固定されてしまいます
• セキュリティ上の懸念：暗号化されているとはいえ、パスワードなどの情報をパッケージに含めて配布する必要があります

7. 将来の改善の方向性

7.1 ベースプロパティの取り扱い改善

ベースプロパティについては以下の改善が検討されています：

• ベースプロパティのIDをユーザーが指定できるようにする
• グローバルなベースプロパティをApp内のものより優先して使用できるようにする
• ベースプロパティを含めずに参照情報のみをパッケージ化するオプションを提供する

これにより、配布先の環境に合わせた設定で動作させる柔軟性が向上します。