原始通知概述

原始通知是简短的通用推送通知。 原始通知有严格的指令,不包含 UI 组件。 与其他推送通知一样,Windows 推送通知服务(WNS)功能将原始通知从云服务传送到应用。

可以将原始通知用于各种目的,包括触发应用以运行后台任务(如果用户已授予应用执行此操作的权限)。 通过使用 WNS 与应用通信,可以避免创建持久性套接字连接、发送 HTTP GET 消息和其他服务到应用连接所产生的处理开销。

重要

若要了解原始通知,最好熟悉 Windows 推送通知服务(WNS)概述讨论的概念。

 

与 Toast、磁贴和锁屏提醒推送通知一样,原始通知通过分配的通道统一资源标识符(URI)从应用的云服务推送到 WNS。 反过来,WNS 会将通知传送到与该通道关联的设备和用户帐户。 与其他推送通知不同,原始通知没有指定的格式。 有效负载的内容完全由应用定义。

作为可能受益于原始通知的应用的插图,让我们看看一个理论文档协作应用。 请考虑同时编辑同一文档的两个用户。 托管共享文档的云服务可以使用原始通知在其他用户进行更改时通知每个用户。 原始通知不一定包含对文档的更改,而是向每个用户的应用副本发出信号,以联系中心位置并同步可用的更改。 通过使用原始通知,应用及其云服务可以节省在文档打开时保持持久连接的开销。

原始通知的工作原理

所有原始通知都是推送通知。 因此,发送和接收推送通知所需的设置也适用于原始通知:

  • 必须具有有效的 WNS 通道才能发送原始通知。 有关获取推送通知通道的详细信息,请参阅 如何请求、创建和保存通知通道
  • 必须在 应用的清单中包含 Internet 功能。 在 Microsoft Visual Studio 清单编辑器中,可以在“功能”选项卡下找到此选项作为 Internet(客户端)。 有关详细信息,请参阅功能

通知正文采用应用定义格式。 客户端以空终止字符串(HSTRING)的形式接收数据,该字符串仅需要由应用理解。

如果客户端处于脱机状态,则仅当通知中包含 X-WNS-Cache-Policy 标头时,才会由 WNS 缓存原始通知。 但是,一旦设备重新联机,只会缓存并传送一个原始通知。

原始通知在客户端上只提供三个可能的路径:它们将通过通知传递事件传递到正在运行的应用、发送到后台任务或删除。 因此,如果客户端处于脱机状态,并且 WNS 尝试传递原始通知,则会删除通知。

创建原始通知

发送原始通知类似于发送磁贴、Toast 或锁屏提醒推送通知,但存在以下差异:

  • HTTP Content-Type 标头必须设置为“application/octet-stream”。
  • HTTP X-WNS-Type 标头必须设置为“wns/raw”。
  • 通知正文可以包含大小小于 5 KB 的任何字符串有效负载,但不能是空字符串。

原始通知旨在用作短消息,用于触发应用执行操作,例如直接联系服务以同步大量数据或基于通知内容进行本地状态修改。 请注意,无法保证传递 WNS 推送通知,因此你的应用和云服务必须考虑到原始通知可能无法到达客户端的可能性,例如客户端脱机时。

有关发送推送通知的详细信息,请参阅 快速入门:发送推送通知

接收原始通知

有两种途径可以接收原始通知:应用可通过以下两种方式接收原始通知:

应用可以使用这两种机制来接收原始通知。 如果应用同时实现由原始通知触发的通知传递事件处理程序和后台任务,则当应用运行时,通知传递事件将优先。

  • 如果应用正在运行,通知传递事件将优先于后台任务,并且应用将有机会处理通知。
  • 通知传递事件处理程序可以通过将事件的 PushNotificationReceivedEventArgs.Cancel 属性设置为 true 来指定,在处理程序退出后,不应将原始通知传递给其后台任务。 如果 Cancel 属性设置为 false 或未设置(默认值为 false),则原始通知将在通知传递事件处理程序完成其工作后触发后台任务。

通知传递事件

