Sony Control API
Control API是Smart Extension APIs中的一部分。前面一篇讲到了Sony Extension API。Sony某些智能配件支持Control API。Control API让Extension可以完全控制配件,包括控制屏幕、LED、振动、输入。正是由于是完全控制设备,所以同一时刻只能有一个Extension运行。
Control API包括以下内容:
Control Extension可以使用配件之前,需要使用注册API中的Content Provider插入一条记录到Extension表中(原文:it must use the registration API content provider to insert a record in the extension table)。此外还应在注册表中添加信息。每个可与Extension交互的主应用(Host Application)均应完成上述过程。
为了知道有哪些主应用可用以及主应用支持哪些功能,Extension需要使用Capability API
Extension成功注册后即可与主应用通信。再次强调,由于Extension是完全控制配件,所以同一时刻只有一个Extension运行
Extension并不能任意执行,它应先确认没有其他Extension在运行,这种情况下当前Extension才能使用CONTROL START REQUEST_ INTENT来请求运行自己。 当主应用准备好将控制权交给 Extension后它将发出一个CONTROL START INTENT响应。见下图
当Extension请求控制配件时,主应用可以接受请求并交出控制权;或者由于某些情况,拒绝该请求并发出一个CONTROL ERROR INTENT响应。主应用可以发出的错误码请参考EXTRA ERROR CODE
当Extension在配件上可见主应用时将发出CONTROL RESUME INTENT。可以认为这里Extension控制一切了,而主应用不过是在配件和Extension之间传递信息。
当一个高优先级的Extension临时需要运行时或者主应用负责管理屏幕状态而屏幕 关闭时,也可以暂停Extension。这种情况下主应用给Extension发送CONTROL PAUSE INTENT。也就是,当前Extension已关闭或者其他Extension开始控制配件,所以当前Extension再也不能更新屏幕了。当Extension强行更新屏幕时,主应用会忽略这些违反规定的调用。
当Extension处于暂停状态时,它不能控制屏幕/LED/振动器/按键事件。一个例子是通话Extension,它具有高优先级。比如,当某个Extension正在运行,这时用户接到一个电话。我们希望能够暂停正在运行的Extension,让通话Extension在屏幕上显示来电号码。当通话结束后,结束通话Extension并重新运行原来的Extension,原来的Extension会接收到CONTROL RESUME INTENT。
主应用发出CONTROL RESUME INTENT后,原来的Extension将重新控制一切了。
用户退出Extension时主应用会发送一个CONTROL PAUSE INTENT和一个CONTROL STOP INTENT。这时主应用重新获得控制权。
当正在运行的Extension想结束自己,比如通话Extension,可以向主应用发送CONTROL STOP REQUEST_ INTENT。主应用将停止它并发送一个CONTROL STOP INTENT。如果这个Extension还未停止,主应用发送CONTROL STOP INTENT之前将先发送CONTROL PAUSE INTENT。相应地,其他被暂停的Extension将重新运行。
实现了Control API的Extension可以控制配件的屏幕状态。使用CONTROL SET SCREEN STATE INTENT控制屏幕。
无论在手机端还是配件端,编程时应注意尽可能消耗更少的电量,这点非常重要。配件的电池比手机小得多,所以使用各种功能时应小心。尽可能让主应用控制屏幕状态。这样的话,你就不心担心配件上的电量消耗问题。仅需将屏幕状态设置为"自动"即可。
其实缺省情况下,Extension启动时屏幕状态会被设置为"自动”,所以主应用会控制屏幕开/关/暗等行为。如果Extension想要控制屏幕状态,它必须明确进行修改。
Extension停止时,主应用会自动接管屏幕控制。
注意:当处理"自动"状态时,屏幕关时Extension将收到一个CONTROL PAUSE INTENT;屏幕开时会收到一个CONTROL RESUME INTENT。
某些配件可能支持这样一种模式:信息可以展示给用户但同时保持电量消耗最少。
这种活动节能模式仅能以黑白色显示内容。支持该模式的配件通过SUPPORTS LOW POWER MODE来标识将启动活动节能模式。如果Extension想使用这种模式,它必须在注册到主应用时将LOW POWER_ SUPPORT设置为TRUE。
如果Extension和配件都支持活动节能模式,屏幕关时将激活这一模式。即,如果屏幕状态是SCREEN STATE AUTO,配件将判断何时进入活动节能模式。如果屏幕状态是SCREEN STATE ON或SCREEN STATE DIM,Extension可以通过设置屏幕状态为SCREEN STATE OFF来激活活动节能模式。无论是Extension还是配件激活活动节能模式, Extension都会收到一个CONTROL ACTIVE POWER SAVE MODE STATUS CHANGED _INTENT。另外,在活动节能模式下,Extension仍然可以使用正常显式模块下的方法来更新屏幕。
如果屏幕状态是SCREEN STATE AUTO,并且是由配件主动进入活动节能模式,配件也可以决定什么时候退出这种模式。注意,活动节能模式中Extension不会收到来自配件的任何输入事件,因为这将导致退出活动节能模式。如果是由Extension主动进入活动节能模式,则仍然需要Extension决定什么时候退出该模式,退出时需要设置屏幕状态为SCREEN STATE ON。如果Extension想在屏幕处于活动节能模式时仍然收到输入事件,则只能由它自己主动进入该模式(而不是由配件主动进入)。当屏幕退出活动节能模式时,Extension都会收到CONTROL ACTIVE POWER SAVE MODE STATUS CHANGED _INTENT,并且Extension应用更新屏幕内容。
配件上可能有一个或多个LED,可用于提醒用户有新的事件发生。Extension可以通过注册API和Capability API来获取配件上LED相关的信息。
如果配件上有LED,则Extension可以使用Control API来控制LED。使用CONTROL LED INTENT进行控制。 注意主应用可能在任何时候控制LED以提示用户。而Extension不知道这种情况,如果这时它尝试控制LED,则主应用会忽略它的请求。
配件上可能有振动器。使用注册API和Capability API来检查是有振动器。如果有,则可以使用CONTROL VIBRATE INTENT
配件上可能有若干物理键。当按下物理键时Extension会接收到CONTROL KEY EVENT_ INTENT表示的按键事件。
该Intent包含几个参数,比如事件的时间戳,事件类型(按下,松开还是重复),以及按键代码。每个按键有唯一的按键代码。
某些配件具有触屏。Extension通过注册API和Capability API获取相关信息。当用户触摸配件屏幕时Extension将收到CONTROL TOUCH EVENT_ INTENT
如果CONTROL DISPLAY DATA_ INTENT用于发送图片,那么触摸事件则有带有屏幕坐标信息的CONTROL TOUCH EVENT_ INTENT发送。如果有滑动手势,则会向Extension发送CONTROL SWIPE EVENT_ INTENT
如果CONTROL PROCESS LAYOUT_ INTENT用于发送布局,则布局中的某些View将处理触摸事件。触摸事件会被android:clickable设置为true的View处理。对于这些View,Extension会收到CONTROL OBJECT CLICK EVENT INTENT。而ListView将触摸事件处理为CONTROL LIST ITEM CLICK INTENT。未被布局中View处理的触摸事件和滑动事件会发送给Extension自己来处理。
Extension不仅控制配件本身,还能控制屏幕上显示什么内容。用户可见的内容来自于Extension。基本上Extension是发送图片以显示在配件的屏幕上。为获取支持的屏幕大小和颜色深度,Extension需要使用注册API和Capability API。Extension通过发送CONTROL DISPLAY DATA_ INTENT更新屏幕内容。
Extension可以发送图片的原始数据或仅仅发送URI。注意,我们是使用蓝牙来传输数据所以无法达到较高的帧率。屏幕刷新率请见注册API和Capability API。
Control API v2版本开始可以发送布局而不仅仅是图片了。由EXTRA DATA XML_ LAYOUT来指定布局(仅支持标准Android布局中的某些)。使用CONTROL PROCESS LAYOUT_ INTENT发送布局。而布局中View的内容则使用CONTROL SEND IMAGE_ INTENT和CONTROL SEND TEXT_ INTENT来更新。使用布局时,点击事件由CONTROL OBJECT CLICK EVENT INTENT发送。
布局中可以包含列表。列表由CONTROL LIST COUNT_ INTENT初始化。这个Intent可以在EXTRA LIST CONTENT中包含列表数据。如果没有提供EXTRA LIST CONTENT,则主应用会要求必要时使用CONTROL LIST REQUEST ITEM INTENT来逐一请求列表项数据。Extension可以在任意时候发送一个CONTROL LIST COUNT_ INTENT来更新列表内容,如需要添加新的列表项或者已存在的列表项需要刷新。
ListView和其子元素必须占满屏幕的整个宽度。而列表项的高度小于或等于ListView的高度。
有些列表可以支持用户发起的更新。当用户发起更新时,会向Extension发送一个[CONTROL LIST REFRESH REQUEST INTENT][CONTROL_LIST_REFRESH_REQUEST_INTENT]。Extension需要检查数据源(比如向服务器拉数据)并更新列表内容。如果列表项数目发生变化,则会发送一个新的CONTROL LIST COUNT_ INTENT。如果只是内容发生变化,则会发送几个CONTROL LIST ITEM_ INTENT。
与List非常类似。
Control包含两个内部接口,分别是
1.Control.Intents
Intents sent between Control Extensions and Accessory Host Applications.
2.Control.KeyCodes
Interface used to define constants for keycodes (??? 不明白,为什么这个也要重新定义)