AppleDOC--ANCS

这是一个对于Apple开发者文档的翻译,基于自己的知识经验和有道词典,希望能为需要的同仁提供一些帮助。水平有限,不足之处还望指出,好做更正,避免误导他人。

先贴上原文链接](https://developer.apple.com/library/ios/documentation/CoreBluetooth/Reference/AppleNotificationCenterServiceSpecification/Introduction/Introduction.html#//apple_ref/doc/uid/TP40013460)


介绍

ANCS的目的是给蓝牙外设(指通过BLE与iOS设备建立连接的设备)一种简单方便的方式去接收各种各样的产生于iOS设备上的通知。

ANCS的设计遵循三个原则:简单的,高效的,可扩展的。基于此,不管是简单的led设备,还是大型的能源设备都能在一定范围内有效发现这个服务。

依赖

除了遵循标注GATT的子程序,ANCS没有什么依赖。一个作为GATT客户端的设备在使用ANCS的同时可以使用其他的服务与iOS设备通信。这里说明蓝牙设备在与iOS设备透过其它服务通信的同时可以使用ANCS服务。

字节与编码

除非特别说明,所有ANCS通道数值采用小端字节序

除非特别说明,所有ANCS通道的字符串才有UTF-8编码

术语

苹果通知中心服务被简称为ANCS

ANCS服务发行端(iOS设备)被称为通知提供者(NP)

ANCS服务客户端(外围设备)被称为通知消费者(NC)

出现在iOS设备的通知中心的通知称为iOS通知

通过GATT特征作为异步信息发送的通知称为GATT通知

苹果通知中心服务

苹果通知中心服务是一项基础服务,服务UUID是7905F431-B5CE-4E99-A40F-4B1E122D00D0.

在一个NP上同时只允许一个ANCS实例存在。由于iOS的特性,ANCS实例并不总是存在,基于这个结果,为了能够监听到ANCS随时不定发送的通知,NC随时需要寻找并订阅ANCS服务改变的GATT特征。

服务特征

从基本要素上看,ANCS暴露了3个特征

通知源 :UUID 9FBF120D-6301-42D9-8C58-25E699A21DBD (notifiable)

控制点:UUID 69D1D8F3-45E1-49A8-9821-9BBDFDAAD9D9 (writeable with response)

数据源: UUID 22EAC6E9-24D6-4BB5-BE44-B36ACE7C7BFB (notifiable)

所有这些特征都需要授权使用。

通知源特征的支持是强制的,然而控制点和数据源的特征支持是可选的。

Note:ANCS拥有除了上面说的三种之外的特征,也就是说,一个NC可以忽略任何他不能识别的特征。

通知源

通知源特征是基于NC接收到下述消息之上的特征:

NP上新的iOS通知的到达

NP上iOS通知的修正

NP上iOS通知的移除

GATT通知在NC订阅通知源特征的时候就送达了。因此,NC在订阅通知源特征之前需要保持一个可以正确接受并使用这些消息的状态。

一段通过通知源特证送达的GATT通知的格式如图2-1所示。

(图省略了,用[]来表示了)

[EventID 1Byte][EventFlags 1Byte][CategoryID 1Byte][CategoryCount 1Byte][NotificationUID 4Bytes]

一段通过通知源特征送达的GATT通知包含了以下信息:

EventID:这个字段告诉配件发过来的iOS通知是添加、修改还是删除,EventID values这个枚举值帮助定义这个字段 EventIDNotificationAdded = 0,

EventIDNotificationModified = 1,

EventIDNotificationRemoved = 2,

Reserved EventID values = 3–255

EventFlags:一个用来告知NC这条iOS通知的特殊性.举个例子,如果一个iOS通知被认为是“重要的”,NC可能需要在供给用户接口(在UI上展示)来确保这条消息提醒到了用户.EventFlags这个枚举帮助定义这个字段

EventFlagSilent = (1 << 0),

EventFlagImportant = (1 << 1),

EventFlagPreExisting = (1 << 2),

EventFlagPositiveAction = (1 << 3),

EventFlagNegativeAction = (1 << 4),

Reserved EventFlags = (1 << 5)–(1 << 7)

CategoryID:一个数值编成的类别用于对iOS通知分类,NP尽可能对每一条iOS通知进行精确的分类。CategoryID Values这个枚举帮助定义这个字段

CategoryIDOther = 0,

CategoryIDIncomingCall = 1,

CategoryIDMissedCall = 2,

CategoryIDVoicemail = 3,

CategoryIDSocial = 4,

CategoryIDSchedule = 5,

CategoryIDEmail = 6,

CategoryIDNews = 7,

CategoryIDHealthAndFitness = 8,

CategoryIDBusinessAndFinance = 9,

CategoryIDLocation = 10,

CategoryIDEntertainment = 11,

Reserved CategoryID values = 12–255

CategoryCount:这个分类当前活跃的iOS通知的个数。举个例子,如果现在用户的邮箱里有两条未读邮件,这个时候一条新的邮件推送过来了,那么这个CategoryCount的值将是3。

NotificationUID:一个作为iOS通知的唯一识别符的32位(32-bit)数。这个数可以被用作一个发送给控制点特征(Control Point characteristic)的命令句柄与iOS通知交互。

一个iOS通知的生命周期隐约可以通过NP生成的通知源GATT通知的序列推理出来,如下图

AppleDOC--ANCS_第1张图片

控制点和数据源

一个NC可能需要和iOS通知相互作用,它可能想要获取更多关于iOS通知的信息,包括它的内容,或者是想要在通知上执行些什么。这些属性检索的执行贯穿整个控制点和数据源特征。

NC可以通过发送特定命令给控制点特征用于接受更多关于iOS通知的信息。如果写成功了,NP会立即作出反应,通过数据源特征返回一条GATT通知的数据流。

通过写命令到控制点特征上NC可以在iOS通知上执行预设动作,更多关于行为和iOS通知的信息在 Perform Notification Action(执行通知行为).

获取通知属性

获取通知属性命令允许NC获得特定iOS通知的属性。获取通知属性的命令格式如下:

[CommandID 1byte][NotificationUID 4bytes][AttributeID1 1byte][AttributeID2 1byte][Attribute2 max length 2bytes][…]

一条取通知属性命令包含如下信息:

∙ CommandID :应该写0(CommandIDGetNotificationAttributes)

∙ NotificationUID :32位的数值表示客户端想要信息的iOS通知的唯一ID(UID)

∙ AttributeIDs:NC想要获取的属性列表.一些属性会跟一个16位(2bytes)的参数指定该属性的最大字节数。

获取通知属性命令的返回值(Response)的格式如下:

[CommandID 1byte][NotificationUID 4bytes][AttributeID1 1byte][AttributeID1 length 2bytes][…Attribute1…][AttributeID2 1byte][Attribute2 length 2bytes][…Attribute2…][…]

一条取通知属性命令的返回值包含如下信息:

∙ CommandID :应该写0(CommandIDGetNotificationAttributes)

∙ NotificationUID :32位的数值表示这些属性对应的iOS通知的唯一ID(UID)

∙ AttributeList:一个(属性ID/16位长度说明/属性元组)列表.属性是一条长度被元组提供的字符串,但是不以NULL结尾.如果一条被请求的iOS通知属性是空的或者丢失了,它的长度将被置为0.

如果一条返回值长度超过了GATT的长度上限,它将被NP分包处理.NC则必须要重新组包.每条请求的返回值消息完成时都会有完成元组被接收到.

获取应用属性(Get App Attributes)

获取应用属性的命令允许NC获取NP上已安装的制定App的的属性。命令格式标准如下:

[CommandID 1byte][…App Identifier…][AttributeID1][AttributeID2][…]

获取应用属性的命令包含以下信息:

∙ CommandID :应该写1(CommandIDGetAppAttributes)

∙ AppIdentifier :NC想要获取信息的对象App的字符串标示.这个字符串必须是Null结尾.

∙ AttributeIDs:NC想要获取的属性列表

获取应用属性命令的返回值的格式如下

[CommandID 1byte][…App Identifier…][AttributeID1 1byte][AttributeID1 length 2bytes][…Attribute1…][AttributeID2 1byte][Attribute2 length 2bytes][…Attribute2…][…]

获取应用属性命令的返回值包含以下信息:

∙ CommandID :应该写1(CommandIDGetAppAttributes)

∙ NotificationUID :跟随的属性对应的App的字符串标示.这个字符串必须是Null结尾.

∙ AttributeList:一个(属性ID/16位长度说明/属性元组)列表.属性是一条长度被元组提供的字符串,但是不以NULL结尾.如果一条被请求的iOS通知属性是空的或者丢失了,它的长度将被置为0.

和获取通知属性的返回值一样,如果一条获取应用通知的返回值长度超过了GATT的长度上限,它将被NP分包处理.NC则必须要重新组包.每条请求的返回值消息完成时都会有完成元组被接收到.

执行通知行为

这个命令允许客户端真对特定iOS通知执行一条预设任务.一条执行通知行为的命令包含以下几个部分:

Bytes    Name  Description

1   CommandID 设为2 (CommandIDPerformNotificationAction).

2-5   NotificationUID 客户端想执行行为的对应iOS通知的32位(4bytes)唯一ID;

6   ActionId NC想在这条iOS通知上执行的行为

当这条命令错误是数据源特征上不会有数据产生,不管命令发送成功或者失败。

通知行为

从iOS8.0开始,NP可以通知NC和iOS通知关联的潜在行为.出于用户考虑,NC可以请求NP完成一个特定iOS通知关联的行为.

NC被通知源特特征通过检索事件标记位的存在来验证iOS通知上可执行行为的需要而生成的GATT通知通知.(The NC is informed of the existence of performable actions on an iOS notification by detecting the presence of set flags in the EventFlags field of the GATT notifications generated by the Notification Source characteristic:

通知源特征        生成的GATT通知    坚定事件标记位的存在    iOS通知上的可执行行为的存在  通知 NC)

∙ EventFlagPositiveAction: 与iOS通知关联的一个正向行为的存在

∙ EventFlagNegativeAction: 与iOS通知关联的一个负向行为的存在

实际上NP代表NC执行的行为的不同取决于它依靠的iOS通知类型。举个例子,在来电通知里执行一条正向行为代表接听,执行反响行为代表挂断。

NC不能假设或预判在iOS通知上行为的准确执行,因为这些行为建立在不能被他利用的信息之上,如同NP实现的ANCS版本的其他影响因素一样。NP保证这些正向或者负向的行为导致的结果不会吓到用户。

如果被一条iOS通知提出,正向或负向的行为必须要展示给用户,通过核实标记(check marks)、X marks、感谢和免责的通用颜色(就像绿色和红色).

在iOS8.0,NC可以检索标签来简洁描述介绍在收到新的iOS通知属性后的实际行为

∙NotificationAttributeIDPositiveActionLabel: 这个标签用于描述正向的行为

∙NotificationAttributeIDNegativeActionLabel: 这个标签用于描述负向的行为

会话(Sessions)

一个ANCS会话开始于NC通过通知源特征向NP订阅,结束于NC在同一特征上取消订阅或者NC与NP断开连接。因为ANCS没有被设计成完整的同时性服务,所以它不保存整个会话的状态轨迹.基于此,NP和NC之间交换的所有标示(例如通知唯一表示和应用标示字符串)和数据都只在特定会话内有效。

当一个会话结束时,NC应该清理掉在这个会话里接受到和保存的所有标示和数据.当一个新的session开始时,NP尽可能通知NC所有存在与系统的iOS通知.NC可以用这些信息建模以便在接下来的会话中使用.

属性抓取和缓存(Attribute Fetching and Caching)

强烈建议NC只在需要和可能的用户行为的返回值时才抓取属性.举个例子,NC选择显示iOS通知在一个简单列表里,并且在用户选择时展示特定iOS通知的详情,那么检索这些通知属性的行为就可以被懒加载.

在一个会话里,强烈建议NC为它遇到的每一个App属性的每一个标示建立缓存.这些缓存可以帮助NC过滤相同App属性的多次接受—-省时省电.

错误码

在写控制点特征命令时,NC可能会收到以下特定错误码:

∙Unknown command (0xA0): NP 不承认这个命令

∙Invalid command (0xA1): 命令格式不正确

∙Invalid parameter (0xA2): 参数中(eg:the NotificationUID)没有关系到NP上已存在对象.

∙Action failed (0xA3): 这个行为不被允许.

如果NP的回复包含了error,它就不会在数据源特征上生成一条相关命令的GATT通知。

示例图表

图表在原文最后,用两个例子描述下NP与NC的工作流程。这里就不贴了

你可能感兴趣的:(AppleDOC--ANCS)