应用可以使用通知传送事件(PushNotificationReceived)在应用正在使用时接收原始通知。 当云服务发送原始通知时,正在运行的应用可以通过处理通道 URI 上的通知传送事件来接收它。

如果应用未运行并且未使用后台任务,则 WNS 会在接收时丢弃发送给该应用的任何原始通知。 为了避免浪费云服务的资源,应考虑在服务上实现逻辑来跟踪应用是否处于活动状态。 此信息有两个来源:应用可以显式告知服务它已准备好开始接收通知,WNS 可以告诉服务何时停止。

  • 应用通知云服务:应用可以联系其服务,让其知道应用在前台运行。 此方法的缺点是应用最终可能会非常频繁地联系你的服务。 但是,它的优点是,服务将始终知道应用何时准备好接收传入的原始通知。 另一个优点是,当应用联系其服务时,该服务会知道将原始通知发送到该应用的特定实例,而不是广播。

  • 云服务响应 WNS 响应消息 :应用服务可以使用 WNS 返回的 X-WNS-NotificationStatusX-WNS-DeviceConnectionStatus 信息来确定何时停止向应用发送原始通知。 当服务将通知作为 HTTP POST 发送到通道时,它可以在响应中接收以下消息之一:

    • X-WNS-NotificationStatus:已删除:这表示客户端未收到通知。 这是一个安全假设, 即丢弃 的响应是由应用不再位于用户设备上的前台造成的。
    • X-WNS-DeviceConnectionStatus:断开连接X-WNS-DeviceConnectionStatus:tempconnected:这表示 Windows 客户端不再与 WNS 建立连接。 请注意,若要从 WNS 接收此消息,必须在通知的 HTTP POST 中设置 X-WNS-RequestForStatus 标头来请求它。

    应用的云服务可以使用这些状态消息中的信息来停止通过原始通知的通信尝试。 当应用切换回前台时,服务可以在应用联系原始通知后恢复发送原始通知。

    请注意,不应依赖 X-WNS-NotificationStatus 来确定是否已将通知成功传送到客户端。

    有关详细信息,请参阅 推送通知服务请求和响应标头

由原始通知触发的后台任务

重要

在使用原始通知后台任务之前,必须通过 BackgroundExecutionManager.RequestAccessAsync 授予应用后台访问权限。

 

后台任务必须注册到 PushNotificationTrigger 如果未注册,则收到原始通知时,任务将不会运行。

原始通知触发的后台任务使应用的云服务能够与应用联系,即使应用未运行(尽管它可能会触发它来运行)。 这种情况发生时,应用无需维护连续连接。 原始通知是唯一可以触发后台任务的通知类型。 但是,尽管 Toast、磁贴和锁屏提醒推送通知无法触发后台任务,但原始通知触发的后台任务可以通过本地 API 调用更新磁贴和调用 Toast 通知。

作为原始通知触发的后台任务工作方式的插图,让我们考虑一个用于阅读电子书的应用。 首先,用户可能在另一台设备上在线购买书籍。 作为响应,应用的云服务可以向每个用户的设备发送原始通知,该有效负载指出已购买书籍,并且应用应下载它。 然后,应用会直接与应用的云服务联系,开始新书的后台下载,以便以后,当用户启动应用时,该书已经在那里并准备好阅读。

若要使用原始通知触发后台任务,应用必须:

  1. 使用 BackgroundExecutionManager.RequestAccessAsync 请求在后台运行任务的权限(用户可以随时撤销这些任务)。
  2. 实现后台任务。 有关详细信息,请参阅使用后台任务支持应用

然后,在响应 PushNotificationTrigger 时调用后台任务,每次收到应用的原始通知。 你的后台任务解释原始通知的应用特定有效负载并对其执行操作。

对于每个应用,一次只能运行一个后台任务。 如果为已运行后台任务的应用触发后台任务,则必须先完成第一个后台任务,然后才能运行新任务。

其他资源

你可以通过下载 适用于 Windows 8.1 的原始通知示例 以及 适用于 Windows 8.1 的推送和定期通知示例 ,并在 Windows 10 应用中重新使用其源代码来了解详细信息。