使用活动源 REST API

命名空间：microsoft.graph

可以使用 Microsoft Graph 中的活动源 API 跨设备和平台恢复用户的活动。活动源 API 请求通过委派的权限和用户活动权限代表用户执行，这些权限可用于个人或工作和学校帐户。

用户活动由活动资源表示，并在集合 me/activities 表示的基于时间的源中组织。

是什么造就了出色的用户活动？

用户活动不只是启动应用，它们是应用中特定内容的深层链接。你创建的用户活动不仅可以在你自己的应用中使用，而且还会显示在 Cortana 和 Windows 时间线中，从而推动更多的应用重新接触，并使用户能够更轻松地跨多个设备继续使用你的应用。

由于每个应用都是不同的，因此每个应用开发人员需要了解将应用程序中的操作映射到用户活动的最佳方法。例如，游戏可能会为每个市场活动创建活动，文档创作应用可能会为每个唯一文档创建一个活动，业务线应用可能会为每个工作流创建一个活动。

在应用中定义活动时，请应用以下准则：

DO： 记录一组相关用户操作的单个活动。如果应用程序用于一系列相关内容，则记录整个参与会话的单个活动可能有意义。

播放列表方案： 这与音乐播放列表或电视节目特别相关，单个用户活动可以更新以显示进度。在这种情况下，你有一个用户活动，其中包含多个历史记录项，这些历史记录项表示跨多天或多周的参与期。

DO： 将用户数据存储到云中。如果要支持跨设备活动，则需要确保将重新进行此活动所需的内容存储在云位置。例如，如果在每次用户编辑文档时发布活动，则应将文档存储在云中，而不是存储在用户的设备上本地，以便启用跨设备重新参与。

不要： 为用户将来不需要恢复的操作创建用户活动。如果应用程序用于完成简单的一次性操作，这些操作不会保留状态以供将来跟踪，则可能不需要编写用户活动。

需要明确的是，即使用户活动显示在 Windows 时间线中，也不设计为版本控制工具，选择基于文档的活动应始终显示该文档的最新版本 (包括其他用户所做的更改。)

不要： 为其他用户完成的操作创建用户活动。如果有人向用户或 @mentions 应用内的用户发送消息，则不应编写新活动。通过显示通知可以更好地提供这些交互。

协作方案：如果多人正在处理同一活动 (（例如Word文档) ），则在某些情况下，其他用户在上次编辑文档后对文档进行了更改。在这种情况下，应用开发人员可能需要更新活动中的视觉元素，以反映对文档所做的更改。为此，应用可能会更新现有活动，而无需创建新的历史记录项。

注意：如果要为 Web 应用程序发布活动，请务必为每个活动同时activationURL包含和。fallbackURL 这些活动将按预期从 Microsoft 体验（如 Windows 时间线）启动用户返回到你的应用。

创建的用户活动将因应用的交互模式而异。虽然每个应用都不同，但大多数应用将属于以下交互模式之一：

基于文档的应用 - 为每个文档创建一个活动，其中包含一个或多个反映使用周期的历史记录。在对文档进行更改时，更新活动卡非常重要。
媒体播放应用 - 为每个内容（例如播放列表、程序或独立内容）的逻辑分组创建一个活动。
游戏 — 为每个保存的游戏或世界创建一个活动。如果游戏仅支持单个关卡序列，则可以随时间推移编写相同的活动，不过你可能希望更新卡以显示最新进度或成就。
实用工具应用 - 如果应用中没有任何用户想要恢复的内容，则不应发布活动。一个很好的示例是一个简单的单一用途应用，例如计算器。
业务线应用 - 存在许多用于管理简单任务或工作流的应用。为通过应用访问的每个单独工作流创建一个活动。例如，每个费用报表都是单独的活动，因为您可能希望选择该活动以查看它是否已获得批准。

一些复杂的应用包含多个交互模式。你可能希望针对应用处理的不同方案遵循不同的用户活动创建模式。

正在寻找更多想法？