CN108780409A - 通用通知流水线 - Google Patents

Abstract

本文所描述的发明的实施例涉及用于处理用户界面通知的通用方法。设备上的通知流水线用作设备上的应用与设备上的通知表面之间的中介。通知表面向通知流水线注册其自己以成为活动订户。应用或其他进程向通知流水线提交符合相同格式、模式、结构等的通知。通知流水线向订阅的通知表面广播通知，订阅的通知表面又基于通知的内容来确定是否或如何处理和可能显示通知。

Description

通用通知流水线

背景技术

计算的目标是向人们提供信息。假定一个人使用计算设备来访问信息，竞争因素可以与如何以及何时呈现信息有关。例如，用户的目标可能根据可用时间量、用户参与的活动、可用信息的重要性等而变化。可用信息的量和类型以及信息变得可用的频率可以变化很大。此外，显示信息的计算设备具有广泛的功率容量、计算能力、显示尺寸以及输入设备类型。给定的信息可能用于佩戴在手腕上的小设备和在建筑物大厅中的具有大显示器的设备。

为了适应信息呈现因素的多样性和复杂性，软件开发人员已经设计了不同类型的通知机制或通知表面。例如，很多操作***或图形用户外壳为不同的上下文提供不同的通知表面。例如，锁定屏幕或登录屏幕可能具有通知表面，用于启动应用的“主页”或“开始”屏幕可能具有能够显示通知或关于它们的信息的图标，工具或状态栏可能具有可以被激活以显示通知的用户界面元素，或者可以提供“吐司(toast)”通知表面。在任何情况下，这些类型的通知表面通常具有不同的大小，消费不同类型或格式的信息，实现不同的语义，并且通过不同的应用编程接口(API)或协议进行对接。

发明人已经单独意识到，开发人员变得难以编写可以利用在不同平台上可用的各种通知表面的软件。发明人已经意识到，编写用于传播单个信息项的软件的开发人员当前可能需要编写很多代码段，每个代码段针对相应的通知表面进行定制。另外，如果旨在通过同一设备的多个通知表面显示单个通知信息项，则可能需要传输具有不同内容和格式的多个通知消息，从而导致相同信息项的重复传输，可能导致多个进程“唤醒”和接收设备处的其他开销。因此，发明人单独已经意识到，在计算设备上提供通用通知机制可以潜在地缓解与通知表面的扩散相关的一些问题。

发明内容

包括以下发明内容仅是为了介绍在以下具体实施方式中讨论的一些概念。本发明内容并不全面，并且不旨在描述由最后提出的权利要求阐述的所要求保护的主题的范围。

本文所描述的发明的实施例涉及用于处理用户界面通知的通用方法。设备上的通知流水线用作设备上的应用与设备上的通知表面之间的中介。通知表面可以将自己注册到通知流水线以成为流水线的活动订户。应用或其他进程向通知流水线提交符合相同格式、模式、结构等的通知。通知流水线向订阅的通知表面广播通知，订阅的通知表面又基于通知的内容来确定是否或如何处理和可能显示通知中的信息。

下面将参考结合附图考虑的以下具体实施方式来解释很多伴随特征。

附图说明

从以下根据附图阅读的详细描述将更好地理解本说明书，其中相同的附图标记用于表示所附说明书中的相同部分。

图1示出了通知表面图形的示例。

图2示出了通知表面可以在其中执行的计算设备和软件环境。

图3示出了具有不同的通知表面的计算设备的示例。

图4示出了通知表面的未协调使用的示例场景的细节。

图5示出了通知流水线的一个实施例。

图6示出了通知流水线的另一实施例。

图7示出了通知订阅列表如何随时间改变的示例。

图8示出了不同的通知表面分别如何处理相同的通知。

图9概念性地示出了通知流水线如何使得不同的通知发布者能够向订户指定分类通知意图。

图10示出了计算设备的示例。

具体实施方式

以下讨论的实施例涉及通用通知流水线。首先将总体上描述通知表面，其包括一些图形属性、它们的技术特征以及它们是如何实现的。接下来描述通知流水线。解释发布者订户设计、以及用于将通知流水线集成到现有的通知表面或管理器中的技术。

