移动微件

用手机看条目

出自 MBA智库百科(https://wiki.mbalib.com/)

移动微件(Mobile Widget)

目录

什么是移动微件

  移动微件是在移动互联网领域对微件技术的提升和应用,同时受到运营商、终端厂商、平台厂商和应用软件提供商、内容提供商的重视,是因为它可以满足产业链上不同角色的需要。从运营商角度看,移动微件可以作为业务运营的一种良好方式;从终端厂商角度看,移动微件可以用于增加其终端的可定制性;从平台厂商角度看,移动微件可以作为其控制终端桌面,从而实现控制用户的一种方式;从应用软件提供商来看,移动微件易于开发、易于部署的特性使其成为应用开发的较好平台;从内容提供商角度看,移动微件是开展内容服务的较好通道。

移动微件的实现方案[1]

  虽然移动微件的实现方案很多,但是从标准化的角度来说,真正具有标准化前景的方案有四种:W3C方案、OMTP BONDI方案、诺基亚的WRT方案、中国移动的JIL Widget方案。

  自2006年起,W3C开始制定Widget草案,目前由Web Applications( WebApps)Working Group负责。

  图1是一个典型的Widget架构(源于W3C),最下一层称为主机运行时环境,通常是一个软件引擎,或提供功能的网页浏览器。大部分的环境主机运行时,通常会支持HTTP、IRls、Unicode、HTTP.以及ECMAScript/JavaScript、CSS、DOM,其中还包括为了展现多媒体资源需要的支撑技术。

  各规范的内容大致如下:

  (1)《Widgets l.0: Requirements》:针对打包、配置文件、程序语言接口、用户体验、安全与数字签名等内容提出Widget总体需求。

  (2)《Widgets l.0: Packaging and Configuration》:涉及到资源文件的文件类型、内容、路径,打包方式,描述文件元数据等;规定Widget需用ZIP算法打包,并使用wgt作为文件扩展名;配置文件需用统一的文件名:config.xml,放在Widget包的根目录下;并进一步规范了配置文件所应使用的源数据及其语义:Widget, name, description, author, license, icon,content, feature, param, preference。

  (3)《Widgets l.0: Digital Signatures》:数字签名用于验证Widget包的完整性,需使用signaturel.xml作为文件名,放在Widget包根目录下;并同时规范用户代理对签名文件的处理流程。

  (4)《Widgets l.0: APls and Events》:定义Widqet对象提供给应用程序(如jacascript脚本)调用的接口,具体包括一个Widget接口,其中包含如下属性:viewMode, locale, identifier, authorName,authorEmail, authorHref, name, description,version,width,height,preferences。如下方法:onmodechange, hasFeature, openURL,getAttention, showNotification。

  (5)《Widgets l.0.: Access Requests Policy》:定义默认情况下的安全策略、安全声明格式以及对安全事件的处理流程。目前尚无实质内容。

  (6)《Widgets l.0: Updates》:定义了Widget更新需使用统一命名的update.xml文件名,并规范了此文件中需使用的元数据和更新处理流程。

  (7)《Widgets 1.O:URI Scheme》:规范化Widget内部所使用的URI的语法和模式,目前尚无实质内容。

  2009年7月3日,W3C DAP工作组(Device APlsand Policy Working Group)成立。DAP制定终端侧API,通过这些API,互联网应用和微件(Widget)能与终端提供的服务交互,如日程、地址本、摄像头等。同时,该工作组还研究制定安全框架,该框架管理对API的安全访问/调用。

  应该说,由于W3C在互联网领域以及Web标准制定上的权威性,W3C的标准是最具有指导价值的。但是,由于W3C标准需要广泛征求各方建议,充分吸纳各种输入文稿,所以其制定速度较慢。因为草案较多,制定的内容也比较全面,因此至今仍未发布关于Widget标准的正式国际规范。

  此外,对运营商采用Widget开展业务来说,由于W3C并未规定相关的平台侧技术要求,可能会造成具体运营时的困难。在具体的API定义上,W3C也处于起步阶段,这是影响Widget可移植性的主要因素,如果W3C标准要进入实际运营环节,还有很多工作要做。

  OMTP是由国外8家具影响力的移动运营商组成的联盟,致力于移动应用的编程接口的标准化工作,针对Widget成立了BONDI项目,包含如下两项规范:

  (1)《BONDI: Interfaces》:移动设备底层能力调用接口的标准化

  (2)《BONDI: Architecture_Security》:移动设备底层能力调用的安全架构。

  OMTP将来打算将BONDI项目形成的规范推向W3CWidget,已于2008年8月与W3C签订了备忘录。因此可以认为OMTP BONDI与W3C Widget是相互兼容的。

  BONDI由几个相关的规范组成。

  API规范——一组生成HTML页的BONDI APls的语法和语义定义。

  安全策略规范——安全策略的一个互操作的×ML描述,定义访问一个特定Web应用和Widget所需的BONDI APls。

  开源的参考实现(Rl) -有关接口和安全规范应该实现的一个实际的、具体例子, Rl SDK包含API文档和代码

  BONDI工作组要确定的规范必须提交W3C和OpenAjax联盟审阅和修订。

  OMTP BONDI已经正式提交给W3C作为Widget API的输入文稿,这表示BONDI和W3C的工作会逐步走向统一。

  虽然BONDI的参与者众多,但是其产品化推进一直没有得到太多的重视,导致其接口定义虽然完整,但是真正实现BONDI的厂家较少,不利于其推广应用。

  诺基亚于2007年8月24日发布了在S60平台上的Widget引擎并且宣布在其未来所有发布的S60手机都将支持自己的Widget产品。Widget的运行基于Web Run-time(以下简称WRT)。WRT是S60 SDK 3rd EditionFeature Pack 2中新增加的浏览器组件。它是一个Web应用开发环境。

  Nokia Widget的使用方式与S60本地应用一样。作为Widget的运行平台,WRT设计目标之一就是使Widget与S60平台进行无缝集成,给用户一致的使用体验。例如,每个Widget都可以在应用程序菜单中显示图标;可被设置为待机状态下的快捷键和左右软键;能出现在活动应用列表中;具有与现有的S60应用一样的管理方式,如安装、卸载等等。由于功能简单,WRT占用资源较其他Widget引擎要小。同时,由于WRT是基于S60浏览器环境构建,技术相对较成熟,对资源的利用效率也较高。

  从标准的角度来说,诺基亚提供了以下输入文稿到W3C,作为W3C DAP组的起草文件:Nokia´s calendarAPI, Nokia´s camera API, Nokia´s contacts API,Nokia´s messaging API, Nokia´s System Info API,Nokia´s DeviceException Interface。

  整体上说,OMTP和Nokia都是W3C成员.OMTP正在将其BONDI规范,Nokia也正在将其JavaScript API规范提交W3C供讨论。

  BAE是中国移动主导的,面向移动互联网的、开放的、跨终端操作系统平台应用运行环境。它基于开放的浏览器技术,为移动互联网应用提供了跨平台的运行环境,为开发者提供基于标准Web技术开发移动互联网应用的基础,降低了手机终端应用和业务的开发和部署难度;为终端用户在手机终端上提供移动互联网全新体验。目前,BAE支持JIL Widget格式(中国移动沃达丰软银Verizon共同定义、遵循的Widget标准),同时兼容部分互联网上流行的Widget,如Apple Dashboard Widget等。

  JIL Widget的特点是提供一套可产品化的参考实现。同时,JIL Widget项目也在与移动软件开发商、设备制造商的战略合作,推动丰富的产品开发工作。更进一步,JIL Widget也会提供相应兼容性测试工具。另一方面,JIL Widget标准化的工作重点是推动个人及第三方的Widget开发工作,构建一个开放的、全球化的开发者社区。JIL Widget希望通过以上这种方式来建设一个较为完整的、能够商业化运营的移动Widget产业环境

  从技术层面上来讲,JIL和BONDI的API定义各有特色,但是JIL更加重视产业化推进,配套开发工具和开发包等比较完备。

  JIL Widget的主要特点是运营商主导,推进迅速,但是其并没有纳入W3C规范,即没有正式向W3C输入文稿,在具体的API定义方面也与W3C的路线有冲突,该方案能否在全球范围内取得成功,还需要时间的检验。

移动微件业务发展策略[2]

  从移动微件业务本身来说,支持何种形式的应用都有可行性,但是技术毕竟有其局限性,除去标准化的因素,结合运营商自身的需求,找准移动微件最适用的业务形式,是移动微件业务成功的关键因素之一。这里重点考虑两方面的问题:一是移动微件从技术角度来说适用的应用形式;二是移动微件如何与其它业务相结合。

  从技术角度来说,移动微件对复杂逻辑的处理能力有限,因此难以用来开发较为复杂的本地应用,如大型游戏等,至少在现阶段仍是如此。从微件简单易移植的特性来说,更加适合信息类的应用,以及对现有应用进行UI优化或者集成的方面,除简单的天气预报、新闻类业务外,可以重点考虑话费查询、影音播放等逻辑较为简单的业务,以及开展广告等后向收费型的推送业务。从移动微件与其它业务的关系来说,移动微件可以成为其它业务的良好承载形式,如将运营商常见的手机音乐、手机电视、手机邮箱等业务用移动微件的形式来提供,即可提高应用的可移植性,加快部署速度,也可以有更优化的UI和更灵活的界面布局控制。从部署策略来说,移动微件常与应用商厦相结合,可以成为应用的一种形式。但是,移动微件在访问控制上有更高的要求,特别是终端本地能力访问控制上,比常见的应用有更好的控制力,因此移动微件也有自己的控制平台,除通过移动微件引擎进行控制外,部分功能还需要与平台联系来确定应用的访问权限。从发展的趋势来说,移动微件的策略应该是与本地应用相混合,从形式上不再让用户区分是微件应用还是本地应用,也就是类似Palm在发展WebOS时的技术途径,但是应用之间应该有相互调用的机制,以保证业务的一体化。

参考文献

  1. 廖军.《移动微件技术及标准进展》.技术趋势[J].2014年1月5日
  2. 廖军.《移动微件业务发展现状及策略》[M].移动通信.2010(07)
本条目对我有帮助0
MBA智库APP

扫一扫,下载MBA智库APP

分享到:
  如果您认为本条目还有待完善,需要补充新内容或修改错误内容,请编辑条目投诉举报

本条目由以下用户参与贡献

Tracy,苏青荇.

评论(共0条)

提示:评论内容为网友针对条目"移动微件"展开的讨论,与本站观点立场无关。

发表评论请文明上网,理性发言并遵守有关规定。

打开APP

以上内容根据网友推荐自动排序生成

闽公网安备 35020302032707号