一种微件更新的方法及客户端、 服务器及系统 【技术领域】
本发明涉及互联网技术领域, 具体涉及一种微件 (Widget) 更新的方法、 客户端、 服务器及系统。背景技术
Widget, 也称为微技, 是一种基于互联网 (Web) 的小应用, 通常实现某个特定的功 能。Widget 可以看作是运行于浏览器界面之外的定制 Web 页面, 基于 Web 技术的特征使得 Widget 具有小巧轻便、 易于开发, 与操作系统耦合度低和功能完整等特性。每一个 Widget 都是面向具体的轻量级的任务。Widget 应用介于浏览器 / 服务器 (B/S, Browser/Server) 和客户端 / 服务器 (C/S, Client/Server) 架构之间, 结合了两者的优点。它并不完全依赖 于网络, 软件框架可以在本地获取, 而内容资源从网络获取, 程序代码和 UI 设计同样可以 从专门的服务器更新, 保留了 B/S 架构的灵活性。
Widget 作为一种特殊的 “网页” 正在改变着互联网的访问方式, 用户访问网络不再 需要依赖于浏览器, 而是靠这些小工具就可以实现 Web 功能。随着互联网用户的需求改变 以及 Widget 技术的发展, Widget 已经不仅仅局限于个人电脑 (PC, Personal Computer) 桌 面, 开始渗透到其他领域, 例如网页 Widget、 移动 Widget、 人机交互 Widget, 甚至 Widget 专 用终端等。
移动 Widget 指运行于移动终端上的 Widget。手机终端屏幕相对较小, 浏览器却 占用了有限的屏幕资源, 导致手机上网用户体验较差, 而移动 Widget 应用框架非常适合于 手机终端, 移动 Widget 不仅可以独立于浏览器运行, 有效地利用手机屏幕, 而且可以更加 直接快速方便地访问移动互联网, 给手机用户带来良好的呈现方式和互联网体验。且移动 Widget 特定的服务和内容使得用户更加容易获得有用信息, 减少流量, 避免冗余的数据传 输带来额外的流量。移动 Widget 所具有的易开发、 易部署、 个性化、 交互式、 消耗流量少等 特性使得它非常适合于移动互联网。
目前 Widget 包的大小范围为几十 k ~几 M 字节, 随着 Widget 包中图片等资源文 件的增多, Widget 包也随之增大。另外, 目前 Widget 通常都是基于标的超文本标记语言 (HTML, Hyper Text Markup Language)、 JavaScript 脚本语言 (JavaScript)、 层叠样式表单 (CSS, Cascading Style Sheet) 等传统网页开发语言进行开发, 开发难度比较小, 开发者很 容易对 Widget 开发新功能, 修改现有功能, 修改 Widget 中存在的缺陷, 对 Widget 进行不断 维护和更新。
现有技术中, 对 Widget 更新是采用下载新版 Widget 包, 替换客户端上的旧版 Widget 包来实现的。
在对现有技术的研究和实践过程中, 本发明的发明人发现上述方法是通过下载一 个完整的新版本 Widget 包来对旧版本进行更新的, 但是本发明的发明人发现这种方法会 造成较大的网络开销, 且更新效率较低。发明内容 本发明实施例提供一种 Widget 更新的方法、 客户端、 服务器及系统, 能够减小网 络开销, 提高 Widget 更新效率。
本发明实施例是通过以下技术方案实现的 :
一种微件 Widget 更新的方法, 包括 :
下载 Widget 更新描述文件, 所述 Widget 更新描述文件中包括 Widget 补丁的相关 信息 ;
根据所述 Widget 补丁的相关信息下载 Widget 补丁 ;
根据所述 Widget 补丁进行更新, 得到指定版本的 Widget 包。
一种微件 Widget 客户端, 包括 :
更新描述文件处理单元, 用于下载并解析 Widget 更新描述文件, 所述 Widget 更新 描述文件中包括 Widget 补丁的相关信息 ;
补丁下载单元, 用于根据所述更新描述文件处理单元解析得到的 Widget 补丁相 关信息, 下载 Widget 补丁 ;
Widget 更新单元, 用于根据补丁下载单元所下载的 Widget 补丁, 对 Widget 进行更 新, 得到指定版本的 Widget 包。
一种微件 Widget 更新服务器, 包括 :
接收单元, 用于接收 Widget 客户端的 Widget 更新描述文件请求消息 ;
发送单元, 用于根据所述接收单元接收到的 Widget 更新描述文件请求消息, 将存 储的或生成的 Widget 更新描述文件发送至所述 Widget 客户端。
一种微件 Widget 服务器, 包括 :
接收单元, 用于接收 Widget 客户端所发送的 Widget 补丁请求消息 ;
发送单元, 用于向所述 Widget 客户端发送存储的或生成的 Widget 补丁。
一种微件 Widget 系统, 包括 : Widget 客户端、 Widget 更新服务器和 Widget 服务 器, 其中 :
所述 Widget 客户端, 用于从所述 Widget 更新服务器下载 Widget 更新描述文件, 所述 Widget 更新描述文件中包括 Widget 补丁的相关信息 ; 根据所述 Widget 补丁的相关 信息下载 Widget 补丁, 并根据所述 Widget 补丁进行 Widget 部分更新, 得到指定版本的 Widget 包。
所述 Widget 更新服务器, 用于存储或自动生成所述 Widget 更新描述文件, 并向所 述 Widget 客户端提供所述 Widget 更新描述文件 ;
所述 Widget 服务器, 用于存储或自动生成所述 Widget 补丁, 并向所述 Widget 客 户端提供所述 Widget 补丁。
本发明实施例中通过下载 Widget 更新描述文件, 并根据所述 Widget 更新描述文 件中包括的 Widget 补丁相关信息下载 Widget 补丁, 再根据所述 Widget 补丁进行更新, 由 于只需要根据 Widget 补丁进行 Widget 部分更新, 因此可以减小网络开销, 提高 Widget 更 新效率。
附图说明 为了更清楚地说明本发明实施例或现有技术中的技术方案, 下面将对实施例或现 有技术描述中所需要使用的附图作简单地介绍, 显而易见地, 下面描述中的附图仅仅是本 发明的一些实施例, 对于本领域普通技术人员来讲, 在不付出创造性劳动性的前提下, 还可 以根据这些附图获得其他的附图。
图 1 是本发明实施例一中 Widget 更新的方法流程图 ;
图 2 是本发明实施例二中 Widget 更新的方法流程图 ;
图 3 是本发明实施例三中 Widget 更新的方法流程图 ;
图 4 是本发明实施例四中 Widget 更新的方法流程图 ;
图 5 是本发明实施例五中 Widget 更新的方法流程图 ;
图 6 是本发明实施例六 Widget 更新的方法流程图 ;
图 7 是本发明实施例七中 Widget 客户端结构示意图 ;
图 8 是本发明实施例八中 Widget 客户端结构示意图 ;
图 9 是本发明实施例九中 Widget 客户端结构示意图 ;
图 10 是本发明实施例十中 Widget 更新服务器结构示意图 ;
图 11 是本发明实施例十一中 Widget 更新服务器结构示意图 ; 图 12 是本发明实施例十二中 Widget 服务器结构示意图 ; 图 13 是本发明实施例十三中 Widget 服务器结构示意图 ; 图 14 是本发明实施例十四中 Widget 系统结构示意图。具体实施方式
本发明的发明人发现, 现有技术中是通过下载一个完整的 Widget 包对 Widget 进 行更新, 而目前 Widget 包大小一般为几十 k ~几 M 字节, 且 Widget 包中图片等资源文件占 了较大部分的空间。Widget 开发者主要是通过对 Widget 布局、 Widget 逻辑的修改和更新, 来达到修改 Widget 中存在的缺陷、 修改现有功能以及添加新功能的目的。 Widget 包中的资 源文件在不同 Widget 版本中相对保持稳定, 不会进行大规模替换, 因此, 每次进行 Widget 更新都重新下载一个完整的 Widget 包, 会造成较大的网络资源浪费。
本发明实施例提供一种 Widget 更新的方法, 通过对 Widget 进行部分更新, 能够减 小网络开销, 提高 Widget 更新效率。本发明实施例还提供相应的 Widget 客户端、 服务器及 系统。 下面将结合本发明实施例中的附图, 对本发明实施例中的技术方案进行清楚、 完整地 描述, 显然, 所描述的实施例仅仅是本发明一部分实施例, 而不是全部的实施例。基于本发 明中的实施例, 本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施 例, 都属于本发明保护的范围。
实施例一、 参照图 1, 是本发明实施例一中 Widget 更新的方法流程图, 具体步骤如下 :
S101 : Widget 客户端下载 Widget 更新描述文件 (UDD, Update DescriptionDocument), 所述 Widget UDD 中包括 Widget 补丁的相关信息 ;
在具体实施中, Widget 客户端可以从 Widget 更新服务器下载 Widget UDD。
S102 : Widget 客户端根据所述 Widget 补丁的相关信息下载 Widget 补丁 ;
在具体实施中, Widget 客户端可以从 Widget 服务器下载 Widget 补丁。S103 : Widget 根据所述 Widget 补丁进行更新, 得到指定版本的 Widget 包。
在具体实施中, Widget 更新服务器与 Widget 服务器可以是同一个物理实体, 也可 以是分立的物理实体。
可见, Widget 客户端通过下载 Widget UDD, 并根据所述 Widget UDD 中包括的 Widget 补丁相关信息下载 Widget 补丁, 再根据所述 Widget 补丁进行更新, 由于只需要根据 Widget 补丁进行 Widget 部分更新, 因此可以减小网络开销, 提高 Widget 更新效率。
为使本领域技术人员更好地理解和实现本发明实施例, 以下实施例中通过具体的 应用场景进行说明 :
实施例二、 Widget UDD 中的 Widget 补丁相关信息可以包括 : Widget 补丁的统一 资源定位符 (URL, Universal Resource Locator) 地址、 更新后需要删除的文件信息。通常 Widget 更新服务器存储或者自动生成 UDD, 并处理 Widget 客户端的 UDD 请求, Widget 服务 器存储或自动生成 Widget 补丁, 并处理 Widget 客户端的 Widget 补丁请求, Widget 更新服 务器与 Widget 服务器可以是同一个物理实体, 也可以是分立的物理实体。 Widget 更新流程 参照图 2, 具体步骤如下 :
S201 : Widget 客户端通过向 Widget 配置文件 config.xml 中的 update 元素的 href 属性指定的 URL 地址请求相应的 UDD ; 在万维网联盟工作草案 “微件 1.0 版 : 封装与配置” (W3C Working Draft“Widget 1.0 : Packaging and Configuration” ) 中定义的 Widget 配置文件 config.xml 结构示例如 下:
< ? xml version =″ 1.0″ encoding =″ UTF-8″? >
xmlns =″ http://www.w3.org/ns/widgets″ // 命名空间
id =″ http://example.com/myWidget″ //Widget 标识符
version = “1.0″ //Widget 当前版本号
height =″ 200″ //Widget 屏幕显示高度
width =″ 200″ > //Widget 屏幕显示宽度
The example Widget ! //Widget 名字
//Widget 中用到的应用编程接口 (API)
A sample widget to demonstrate some of the possibilities.
//Widget 描述信息
href =″ http://foo-bar.example.org/″
email =″ foo-bar@example.org″ >
Foo Bar Corp
//Widget 作者相关信息
//Widget 图标
//Widget 的入口文件地址
href =″ http//example.com/update.php ? widget = myWidget&version = 1.0″ />
//Widget 更新地址
Example license(based on MIT License) Copyright(c)2008TheFoo Bar Corp. //Widget 版权信息
该示例中, “//”前内容表示用 xml 语言实现的具体功能, “//”后注释各行程 序 的 具 体 内 容, 其 中 update 元 素 由 万维 网 工 作 草 案 “微 件 1.0 版 : 更 新” (W3CWorking Draft“Widgets 1.0 : Updates” ) 定义, 是对 W3C Working Draft“Widgets1.0 : Packaging and Configuration” 所作的扩展。
当 Widget 客户端需要更新某个 Widget 时, 可以向该 Widget 的配置文件 config. xml 中的 Update 元素的 href 属性所指定的 URL 地址进行请求, 获取该 Widget 所对应的 UDD, 上述 URL 包括客户端上该 Widget 的标识符及当前版本号。
本实施例中 Widget UDD 的结构示例如下 :
< ? xml version =″ 1.0″ encoding =″ UTF-8″? >
xmlns =″ http://www.w3.org/ns/widgets″ // 命名空间
src = https://example.com/myWidget/v1.1/widget.patch
//Widget 最新版本补丁地址
version =″ 1.1″ //Widget 最新版本号
id = http://example.com/myWidget //Widget 标识符
bytes =″ 1024″ //Widget 补丁字节数
notify = ″ https://example.com/myWidget/updateManager.php ? justUpdated = {version}″ > //Widget 更新成功后, 可以向该地址进行通知
//details 节点描述 widget 相关修改信息, href 属性指向一个网页, 它用自然 语言描述 widget 最新版本有什么修改 / 更新
/js/1.js
/img/2.png
//Widget 包中需要删除的文件信息
该示例中, “//” 前内容表示用 xml 语言实现的具体功能, “//” 后注释各行程序的 具体内容, 其中 : Widgetupdate 是 UDD 的根元素, 其中 src 属性指明了该 Widget 当前最新 版本补丁的 URL 地址, version 属性指明了该 Widget 当前最新版本的版本号, id 属性指明 了该 Widget 的标识符, bytes 属性指明了该 Widget 最新版本补丁大小 ; notify 属性指明了 Widget 更新成功后, 可以向该属性所指的 URL 地址进行通知。 details 元素描述了该 Widget 的相关更新信息, remove 子元素描述了该 Widget 更新后需要删除的文件信息, href 属性指 向的网页采用自然语言描述对 Widget 修改情况进行了更进一步的说明。
S202 : Widget 更新服务器向 Widget 客户端返回相应的 UDD ;S203 : Widfet 客户端判断该 Widget 当前版本号与 UDD 中描述的最新版本号是否 相同, 如果相同, 则说明该 Widget 没有新版本, 无需更新, 流程结束 ; 否则继续步骤 S204 ;
Widget 客户端可以指定更新到哪一版本的 Widget 包, 这里默认更新到最新版本 的 Widget 包。
S204 : Widget 客户端向 UDD 中描述的 Widget 补丁的 URL 地址进行请求 Widget 补 丁;
S205 : Widget 服务器向 Widget 客户端返回 Widget 补丁 ;
S206 : Widget 客户端对 Widget 补丁进行相应验证, 采用 Widget 补丁中的文件替 换掉旧版 Widget 包中的同名文件, 同时根据 UDD 中 details 元素的 remove 子元素指定的 需要删除的文件, 将旧版 Widget 包中相应文件进行删除, 流程结束。
由于 Widget 配置文件 config.xml 中的 update 元素的 href 属性所指定的 URL 地 址中包括了客户端上该 Widget 的标识符以及当前版本号, 因此针对不同 Widget 客户端上 相同 widget 的不同版本, Widget 更新服务器返回的 UDD 中, 会分别指定不同的 Widget 补 丁以及相应的 remove 子元素, 从而不同版本的 Widget 均可以通过相应的 Widget 补丁升级 到最新版本。 可见, 本实施例中, 在有新的版本时, Widget 客户端可以通过 Widget UDD 文件从 Widget 更新服务器获取 Widget 补丁的 URL 地址, 并根据所述 Widget 补丁的 URL 地址, 从 Widget 服务器下载 Widget 补丁, 采用所述 Widget 补丁替换掉当前版本 Widget 包中的同名 文件, 并根据所述 Widget UDD 中的更新后需要删除的文件信息, 删除当前版本 Widget 包中 的相应文件, 从而实现 Widget 部分更新, 因此可以减小网络开销, 提高更新效率。
实施例三、 与实施例二的不同之处在于, Widget UDD 中的 Widget 补丁相关信息为 Widget 补丁描述文件的 URL 地址, 此时会增加 Widget 客户端与 Widget 更新服务器交互获 取 Widget 补丁描述文件的过程, Widget 更新服务器用来保存或自动生成 UDD 及 Widget 补 丁描述文件, 以及处理 Widget 客户端的 UDD 请求以及 Widget 补丁描述文件请求, Widget 服 务器存储或者自动生成 Widget 补丁, 处理 Widget 客户端的 Widget 补丁请求。 同样, Widget 更新服务器与 Widget 服务器可以是同一个物理实体, 也可以是相互分立的物理实体。参照 图 3, 具体步骤如下 :
S301 : Widget 客户端通过向 Widget 配置文件 config.xml 中的 update 元素的 href 属性指定的 URL 地址请求相应的 UDD ;
可以构造 Widget 补丁描述文件 widgetpatch.xml, 其中采用 remove 元素描述旧 版 Widget 中所需删除文件。通过 UDD 的 details 元素的 href 属性指向该 Widget 补丁描 述文件, 使 UDD 与 Widget 补丁描述文件建立关联。本实施例中的 UDD 结构示例如下 :
< ? xml version =″ 1.0″ encoding =″ UTF-8″ ?>
xmlns =″ http://www.w3.org/ns/widgets″ // 命名空间
src = “https://example.com/myWidget/v1.1/widget.patch”
//Widget 最新版本补丁地址
version =″ 1.1″ //Widget 最新版本号
id =″ http://example.com/myWidget″ //Widget 标识符
bytes =″ 1024″ //Widget 补丁字节数
notify = ″ https://example.com/myWidget/updateManager.php ? justUpdated = {version}″ > //Widget 更新成功后, 可以向该地址进行通知
We fixed some bugs and improved performance !
//details 节点描述 widget 相关修改信息, href 属性指向 widget 补丁描述文件
该示例中, “//” 前内容表示用 xml 语言实现的具体功能, “//” 后注释各行程序的 具体内容。
Widget 补丁描述文件结构示例如下 :
< ? xml version =″ 1.0″ encoding =″ UTF-8″? >
xmlns =″ http://www.w3.org/ns/widgets″ > // 命名空间
/js/1.js /img/2.png //Widget 包中需要删除的文件
该示例中, “//” 前内容表示用 xml 语言实现的具体功能, “//” 后注释各行程序的 具体内容。
S302 : Widget 更新服务器向 Widget 客户端返回相应的 UDD ;
S303 : Widget 客户端判断该 Widget 当前版本号与 UDD 中描述的最新版本号是否 相同, 如果相同, 则说明该 Widget 没有新版本, 无需更新, 流程结束 ; 否则继续步骤 S304 ;
S304 : Widget 根据 UDD 的 details 元素的 href 属性所指向的 URL 地址请求对应 的 Widget 补丁描述文件 ;
S305 : Widget 更新服务器向 Widget 客户端返回 Widget 补丁描述文件 ;
S306 : Widget 客户端根据 UDD 中描述的 Widget 补丁的 URL 地址向 Widget 服务器 请求对应的 Widget 补丁 ;
S307 : Widget 服务器向 Widget 客户端返回对应的 Widget 补丁 ;
S308 : Widget 客户端对 Widget 补丁进行相应验证, 采用 Widget 补丁中的文件替 换掉旧版 Widget 包中的同名文件, 并根据所述 Widget 补丁描述文件中的需要删除的文件 信息, 删除当前版本 Widget 包中的相应文件。
可见, 本实施例中, Widget 客户端从 Widget 更新服务器获取 Widget UDD, 如果需 要更新, 则获取 Widget UDD 所指向的 Widget 补丁描述文件, 从 Widget 服务器下载 Widget 补丁替代当前版本中的同名文件, 并且根据 Widget 补丁描述文件中的需要删除的文件信 息, 删除当前版本 Widget 包中的相应文件, 从而实现 Widget 的部分更新, 因此可以减小网 络开销, 并提高更新效率。
实施例四、 与实施例三中所采用的 Widget UDD 结构类似, 不同之处在于, Widget UDD 的 details 元素的 href 属性所指定的 URL 不再指向 Widget 补丁描述文件, 且将 Widget 补丁描述文件 widgetpatch.xml 一并放在 Widget 补丁中, 具体执行流程与实施例二类似,
具体步骤如下 :
S401 : Widget 客户端通过向 Widget 配置文件 config.xml 中的 update 元素的 href 属性指定的 URL 地址请求相应的 UDD ;
S402 : Widget 更新服务器向 Widget 客户端返回相应的 UDD ;
S403 : Widget 客户端判断该 Widget 当前版本号与 UDD 中描述的最新版本号是否 相同, 如果相同, 则说明该 Widget 没有新版本, 无需更新, 流程结束 ; 否则继续步骤 S404 ;
S404 : Widget 客户端向 UDD 中描述的 Widget 补丁的 URL 地址进行请求 ;
S405 : Widget 服务器向 Widget 客户端返回 Widget 补丁 ;
S406 : Widget 客户端对 Widget 补丁进行相应验证, 采用 Widget 补丁中的文件替 换掉旧版 Widget 包中的同名文件, 同时根据 Widget 补丁中的 Widget 补丁描述文件, 将旧 版 Widget 包中相应文件进行删除, 流程结束。
同样可以看出, 本实施例中, 仅仅通过下载需要更新的补丁, 实现 Widget 的部分 更新, 从而可以减小网络开销, 提高更新效率。
前述实施例二至四中以将 Widget 更新到最新版本进行说明, 如前所述, 在具体实 施中, 可以将 Widget 更新到所指定的任意版本, 以下通过一个具体的实施实例进行说明 : 实施例五、 将 Widget 更新到任意版本, 参照图 5, 具体步骤如下 :
S501 : Widget 客户端在获得的 URL 地址后面添加想要更新的目标版本号 ;
Widget 客户端从 Widget 配置文件 config.xml 获得 update 元素的 href 属性, 比 如获得的 URL 地址为 :
″ http//example.com/update.php ? widget = myWidget&version = 1.0″
例如, 可采用″ targetVersion = 1.3″的模式, 得到新的 URL 地址为 :
″ http//example.com/update.php ? widget = myWidget&version = 1.0&targetVersion = 1.3″
S502 : Widget 客户端根据该 URL 地址, 向 Widget 更新服务器请求 UDD ;
S503 : Widget 更新服务器进行相应处理, 返回相应的 UDD, 这里存在几种策略 :
a. 如果该目标版本号 targetVersion = 1.3 对应的 Widget 存在, 则返回相应的 UDD, 其中包含该目标版本对应的 Widget 补丁相关信息 ;
b. 如果该目标版本号 targetVersion = 1.3 对应的 Widget 不存在, 则返回最新版 本 UDD, 其中包含该 Widget 最新版本的 Widget 补丁相关信息。
S504 : Widget 客户端根据返回的 UDD 进行相应处理, 判断是否存在更新, 如果存在 更新, 则执行 S505 ; 否则, 结束流程 ;
S505 : Widget 客户端向 Widget 服务器请求 Widget 补丁 ;
S506 : Widget 服务器返回 Widget 补丁 ;
S507 : Widget 客户端根据 Widget 补丁更新 Widget。
实施例六、 在具体实施中, 本发明实施例所述 Widget 更新的方法还适用于多个相 互关联的 Widget 进行更新的场景。例如, 在 Widget 客户端中多个 Widget 相互间存在通信 的场景中, 可能多个 Widget 间存在关联关系 ( 例如依赖关系 ), 一个 Widget 的更新可能导 致该 Widget 不可用或者依赖于该 Widget 的其他 Widget 不可用。以下通过几个具体的场 景进行说明 :
Widget 客户端上存在两个 Widget : 天气预报 widget(weather widget, 版本号 1.2) 和地图 widget(map widget, 版本号 1.3)。天气预报 widget(1.2 版本 ) 依赖于地图 widget(1.3 版本 ), 天气预报 widget 需要从地图 widget 获得某地区的地图, 然后将相应的 天气信息整合在地图上展现给用户。服务器上, 天气预报 widget 和地图 widget 的最新版 本号分别是 1.3 和 1.6。
情况 1 : Widget 客户端对天气预报 widget 进行更新, 天气预报 widget 被更新成最 新版 1.3 版本, 而 1.3 版本的天气预报 widget 依赖于 1.4 版本的地图 widget(1.3 版本的 天气预报 widget 与 1.3 版本的地图 widget 不兼容 ), 而 Widget 客户端上目前没有 1.4 版 本的地图 widget, 从而出现天气预报 widget 更新导致天气预报 widget 自身无法使用的情 况;
情况 2 : Widget 客户端对地图 widget 进行更新, 地图 widget 被更新成最新版 1.6 版本, 而 1.2 版本的天气预报 widget 依赖于 1.3 版本的地图 widget(1.2 版本的天气预报 widget 与 1.6 版本的地图 widget 不兼容 ), 而 widget 客户端上目前没有 1.3 版本的地图 widget, 从而出现地图 widget 更新导致依赖于地图 widget 的天气预报 widget 无法使用的 情况 ;
情况 3 : Widget 客户端同时对天气预报 widget 和地图 widget 进行了更新, 均更新 成最新版。但是 1.3 版本的天气预报 widget 与 1.6 版本的地图 widget 不兼容, 造成天气 预报 widget 无法使用的情况。
在本发明实施例中, 通过将 Widget 更新到最新版本, 且同时将与之关联的其他 Widget 进行相应更新 ( 将其他 Widget 更新到任意指定版本, 而未必是最新版本 ), 即可解 决上述互相关联的至少两个 Widget 更新所导致的 Widget 无法正常使用的情况。
可以理解的是, 如前实施例所述, 也可以将该 Widget 更新到其他指定版本, 同时 将与之关联的其他 Widget 进行相应更新。
设 Widget 客户端有 : Widget A 以及与 Widget A 关联的其他 Widget, 参照图 6, 以 下以 Widget A 的更新过程进行说明 :
S601 : Widget 客户端通过向 Widget 配置文件 config.xml 中的 update 元素的 href 属性指定的 URL 地址请求 Widget A 的 UDD ;
可 以 将 Widget A 的 配 置 文 件 config.xml 中 的 update 元 素 的 href 属 性 进 行 如 下 约 定, 采 用 widget1 和 version1 描 述 Widget A 的 标 识 符 和 当 前 版 本 号, 采用 widget2/version2, widget3/version3... 描 述 Widget A 所 依 赖 的 其 它 Widget 的 标 识 符和当前版本号。例如, weather widget 的 config.xml 的 update 元素为 :
, 则表示 weather widget 当前版本号为 1.2, 依赖于当前版本号 为 1.3 的 map widget。
S602 : Widget 更新服务器向 Widget 客户端返回 Widget A 的 UDD ;
对于存在多个 Widget 关联的情况, Widget 更新服务器保存或自动生成的 UDD 结构 也发生了相应变化。例如, Widget A 对应的 UDD 中包括 Widget A 的更新信息和 WidgetA 所 依赖的其它 Widget 的更新信息, UDD 中描述的 WidgetA 和 Widget A 所依赖的其他 Widget 的更新后版本相互兼容。例如, weather widget 的 UDD 结构示例如下 :< ? xml version =″ 1.0″ encoding =″ UTF-8″? >
xmlns =″ http://www.w3.org/ns/widgets″ // 命名空间
src =″ https://example.com/weatherWidget/v1.3/weather.patch″
//weatherWidget 最新版本补丁地址
version =″ 1.3″ //weatherWidget 最新版本号
id =″ http://example.com/weatherWidget″ //Widget 标识符
bytes =″ 1024″ //Widget 补丁字节数
notify = ″ https://example.com/weatherWidget/updateManager.php ? justUpdated =
{version}″ > //Widget 更新成功后, 可以向该地址进行通知
//details 节点描述 weatherWidget 相关修改信息, href 属性指向一个网页,
它用自然语言描述 widget 最新版本有什么修改 / 更新
/img/2.jpg
/js/1.js //Widget 包中需要删除的文件信息
src =″ https://example.com/mapWidget/v1.4/map.patch″
//mapWidget 相应版本的补丁地址
version =″ 1.4″ //mapWidget 相应版本的版本号
id =″ http://example.com/mapWidget″ //mapWidget 标识符
bytes =″ 804″ //mapWidget 补丁字节数
notify =″ https://example.com/mapWidget/updateManager.php ? justUpdated =
{version}″ > //mapWidget 更新成功后, 可以向该地址进行通知
//details 节点描述 widget 相关修改信息, href 属性指向一个网页,
它用自然语言描述 widget 相应版本有什么修改 / 更新
/html/xx.html
//Widget 包中需要删除的文件信息
该示例中, “//” 前内容表示用 xml 语言实现的具体功能, “//” 后注释各行程序的 具体内容。
其中包括 weather widget 更新信息 ( 最新版本号为 1.3), 同时, 采用 refwidget 元素描述了 weather widget 所依赖的 map widget 的更新信息 ( 为了与 weatherwidget 进 行兼容, map widget 的更新版本号为 1.4, 而不是采用 map widget 的最新版本 1.6)。如 果 Widget A 依赖于多个其它 Widget, 则 Widget A 的 UDD 中可以包括多个 refwidget 元 素, Widget A 的补丁是最新版本, 为了能够与 Widget A 进行兼容, Widget A 所依赖的其它 Widget 的补丁可能不是最新版本。如本实施例中 weather widget 的 UDD 结构中采用 details 元素的 remove 子元素来描述需要删除的 Widget 文件。
S603 : Widget 客户端根据所返回的 Widget A 的 UDD 判断 Widget A 及 WidgetA 所 依赖的其他 Widget 是否存在更新, 如果是, 则执行 S604 ; 否则结束流程 ;
S604、 Widget 客户端向 Widget A 的 UDD 中描述的 Widget 补丁的 URL 地址请求 Widget A 和 Widget A 所依赖 Widget 的补丁 ;
S605 : Widget 服务器向 Widget 客户端返回 Widget A 和 Widget A 所依赖的 Widget 的补丁 ;
S606 : Widget 客户端对 Widget A 和 Widget A 所依赖的其他 Widget 的补丁进行 相应验证, 采用 Widget 补丁中的文件替换掉旧版 Widget 包 ( 包括 WidgetA 及 Widget A 依 赖的其他 Widget 的 Widget 包 ) 中的同名文件, 同时根据 Widget A 的 UDD 中 details 元素 的 remove 子元素指定的需要删除的文件, 将旧版 Widget 包 ( 包括 Widget A 及 Widget A 依赖的其他 Widget 的 Widget 包 ) 中相应文件进行删除, 流程结束。
本实施例中, 对于 Widget 客户端有多个相互关联的 Widget 时采用实施例二中所 述的更新方法, 可以理解的是, 也可以采用前述实施例三、 实施例四中所介绍的方法, 具体 流程大致相同。例如, 对于某个 Widget 存在与之关联的其他 Widget 时, 所述 Widget 补丁 相关信息可以包括 : 所述 Widget 及与之关联的其他 Widget 的补丁对应的 URL 地址、 所述 Widget 及与之关联的其他 Widget 的补丁描述文件对应的 URL 地址 ; 对应的, 所述采用所述 Widget 补丁的相关信息下载 Widget 补丁的步骤包括 : 根据所述 Widget 及与之关联的其他 Widget 的补丁描述文件对应的 URL 地址, 从 Widget 更新服务器获取所述 Widget 及与之关 联的其他 Widget 补丁描述文件 ; 根据所述 Widget 及与之关联的其他 Widget 的补丁对应 的 URL 地址, 从 Widget 服务器下载所述 Widget 及与之关联的其他 Widget 的补丁 ; 而采用 所述 Widget 补丁进行更新的步骤包括 : 将所述 Widget 及与之关联的其他 Widget 的补丁 替换掉所述 Widget 及与之关联的其他 Widget 当前版本 Widget 包中的同名文件, 并根据所 述 Widget 及与之关联的其他 Widget 的补丁描述文件中的需要删除的文件信息, 删除所述 Widget 及与之关联的其他 Widget 当前版本 Widget 包中的相应文件。
对于某个 Widget 存在与之关联的其他 Widget 时, 所述 Widget 补丁相关信息可以 包括 : 所述 Widget 及与之关联的其他 Widget 的补丁对应的统一资源定位符 URL 地址 ; 对应 的, 根据所述 Widget 补丁的相关信息下载 Widget 补丁的步骤包括 : 根据所述 Widget 及与 之关联的其他 Widget 的补丁对应的 URL 地址, 从 Widget 服务器下载所述 Widget 及与之关 联的其他 Widget 的补丁, 所述 Widget 及与之关联的其他 Widget 的补丁中包括所述 Widget 及与之关联的其他 Widget 需要删除的文件信息 ; 而根据所述 Widget 补丁进行更新的步骤 包括 : 根据所述 Widget 及与之关联的其他 Widget 的补丁替换掉所述 Widget 及与之关联 的其他 Widget 当前版本 Widget 包中的同名文件, 并根据所述 Widget 及与之关联的其他 Widget 的补丁中包括的需要删除的文件信息, 删除所述 Widget 及与之关联的其他 Widget 当前版本 Widget 包中的相应文件。
以下仍以 weather widget 和 map widget 为例来说明本实施例在各种场景中具体 应用 :
场景 1 :1) 当前 weather widget 版本 1.2, map widget 版本 1.3 ;
2)weather widget 进行更新, 例如, 按照图 6 所示的流程, 可以顺利完成 weather widget 和 map widget 的更新, 更新后, weather widget 版本 1.3, map widget 版本 1.4 ;
3) 更新结束。
场景 2 :
1) 当前 weather widget 版本 1.2, map widget 版本 1.3 ;
2)map widget 进行更新, 按照实施例二至四任一实施例所述的流程, mapwidget 可 被更新为 1.6 ;
3)weather widget 进行更新, Widget 客户端通过对 weather widget 的 config. xml 的 update 元 素 进 行 分 析, update 元 素 为 :
, 发现 map widget 的当前版本号不是 1.3, 而是 1.6, 所以可以通过 URL
″ http//example.com/update.php ? widget1 = weather&version1 = 1.2&widget2 = map&version2 = 1.6″向 Widget 更新服务器进行请求, Widget 更新服务 器发现这是多个存在依赖关系的 Widget 间的更新, 因此同意对 map widget 进行降版本更 新 ( 从版本 1.6 降为版本 1.4), 返回的 UDD 中, weather widget 版本为 1.3, mapwidget 版 本为 1.4 ; 4)Widget 客户端通过分析 UDD, 发现这是多个存在依赖关系的 Widget 间的更新 ; weather widget 顺利完成更新 ( 从版本 1.2 更新为版本 1.3), 当对 mapwidget 进行更新 时, Widget 客户端发现现有的 map widget 版本为 1.6, 而需要降版本更新为 1.4, 为了用 户能够正常使用 1.6 版本的 map widget, 同时也让 weatherwidget 能够正常运行, Widget 客户端可以生成 map widget 的一个备份, 该备份对用户不可见, 只对依赖于该版本的其它 Widget( 比如 weather widget) 可见, 并用 map widget 的补丁将其从 1.6 版本降级为 1.4 版本 ; weather widget 的 config.xml 的 update 元素也更新为 :
href =″ http//example.com/update.php ? widget1 = weather&version1 = 1.3
&widget2 = map&version2 = 1.4″ />
5) 更新结束。
则以后 weather widget 运行时, 就与 1.4 版本的 map widget 进行通信, 而不与 1.6 版本的 map widget 进行通信。
情景 3 :
1) 当前 weather widget 版本 1.3, 备份 map widget 版本 1.4, map widget 版本 1.6 ;
2) 更 新 服 务 器 端 存 在 1.4 版 本 的 weather widget, 其 依 赖 于 1.5 版 本 的 mapwidget ;
3)Widget 客户端更新 weather widget, 并触发备份 map widget 进行版本更新, 更 新完成后, weather widget 版本 1.4, 备份 map widget 版本 1.5, map widget 版本 1.6 ;
4) 更新结束。
情景 4 :
1) 当前 weather widget 版本 1.4, 备份 map widget 版本 1.5, map widget 版本 1.6 ;
2) 更 新 服 务 器 端 存 在 1.5 版 本 的 weather widget, 其 依 赖 于 1.6 版 本 的 mapwidget ;
3)Widget 客 户 端 更 新 weather widget, 将 其 更 新 为 版 本 1.5, 并触发备份 mapwidget 进行版本更新, 由于备份 map widget 需要被更新为版本 1.6, 而 Widget 客户端已 经存在 1.6 版本的 map widget, 因此 Widget 客户端将备份 map widget 删除 ; 现在 widget 客户端存在 1.5 版本的 weather widget 和 1.6 版本的 map widget ;
4) 更新结束。
各个应用场景中的 Widget 更新均可采用实施例一至五任一实施例中所述的方 法进行更新, 不同之处在于, 需要同时更新与之关联的其他 Widget。考虑到兼容性, 各个 Widget 更新后未必都是最新版本。
可见, 本实施例通过对多个相互关联的 Widget 进行部分更新, 可以减小网络开 销, 提高更新速度, 且同步更新可以实现更新后的各个 Widget 相互兼容。
以上通过具体实施例对 Widget 更新的方法进行了详细的说明, 以下详细介绍上 述方法对应的客户端、 服务器及系统。
实施例七、 一种 Widget 客户端, 如图 7 所示, 该客户端包括 :
更新描述文件处理单元 701, 用于下载并解析 Widget 更新描述文件, 所述 Widget 更新描述文件中包括 Widget 补丁的相关信息 ;
补丁下载单元 702, 用于根据所述更新描述文件处理单元 701 解析得到的 Widget 补丁相关信息, 下载 Widget 补丁 ;
Widget 更 新 单 元 703, 用 于 根 据 补 丁 下 载 单 元 702 所 下 载 的 Widget 补 丁, 对 Widget 进行更新, 得到指定版本的 Widget 包。
在具体实施中, 如图 7 所示, 更新描述文件处理单元 701 解析得到的 Widget 补丁 的相关信息可以包括 : Widget 补丁的统一资源定位符 URL 地址、 更新后需要删除的文件信 息; 对应的, 补丁下载单元 702, 可用于根据所述更新描述文件处理单元解析得到的 Widget 补丁的 URL 地址, 下载 Widget 补丁 ; Widget 更新单元 703 可以包括第一更新子单元 703-1 和第二更新子单元 703-4, 其中 : 第一更新子单元 703-1 用于根据采用补丁下载单元 702 下 载的 Widget 补丁替换掉当前版本 Widget 包中的同名文件 ; 第二更新子单元 703-2, 用于根 据所述更新后需要删除的文件信息, 删除当前版本 Widget 包中的相应文件。
实施例八, 参照图 8, 在具体实施中, 与实施例七中的 Widget 客户端可以有如下不 同之处 :
更新描述文件处理单元 801 解析得到的 Widget 补丁相关信息可以包括 : Widget 补丁的 URL 地址、 Widget 补丁描述文件的 URL 地址 ; 对应的, 补丁下载单元 802, 包括第一下 载单元 802-1, 和第二下载单元 802-2, 其中 : 第一下载单元 802-1, 可用于根据更新描述文 件处理单元 801 解析得到的 Widget 补丁描述文件的 URL 地址获取 Widget 补丁描述文件, 所述补丁描述文件中包含需要删除的文件的信息 ; 第二下载单元 802-2, 可用于根据更新 描述文件处理单元 801 解析得到的 Widget 补丁的 URL 地址, 下载 Widget 补丁 ; Widget 更 新单元 803 可以包括第三更新子单元 803-1 和第四更新子单元 803-2, 其中 : 第三更新子单 元 803-1, 用于采用第二下载单元 802-2 下载的 Widget 补丁替换掉当前版本 Widget 包中的 同名文件 ; 第四更新子单元 803-2, 用于根据第一下载单元 802-1 下载的所述 Widget 补丁描述文件中的需要删除的文件信息, 删除当前版本 Widget 包中的相应文件。
实施例九, 参照图 9, 在具体实施中, 与实施例七、 八中的 Widget 客户端可以有如 下不同之处 :
更新描述文件处理单元 901 解析得到的 Widget 补丁相关信息可以包括 : Widget 补丁的统一资源定位符 URL 地址 ; 对应的, 补丁下载单元 902, 可以用于根据所述 Widget 补 丁的 URL 地址从 Widget 服务器下载 Widget 补丁, 所述 Widget 补丁中包括需要删除的文件 信息 ; Widget 更新单元 903 可以包括 : 第五更新子单元 903-1, 用于根据所述 Widget 补丁替 换掉当前版本 Widget 包中的同名文件, 并根据所述 Widget 补丁中包括的需要删除的文件 信息, 删除当前版本 Widget 包中的相应文件。
本实施例中的 Widget 客户端通过下载 Widget 更新描述文件, 并根据所述 Widget 更新描述文件中包括的 Widget 补丁相关信息下载 Widget 补丁, 再根据所述 Widget 补丁进 行更新, 由于只需要根据 Widget 补丁进行部分 Widget 更新, 因此采用所述 Widget 客户端 进行更新可以减小网络开销, 提高 Widget 更新效率。
本发明实施例还提供了相应的 Widget 服务器, 该服务器包括 :
接收单元, 用于接收 Widget 客户端的 Widget 更新描述文件请求消息 ;
发送单元, 用于根据所述接收单元接收到的 Widget 更新描述文件请求消息, 将存 储的或生成的 Widget 更新描述文件发送至所述 Widget 客户端。
以下通过两个具体的实施例进行说明 :
实施例十、 一种微件 Widget 更新服务器, 如图 10 所示, 该更新服务器可以包括 :
第一存储单元 1001, 用于存储 Widget 更新描述文件, 所述 Widget 更新描述文件中 包括 Widget 补丁的相关信息 ;
第一接收单元 1002, 用于接收 Widget 客户端的 Widget 更新描述文件请求消息 ;
第一处理单元 1003, 用于根据第一接收单元 1002 接收到的 Widget 更新描述文件 请求消息, 从第一存储单元 1001 中获取相应的 Widget 更新描述文件 ;
第一发送单元 1004, 用于向所述 Widget 客户端发送第一处理单元 1003 所获取的 Widget 更新文件描述文件。
本实施例中的 Widget 更新服务器通过向 Widget 客户端提供所需更新的 Widget 补丁的相关信息, 使得 Widget 客户端根据所述 Widget 补丁的相关信息, 获取到更新所需要 的补丁, 进而实现 Widget 部分更新, 因而可以减小网络开销, 提高更新效率。
实施例十一、 一种微件 Widget 更新服务器, 参照图 11, 该服务器包括 :
第二接收单元 1101, 用于接收 Widget 客户端发送的 Widget 更新描述文件请求消 息;
第一生成单元 1102, 用于根据第二接收单元 1101 接收到的 Widget 更新描述文件 请求消息, 生成相应的 Widget 更新描述文件, 所述 Widget 更新描述文件中包括 Widget 补 丁的相关信息 ;
第二发送单元 1103, 用于向所述 Widget 客户端发送第一生成单元 1102 所生成的 Widget 更新描述文件。
可见, 本实施例中所提供的 Widget 更新服务器与实施例十的不同之处在于, 本 Widget 更新服务器中不需要保存 Widget 更新描述文件, 而是在接收到 Widget 客户端发送的 Widget 更新描述文件请求消息时, 自动生成相应的 Widget 更新描述文件并返回 Widget 客户端, 从而使 Widget 客户端根据所述 Widget 补丁的相关信息, 获取到更新所需要的补 丁, 进而实现 Widget 部分更新, 因而可以减小网络开销, 提高更新效率。
本发明实施例还提供了相应的 Widget 服务器, 该服务器包括 :
接收单元, 用于接收 Widget 客户端所发送的 Widget 补丁请求消息 ;
发送单元, 用于向所述 Widget 客户端发送存储的或生成的 Widget 补丁。
以下通过两个具体的实施例进行说明 :
实施例十二、 一种微件 Widget 服务器, 参照图 12, 该服务器可以包括 :
第二存储单元 1201, 用于存储 Widget 补丁 ;
第三接收单元 1202, 用于接收 Widget 客户端所发送的 Widget 补丁请求消息 ;
第二处理单元 1203, 用于根据第三接收单元 1202 接收到的 Widget 补丁请求消息, 从第二存储单元获取相应的 Widget 补丁 ;
第三发送单元 1204, 用于向所述 Widget 客户端发送第二处理单元 1203 所获取的 Widget 补丁。
本实施例所提供的 Widget 服务器在接收到 Widget 客户端发送的 Widget 补丁请 求时, 向 Widget 客户端提供更新所需的 Widget 补丁, 从而使得 Widget 客户端只需要下载 与当前版本不同的 Widget 补丁即可实现更新, 由于不需要下载完整的 Widget 包, 因此可以 减小网络开销, 提供提高更新效率。
实施例十三、 一种微件 Widget 服务器, 参照图 13, 该服务器包括 :
第四接收单元 1301, 用于接收 Widget 客户端发送的 Widget 补丁请求消息 ;
第二生成单元 1302, 用于根据第四接收单元 1301 接收到的 Widget 补丁请求消息, 生成相应的 Widget 补丁 ;
第四发送单元 1303, 用于向所述 Widget 客户端发送第二生成单元 1302 所生成的 Widget 补丁。
实施例十四、 一种微件 Widget 系统, 参照图 14, 该系统包括 : Widget 客户端 1401、 Widget 更新服务器 1402 和 Widget 服务器 1403, 其中 :
Widget 客户端 1401, 用于从 Widget 更新服务器 1402 下载 Widget 更新描述文件, 所述 Widget 更新描述文件中包括 Widget 补丁的相关信息 ; 根据所述 Widget 补丁的相关 信息从 Widget 服务器 1403 下载 Widget 补丁, 并根据所述 Widget 补丁进行 Widget 部分更 新, 得到指定版本的 Widget 包。
Widget 更新服务器 1402, 用于存储或自动生成 Widget 更新描述文件, 并向 Widget 客户端 1401 提供所述 Widget 更新描述文件 ;
Widget 服务器 1403, 用于存储或自动生成 Widget 补丁, 并向 Widget 客户端 1901 提供所述 Widget 补丁。
本实施例所介绍的 Widget 系统中, Widget 客户端通过从 Widget 更新服务器下 载 Widget 更新描述文件, 并根据所述 Widget 更新描述文件中包括的 Widget 补丁相关信 息从 Widget 服务器下载 Widget 补丁, 再根据所述 Widget 补丁进行更新, 由于只需要根据 Widget 补丁进行 Widget 部分更新, 因此可以减小网络开销, 提高 Widget 更新效率。
在具体实施中, Widget 更新服务器 1902 与 Widget 服务器 1903 可以为同一个物理实体, 也可以为分立的物理实体。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程, 是可以 通过计算机程序来指令相关的硬件来完成, 所述的程序可存储于一计算机可读取存储介质 中, 该程序在执行时, 可包括如上述各方法的实施例的流程。其中, 所述的存储介质可为磁 碟、 光盘、 只读存储记忆体 (Read-Only Memory, ROM) 或随机存储记忆体 (Random Access Memory, RAM) 等。
以上对本发明实施例所提供的 Widget 更新的方法、 客户端、 服务器及系统进行了 详细介绍, 本文中应用了具体个例对本发明的原理及实施方式进行了阐述, 以上实施例的 说明只是用于帮助理解本发明的方法及其核心思想 ; 同时, 对于本领域的一般技术人员, 依 据本发明的思想, 在具体实施方式及应用范围上均会有改变之处, 综上所述, 本说明书内容 不应理解为对本发明的限制。