图1示出了可以由同一计算设备显示的通知表面图形的示例。如背景技术中所讨论的，各种通知表面是已知的并且在使用中。本文中描述的实施例可以由现有的和新的通知表面来方便地使用。本文中使用的术语“通知表面”是指计算设备上的可执行软件以及它们生成和控制的图形用户界面(GUI)元素。通常，大多数通知表面已经通过相应的唯一API等对在相关计算设备上执行的任何软件或应用可访问。大多数通知表面具有不同的行为和外观。如图1所示，通知表面通常以动态图标100的形式并入图形用户外壳中：可能出现在图形外壳的“桌面”或侧边栏的信息面板102、吐司小部件104等。作为图形用户外壳的一部分，一些通知表面能够“弹出”或覆盖其他图形。一些通知可以并入登录或锁定屏幕中。一些通知表面可以具有用于解除通知、打开相关内容或应用等的交互式GUI元素108。一些通知表面可以仅以非交互方式显示信息。一些通知表面是自主操作***进程，而一些通知表面则集成到操作***中。

图2示出了通知表面可以在其中执行的计算设备120和软件环境。计算设备120具有管理进程124的操作***122，进程124包括窗口***125，窗口***125针对一些进程(例如，应用)管理显示在显示器128上的窗口126的显示。计算设备120可以是后面参考图10所描述的各种类型中的任何一种。计算设备120至少具有存储硬件和用于执行操作***122和进程124的处理器硬件。窗口***125可以是任何类型的窗口***，例如平铺、“自由形式”、单个窗口(一次只显示一个应用窗口)，等等。进程是公知的操作***对象，它们是离散地管理的执行单元，通常具有进程标识符、由操作***122管理的存储器(堆和/或堆栈存储器)，并且可以在由操作***122维持的进程标识符等的进程表中进行管理。

图3示出了具有不同的通知表面的计算设备的示例。如上所述，GUI外壳140或环境通常包括不同类型的通知表面。通知表面可以作为相应进程来执行。例如，吐司管理器142、徽章管理器144、登录屏幕146和状态栏148(或侧边栏、工具栏等)可以是相应进程或同一进程的不同组件/接口。一些GUI外壳还包括管理动态图块或图标的外观、显示、布局和用户激活的分片管理器(未示出)，其用作应用启动图标以及可以显示所表示的应用的通知的迷你窗口。

本地软件元素(通常是应用150)在计算设备120上执行，并且向它们被编程为与之对接的任何通知表面提交通知。为了适应经由网络接口卡152和网络堆栈154从网络接收的远程通知，推送***156后台进程可以接收和处理网络通知，例如以超文本传输协议(HTTP)消息的形式。从图3中可以看出，每个通知客户端必须直接与它旨在使用的通知表面进行通信。

图4示出了通知表面的未协调使用的示例场景的细节。每个所描绘的通知表面具有它们自己的API 142A、144A、148A。图4中的通知的阴影对应于它们相应的API 142A、144A、148A的阴影。推送通知服务160可以从用户设备162(例如，智能电话)接收消息，推送通知服务160使用该消息构建通知N1，通知N1经由网络164被推送给推送***156，例如作为包含应用的HTTP消息，其标识唯一的统一资源标识符(URI)。推送通知服务160还接收由云服务166从另一用户设备162中继的通知N2。通知N2由推送***156接收，推送***156将N2传递给应用150(应用1)，应用150可以将N2转换成经由API 142A(API1)传递给吐司管理器142A的相应的数据结构或对象。云服务166还发起其自己的通知N3和N4。通知N3被直接传输到徽章管理器144的自定义网络***，并且通知N4被传输到应用152(应用2)，应用152可能在重新格式化或重新打包N4通知之后调用相应的API 148A(API3)以向状态栏148提交通知。应用150(应用2)还发起用于徽章管理器144的API 144A(API2)的通知N5。类似地，应用150(应用1)发起被提交给徽章管理器144的通知N6。相关的通知表面以已知的方式接收和处理它们的通知，这通常涉及渲染通知图形以通知使用计算设备120的人员。

