アクティビティ フィード REST API を使用する
名前空間: microsoft.graph
Microsoft Graph のアクティビティ フィード API を使用して、デバイスとプラットフォーム間でユーザーのアクティビティを再開できます。 アクティビティ フィード API 要求は、 委任されたアクセス許可 と ユーザー アクティビティのアクセス許可を介してユーザーに代わって実行されます。これは、個人または職場および学校のアカウントで使用できます。
ユーザー アクティビティは アクティビティ リソースによって表され、コレクション me/activity によって表される時間ベースのフィードで編成されます。
優れたユーザー アクティビティとは
ユーザー アクティビティはアプリを起動するだけでなく、アプリ内の特定のコンテンツへのディープ リンクです。 作成したユーザー アクティビティは、独自のアプリで使用できるだけでなく、Cortana と Windows タイムラインにも表示されます。アプリの再エンゲゲメントが増え、ユーザーが複数のデバイス間でアプリを使い続けやすくなります。
アクティビティになるには何が必要ですか?
すべてのアプリが異なるため、アプリケーション内のアクションをユーザー アクティビティにマップする最善の方法を理解するのは、各アプリ開発者が理解する必要があります。 たとえば、ゲームはキャンペーンごとにアクティビティを作成し、ドキュメント作成アプリは一意のドキュメントごとにアクティビティを作成し、基幹業務アプリはワークフローごとにアクティビティを作成する場合があります。
アプリでアクティビティを定義するときに、次のガイドラインを適用します。
DO: 関連するユーザー アクションのグループに対して 1 つのアクティビティを記録します。 関連する一連のコンテンツにアプリケーションを使用する場合は、エンゲージメント セッション全体の 1 つのアクティビティを記録するのが理にかなっている可能性があります。
プレイリストのシナリオ: これは、音楽プレイリストやテレビ番組に特に関連します。1 人のユーザー アクティビティを更新して進行状況を表示できます。 この場合、複数日または数週間にわたるエンゲージメント期間を表す複数の 履歴項目 を持つ 1 人のユーザー アクティビティがあります。
DO: ユーザー データをクラウドに格納します。 デバイス間アクティビティをサポートする場合は、このアクティビティの再エンゲインに必要なコンテンツがクラウドの場所に格納されていることを確認する必要があります。 たとえば、ユーザーがドキュメントを編集するたびにアクティビティを発行する場合、クロスデバイスの再エンゲゲメントを有効にするために、ドキュメントはユーザーのデバイス上のローカルではなくクラウドに格納する必要があります。
できません: ユーザーが今後再開する必要のないアクションのユーザー アクティビティを作成します。 アプリケーションを使用して、後で追跡するための状態を保持しない単純な 1 回限りの操作を完了する場合は、ユーザー アクティビティを記述する必要はないでしょう。
明らかに、Windows タイムラインにユーザー アクティビティが表示されていても、これはバージョン管理ツールとして設計されていません。ドキュメント ベースのアクティビティを選択すると、常にそのドキュメントの最新バージョン (別のユーザーによって行われた変更を含む) が表示されます。
できません: 他のユーザーが完了したアクションの ユーザー アクティビティを作成します。 ユーザーにメッセージまたは @mentions アプリ内のユーザーを送信する場合は、新しいアクティビティを記述しないでください。 これらのやり取りは、通知を表示することによって提供される方が適切です。
コラボレーション シナリオ:複数のユーザーが同じアクティビティ (ドキュメントのWordなど) で作業している場合は、最後に編集した後に別のユーザーがドキュメントに変更を加えた場合があります。 この場合、アプリ開発者は、ドキュメントに加えられた変更を反映するようにアクティビティ内のビジュアル要素を更新する必要があります。 これを行うには、アプリが新しい履歴項目を作成せずに既存のアクティビティを更新する場合があります。
メモ:Web アプリケーションのアクティビティを発行する場合は、アクティビティごとに と の両方を
activationURL
fallbackURL
含める必要があります。 アクティビティは、Windows タイムラインなどの Microsoft エクスペリエンスから期待どおりにユーザーをアプリに戻して起動します。
アプリの操作パターンとユーザー アクティビティ
作成するユーザー アクティビティは、アプリの対話パターンによって異なります。 すべてのアプリは異なりますが、ほとんどのアプリは次のいずれかの操作パターンに分類されます。
- ドキュメント ベースのアプリ - 使用期間を反映した 1 つ以上の履歴レコードを含む、ドキュメントごとに 1 つのアクティビティを作成します。 ドキュメントに変更が加えられたので、アクティビティカードを更新することが重要です。
- メディア再生アプリ - プレイリスト、プログラム、スタンドアロン コンテンツなどのコンテンツの論理グループごとに 1 つのアクティビティを作成します。
- ゲーム - 保存したゲームまたはワールドごとに 1 つのアクティビティを作成します。 ゲームでサポートされているレベルのシーケンスが 1 つだけの場合は、時間の経過と同時に同じアクティビティを記述できますが、最新の進行状況や実績を表示するようにカードを更新することもできます。
- ユーティリティ アプリ - ユーザーが再開する必要があるアプリ内に何もない場合は、アクティビティを発行しないでください。 良い例は、電卓のような単純な単一目的のアプリです。
- 基幹業務アプリ - 単純なタスクやワークフローを管理するために、多くのアプリが存在します。 アプリからアクセスする個別のワークフローごとに 1 つのアクティビティを作成します。 たとえば、各経費精算書は個別のアクティビティになります。これは、そのアクティビティを選択して、承認されたかどうかを確認する場合があるためです。
一部の複雑なアプリには、複数の対話パターンが含まれています。 アプリによって処理されるシナリオごとに、さまざまなユーザー アクティビティ作成パターンに従う必要がある場合があります。
次の手順
- アクティビティ リソースを参照し、アプリのアクティビティを定義して、ユーザーが重要なタスクを再開できるようにします。
- アダプティブ カード サンプル サンプルを調べて、アクティビティをポップにするためのアイデアを確認します。
- Graph エクスプローラーで API をお試しください。
その他のアイデアをお探しですか?