AllJoyn Control Panel服务框架1.0最佳实践

AllJoyn Control Panel Service Framework 1.0 Best Practices

1 AllJoyn Control Panel服务框架
1.1 目的
1.2 范围
1.3 参考文献
1.4 缩写词和术语

2 最佳实践
2.1 控制器
2.1.1 显示多重 Control Panel
2.1.2 响应Control Panel的变化
2.1.3 异常处理
2.2 受控者
2.2.1 受控者Control Panel命名规范
2.2.2 Control Panel结构和布局
2.2.3 受控者的本地化处理


1 AllJoyn Control Panel服务框架
AllJoyn Control Panel服务框架使 一个设备应用程序宣布一个虚拟Control Panel和另一个领近设备应用程序发现和显示 Control Panel 相互作用。
这个服务框架适用于一对一交互在一个设备(受控者)和控制应用程序(控制器)之间。

受控者应用程序可以使用服务定义一组展示控制的“部件”,包括这些部件每个控件的使用和在显示控制器上如何布局的说明。
一个控制器应用程序可以使用服务发现附近的受控者,获得他们的 Control Panel,使用提供的适配器层在特定于目标平台创建控制UI元素。

1.1 目的
本文档提供了执行AllJoyn Control Panel服务框架的最佳实践。

1.2 范围
本文是为想充分利用本服务提供的功能的原始设备制造商和开发者们而写。

1.3 参考文献
以下参考文档基于AllSeen联盟网页Docs/Downloads章节：
■ AllJoyn框架辅导
■ AllJoyn精简客服端入门指导

文档支持 Control Panel服务框架上市的平台比如Android，Linux，Thin Client等。
■ AllJoyn Control Panel服务框架1.0入门指南
■ AllJoyn Control Panel服务框架1.0入使用指南

1.4 缩写词和术语
术语                  定义
----------------------------------------------
AllJoyn Service        实现使用提供特殊功能的
frameworks            AllJoyn框架的全貌集合。
                      这些构建模块被设备和应用
                      构建相互结合在一起。
-----------------------------------------------
Adapter                Control Panel服务框架层翻译接收
                      到的UI元素到Android的UI元素
-----------------------------------------------
AllJoyn device        支持AllJoyn框架，能连接到
                      私人网络的设备
-----------------------------------------------
Control panel          允许用户与设备交互的部件集合。
                      一个Control Panel被受控者定义和发布，
                      被控制器发现和显示。一个设备
                      能有多个，能被定义在预语言基础上。
-----------------------------------------------
Controllable device    一个代表（代理）受控者的客服端。
-----------------------------------------------
Controllee            一个AllJoyn应用程序，发布
                      Control Panel接口，所以其他AllJoyn
                      设备可以控制它。
-----------------------------------------------
Controller            一个AllJoyn应用程序控制另一个
                      发布Control Panel接口的AllJoyn设备
-----------------------------------------------
Widget                一个UI元素在Control Panel代表一个接口。
                      它生动地表现一个用户执行功能或使用内容。
-----------------------------------------------

2 最佳实践
本章节描述基于此服务框架功能的处理情景。

2.1 控制器
2.1.1 显示多重 Control Panel
有时， 一个受控者可能有复合 Control Panel。一些例子如下：
■ 一些 Control Panel可能为整体设备的不同“单位”；
■ 用户的每天 Control Panel和技术员或修复个人的单独的 Control Panel。
因此,控制器应用程序应该提供用户选择的选项
不仅可以与附近的受控者交互,也 Control Panel上他们想要与特定的受控者。

2.1.2 反应 Control Panel的变化
受控者提供的 Control Panel可能根据用户交互,设备状态,和其他因素改变。
控制器有一个注册在 Control Panel的适当的监听器是很重要的,
这样它将被告知这些变化并相应更新 Control Panel的用户界面。

2.1.3 异常处理
当发生错误,控制器试图从受控者恢复部件,适配器将抛出一个异常,
这样应用程序可以处理错误并决定如何向用户显示错误。
这些抛出的错误是有原因的,在不同的状态,他们不应该被忽略。

2.2 受控端
2.2.1 受控端Control Panel命名规范
当设计受控端发布的Control Panel时,必须遵循一定的命名约定为单位的名称和各个部件的名称。
此外,每个Control Panel的单元和小部件名称必须是唯一的。
单位名称和部件名称使用AllJoyn BusObject路径的一部分, Control Panel服务框架会利用。
命名约定如下:
■只包含ASCII字符”[A-Z][a-z][0-9]_”
■不能空字符串

2.2.2 Control Panel结构和布局
重要的是要记住,受控者发布的Control Panel经常在一个移动设备的有限屏幕大小和可用屏幕空间上显示。
因此,Control Panel服务框架的容器部件应使用有效地组织和安排其他小部件的Control Panel。

2.2.3 受控者的本地化处理
开发人员创建一个受控者应用程序不应该依赖或计划有控制器应用程序执行本地化(翻译或口译等)的内容。
例如,如果一个受控者提供语言支持英文和西班牙的Control Panel,
然后字符串包含在不同的部件必须有正确的和完整的language-appropriate字符串可用以便控制器应用程序可以简单地显示小部件。
一个方法,比如有一个受控者小部件定义包含一个数字或代码,然后用来查找或控制器转换为一个特定于语言的字符串是不可接受的。