从图4中可以看出，每个客户端对于其旨在使用的每个通知表面需要不同的代码。即使所有通知表面使用通用格式或模式以封装通知内容，也涉及不同的API，并且每个通知表面需要单独的通信以接收相同的通知内容或信息。此外，在有状态通知的情况下，如果客户端旨在使用不同的通知表面来通知同一条信息，如果一个通知的状态发生变化，则在理想情况下，客户端必须检测通知变化并且与其他通知表面通信以向它们通知状态变化。

图5示出了通知流水线180的实施例。根据其实现方式，通知流水线180可以消除处理多个通知表面的一些缺点，而无需对现有通知表面或***进行重大修改。通知流水线180实现发布订阅(“pub-sub”)设计模式。通知表面及其客户端使用通知流水线180来中继通知的交换。如图5所示，诸如推送***156A和应用150A等客户端与其先前讨论的对应物不同。通知表面142B、144B、146B和148B也与其先前的同类不同。客户端和通知表面都以多种方式进行修改。

首先，应当构建或修改客户端和通知表面以使用公共通知格式。通知流水线180的pub-sub设计的一方面是，由通知流水线180从客户端接收的每个通知被传递到当前订阅到通知流水线180的每个通知表面。参与的任何客户端或通知表面应当实现相同的通知格式或数据结构。例如，如果通知有效负载实现为可扩展标记语言(XML)代码，则每个通知应当符合相同的XML模式。在这种情况下，应当将客户端编程为将其通知格式化为符合通知模式的XML代码。在上面在“相关申请”部分中引用的申请中描述了示例。可以使用其他类型的数据封装或格式化以用于通知。例如，明确定义的数据结构(例如，JavaScript对象符号)、可移植对象、文本形式的键值对集合等。需要注意的将是“合同”或理解任何订阅的通知表面将能够至少解析和解释(可能使用其他设施)符合商定数据格式的通知。通知表面如何处理合规通知的内容(如果有的话)取决于通知表面。虽然，语义约定可以附加到通知的功能。

其次，客户端和通知表面应当被编码为使用相同的API或其他类型的软件接口以访问通知流水线180。通知流水线API可以像“订阅()”调用、“发布()”调用、可能还有“取消订阅()”调用一样简单，尽管其他调用或方法可能会有所帮助，如后面所述。如下面详细描述的，通知表面调用“订阅()”或等同物以成为订户并且因此接收通知。客户端调用“发布()”以作为参数、事件等传递通知。

图5的左侧示出了订阅步骤。在步骤182，调用订阅()功能，并且在步骤184，通知流水线180通过将调用者添加到当前订阅的通知表面的列表来进行响应(参见图6中的订阅列表204)。图5的左侧还示出了发布步骤。在步骤186，诸如推送***156A等客户端调用订阅()功能以提交标准化通知(符合“合同”的通知)。作为响应，在步骤188，通知流水线180将通知发布到已经使用订阅()调用注册的所有当前通知表面。在步骤190，订户接收通知。

图6示出了通知流水线180的实施例。通知N1-N5和API 200的相同阴影反映了客户和通知表面对通用通知方案或格式以及相同API200(或其他类型的软件接口)的使用。在图6中，假定每个示例性通知表面已经通过API 200调用了订阅功能202，并且通知流水线180已经将相应的标识符203添加到订阅列表204。当推送***156A要发布通知N1时，推送***156A调用发布功能(或函数)206。作为响应，发布功能206被执行以用于通知N1。发布功能从订阅列表204获取标识符，并且将通知N1传递给每个标识的通知表面。因此，利用一个API调用和一个通知消息或有效负载，推送***156A例如能够向多个通知表面提供相同的通知内容。类似地，通知N2-N5被发布。每次，来自发布客户端的一个通知事务导致通知的广播。

在一个实施例中，进程间通信(IPC)机制208可以用于将通知从通知流水线180传递到订阅的通知表面。例如，可以使用操作***的事件路由/下沉机制，其中每个通知表面监听通知类型事件并且为其实现事件处理程序。可以使用其他IPC机制，例如共享存储器、消息队列、流水线等。虽然开销和性能可能过高，但是通知流水线也可以被实现为构建在本地网络协议栈之上的应用层协议。例如，通知可以被形成为HTTP请求。内部生成的通知只会通过环回接口，并且来自网络的通知将由流水线直接处理(例如，可以避免推送***)。IPC方法可能更优选。

关于各种通知表面已经订阅的假定，通知表面能够方便地在其初始化代码中调用订阅功能202。典型的通知表面将在引导时、登录等处开始执行。一些通知表面可以利用取消订阅功能210(参见图7)来减少计算开销，降低功耗，或者适应某个应用特定的逻辑。

图7示出了订阅列表204如何随时间改变的示例。首先，为了处理通知发布请求，发布功能206读取订户表格或列表204，并且找到通知请求所发送到的订户标识符212ID1和ID2。接下来，通知表面调用取消订阅功能210以从订户列表204中移除其自身。尽管ID2被示出为参数，但实际上，通知表面可能不需要明确地标识自身；通知流水线180访问调用者的执行上下文等以标识订阅或取消订阅的表面。接下来，第三通知表面调用订阅功能202，订阅功能202又将其标识符(ID3)添加到订户列表204。响应于发布功能206的第二次调用以发布另一通知，再次读取订户列表204并且使用当前订户标识符212-ID1和ID3来发送第二通知。

图6还示出了动作功能214。动作功能214可以是可以针对通知的任何类型的动作。例如，动作功能214可以是由任何通知表面、客户端或其他软件可调用的“解除()”功能。解除功能对应于通知的解除。如果通知表面调用解除功能，则调用可能反映用户与相应表面的交互以解除通知。通知流水线180标识调用解除功能的表面，并且将解除消息或事件发布到其他订阅的通知表面。接收到解除消息的每个通知表面可以通过解除所标识的通知来进行响应。可以提供其他类型的动作或控制逻辑以协调通知表面的动作，从而减少各个应用(客户端)所需要的与通知相关的逻辑。

通知流水线180还可以实现网守功能。例如，通知流水线180可以检查每个传入通知是否符合标准模式或格式，这可以减轻每个通知表面必须执行相同的功能。

图8示出了不同的通知表面230各自如何处理相同的通知232。左边描绘的通知表面230可以接收通知232，解析元素，并且评估哪些元素存在以及它们的属性和内在价值是什么。根据该信息，通知表面的逻辑确定要渲染通知232。在中间描绘的通知表面230类似地接收并且解析相同的通知232。然而，该表面的逻辑确定应当忽略通知。右侧所示的通知表面230确定通知232是可应用的，不是渲染通知232，而是通知表面将通知232转发到例如另一设备(例如，可穿戴设备)的中介或代理。

图9概念性地示出了通知流水线如何使得不同的通知发布者240能够向订户242指定分类通知意图。如背景技术部分所述，很多变量可以影响通知选择。在对应用进行编码和编译时，开发人员不太可能确切地知道应用将在哪种设备上运行、哪些通知表面将可用、或者它们的什么特性(诸如大小和功能)可能是什么。如果使用通用通知模式，如在上面引用的相关专利申请中，则通知发布者240可以定义应当应用通知的绑定。

例如，通知可以被定义为绑定到“中等”大小的通知表面或大于特定大小的通知表面。不同的样式提示或通知内容可能与不同的绑定相关联。换言之，通知发布者不需要指定特定的通知表面，而是指定通知所针对的类型或属性，所有订阅的通知表面都接收通知，并且每个订户242根据与通知的指定相比的其自身的特征来处理通知。在图9中，如果发布者1发布了通知，并且几乎没有任何要求，则每个订户对通知进行操作。如果发布者2发布指定大型通知表面的通知，并且只有订户2和订户3满足要求，则它们显示通知，而其他订户忽略它。如果发布者3向流水线提交包括文本的通知，该文本具有仅将文本渲染为音频的指定，并且如果只有订户4具有这样的能力，则只有订户4将该信息提供给用户；其他订户不采取任何行动。通过相同的逻辑，发布者可以指定如何处理通知的内容或语义的不同部分的意图。

通知流水线还可以帮助避免前向和后向兼容性问题。除此之外，标准格式或模式可以包括“可选的”构造或标记。保证每个表面至少能够识别和解析可选标签。较旧的表面可能会忽略这样的可选通知内容，但较新的表面可能被编程为对可选内容进行操作。随着新的通知表面特征的出现，较新的客户端将能够***它们，而不会影响旧客户端的向后兼容性。例如，如果软件开发人员想要在吐司中支持视频，并且可能图形外壳的第一版本不支持视频吐司但是第二版本支持，如果通知客户端将视频内容放在通知的可选部分中，则可以发送相同的通知有效负载，而不考虑第一版本或第二版本是否将处理它。

在一些情况下，通知表面可能需要知道其计算设备上的哪个应用程序提交了通知。如上所述，通知流水线可以自动标识哪个应用已经提交了通知，并且与通知的广播的发布一起提供该信息。这允许应用特定的接收者将通知的内容定向到适当的子表面或对象。例如，如果使用发布它的应用的身份来发布徽章样式通知，则接收者可以更新对应应用的图标。换言之，通知流水线可以被设计为启用应用和通知的隐式关联。具有多个通知表面的两个不同进程(全部或很多通知表面与特定的相应应用相关联)可以通过一个订阅接收来自相应应用的通知并且将它们引导到适当的应用特定的通知表面。

图10示出了可以在其上实现上述实施例的计算设备120的细节。本文中的技术公开构成了足以用于程序员编写软件和/或配置可重新配置的处理硬件(例如，FPGA)和/或设计专用集成电路(ASIC)等以在一个或多个计算设备120上运行以实现本文中的技术公开中描述的任何特征或实施例的信息。

计算设备120可以具有显示器252、网络接口254、以及存储硬件256和处理硬件258，处理硬件258可以是以下中的任何一个或多个的组合：中央处理单元、图形处理单元、模数转换器、总线芯片、FPGA、ASIC、专用标准产品(ASSP)或复杂可编程逻辑器件(CPLD)等。存储硬件256可以是磁存储器、静态存储器、易失性存储器、非易失性存储器、光或磁可读物质等的任何组合。本文中使用的术语“存储”的含义不是指信号或能量本身，而是指物理装置和物质状态。计算设备250的硬件元件可以以计算领域中充分理解的方式进行协作。另外，输入设备260可以与计算设备250进行集成或通信。计算设备250可以具有任何形状因子，或者可以用在任何类型的包围设备中。计算设备250可以是手持设备的形式，诸如智能手机、平板计算机、游戏设备、服务器、机架安装或背板计算机、片上***等。

可以以被存储在易失性或非易失性计算机或设备可读存储硬件中的信息的形式来实现上面讨论的实施例和特征。这被认为至少包括存储硬件，诸如光存储器(例如，光盘只读存储器(CD-ROM))、磁存储硬件、闪存只读存储器(ROM)等。被存储在存储硬件中的信息可以是机器可执行指令(例如，编译的可执行二进制代码)、源代码、字节代码、或具有可以将信息传送到处理硬件以启用或配置计算设备执行上述各个实施例的物理状态的任何其他物理硬件的形式。这也被认为包括至少易失性存储器(诸如随机访问存储器(RAM))和/或存储信息(诸如在执行实施例的程序的执行期间的中央处理单元(CPU)指令)的虚拟存储器、以及存储允许被加载和被执行的程序或可执行文件的信息的非易失性介质。可以在任何类型的计算设备上执行这些实施例和特征，包括便携式设备、工作站、服务器、移动无线设备，等等。

Claims (10)

1.一种由计算设备执行的方法，所述计算设备包括处理硬件、存储硬件、显示器以及输入设备，所述方法包括：

由所述处理硬件执行操作***，所述操作***管理由所述处理硬件对进程的执行；

执行包括通知流水线的进程，所述通知流水线实现多个功能，所述多个功能至少包括第一功能和第二功能，所述多个功能经由应用编程接口(API)对任意进程可访问；

维持订户标识符集合，所述订户标识符集合分别标识订阅所述通知流水线的订户进程；

由所述通知流水线经由所述API从发布者进程接收由所述发布者进程提供的通知，每个通知包括相应通知内容有效负载，每个通知内容有效负载被构造为符合相同的格式或模式；以及

每次通知由所述通知流水线接收到时，通过所述通知流水线根据所述订户标识符集合向订阅所述通知流水线的任何订户进程传递对应的接收到的所述通知内容有效负载来进行响应，其中每个订户进程接收由所述通知流水线接收到的每个通知内容有效负载。

2.根据权利要求1所述的方法，其中通知内容有效负载包括标识所述通知内容有效负载的属性的元素，并且其中每个订户进程实现相应通知图形用户界面(GUI)，并且其中每个订户进程基于所述通知内容有效负载中的所述元素来确定是否要更新每个订户进程的相应通知GUI。

3.根据权利要求2所述的方法，其中订户进程包括响应于接收到相应通知内容有效负载而显示图形吐司通知的吐司通知应用。

4.根据权利要求1所述的方法，其中所述发布者进程使用所述API来发布所述通知，其中当发布者进程通过对所述API的一次调用提交一个通知时，所述一个通知由所述通知流水线发布给所有订户进程。

5.根据权利要求1所述的方法，其中所述通知流水线读取所有订户标识符，并且根据所有订户标识符建立与相应标识的订户进程的相应事件链接，并且其中当所述流水线进程接收到新的通知时，通过所述流水线进程触发由所述订户进程接收到和处理的进程间事件，相应订户进程都被通知。

6.一种计算设备，包括：

处理硬件、存储硬件、显示器以及输入设备；

所述存储硬件存储操作***，所述操作***被配置为管理由所述处理硬件对进程的执行；

所述存储硬件存储通知流水线，所述通知流水线被配置为由所述处理硬件执行作为由所述操作***管理的进程，所述通知流水线被配置为接收由所述操作***管理的任意其他进程提交的请求，所述请求对应于由所述通知流水线实现的功能，所述功能至少包括发布功能，所述功能经由接口对所述任意进程可访问；

所述存储硬件存储对所述任意进程可访问的多个通知表面，每个通知表面被配置为由所述处理硬件执行以处理和解释符合相同通知格式的通知，每个通知表面被配置为控制图形在相应通知显示区域中的显示；

所述通知流水线还被配置为接收由所述任意进程提交的通知请求，每个通知请求包括被构造为符合所述通知格式的相应通知并且包括被配置为由所述通知表面中的一个或多个通知表面显示的通知信息；以及

所述通知流水线还被配置为基于接收到的所述通知请求来向所述通知表面中的每个通知表面传递每个通知。

7.根据权利要求6所述的计算设备，其中所述通知流水线还被配置为在一个通知表面指示通知已经被解除时自动发信号通知另一通知表面。

8.根据权利要求6所述的计算设备，其中每个通知包括元数据，并且其中第一通知表面和第二通知表面被配置为接收相同的通知，并且基于所述通知中的所述元数据，所述第一通知表面确定要显示所述通知的所述通知信息并且所述第二通知表面确定不显示所述通知的所述通知信息。

9.根据权利要求6所述的计算设备，其中所述存储硬件存储***进程，所述***进程被配置为由所述处理硬件执行并且由所述操作***管理，所述***进程被配置为监听包括经由网络接收到的相应通知的网络通信并且向所述通知流水线传递所述网络通信中的所述通知。

10.一个或多个计算机存储硬件，其存储被配置为使得计算设备能够执行进程的信息，所述进程包括：

执行多个通知表面，每个通知表面包括被指定给所述计算设备的不同上下文的通知显示区域，每个通知表面被配置为接收通知，每个通知符合相同的通知格式并且每个通知包括相应通知内容；

执行通知处理程序时，所述通知处理程序包括软件接口，所述软件接口可用于由在所述计算设备上执行的应用来调用并且可用于由所述通知表面来调用；

由所述通知处理程序接收符合所述通知格式的通知，并且针对接收到的每个通知，基于每个通知向所述通知表面发送所述通知，使得每个通知表面接收所述通知的副本；以及

由所述通知表面接收由所述通知处理程序发送的所述通知，并且针对所述通知中的至少一些通知，所述通知表面中的每个通知表面显示所述相应通知内容。