移动手机Web

移动手机Web（精选7篇）

移动手机Web 篇1

1 WEB网关建设意义

移动 (手机) 消费者需要访问广泛变化的Internet内容:新闻、银行业务、拍卖、博客、照片、电子邮件、社会网络以及购物等。但允许移动设备使用者无拘无束地访问Internet会导致危险—未经改写的内容会过度占用内存、屏幕大小限制以及手机的有限带宽。此外, 过长下载的时间和不一致的导航也导致了不良的用户体验。为了使内容在移动设备上可以访问, 不得不在仅使用于移动设备的站点、运营商的“围墙花园”以及门户站点建立适用于移动设备的版本。然而, 这样的解决方案昂贵且限制消费者的选择。

WEB网关的无线互联网系统集成了手机页面智能适配技术, 通过网页适配模块, 统一策略管理模块、用户管理系统等, 提供一整套完整的运营商级的手机页面自动适配系统, 可以同时为大容量移动在线用户提供平滑的移动互联网访问服务, 并可提供更好的业务模型。通过使用内容适配技术, 动态地、透明地、智能地适配全部网页以在手持设备屏幕上显示, 而取代分离的移动专用内容。入网用户能使用真正的Internet, 就像使用成熟的网络浏览器看到的一样。此外, 通过在服务器上获取并适配内容, 客户端只需下载简化后的页面, 手机页面适配技术提供了动态快捷的浏览和导航功能。

WEB网关可为移动网络运营商提供运营商级的商业基础解决方案, 用来向其WAP 2.0的移动用户提供全HTML的网络浏览方式。手机适配的功能模块使运营商快速展开一个新的Internet服务, 这些服务之前可能是仅适用于便携笔记本、智能手机和其他高端设备上的。这样便能够增加每个用户的平均收益 (ARPU) , 大大提高用户的品牌忠诚度。

手机页面适配的功能可以同时提供在适配的内容中插入广告。广告功能模块提供非比寻常的设备敏感及客户敏感的广告运作支持。运营商可以促销其自有产品, 也可以从第三方广告中获得可观的收入。

作为一个高度集成的能提供多种IP服务的移动数据业务提供和管理平台, 它能对用户访问互联网的WEB流量提供加速、适配、内容过滤、手机广告、手机互联网视频适配等多种服务能力, 并提供详细的用户移动互联网行为数据, 在简化和整合运营商的核心数据网络的同时, 帮助运营商进行经营分析, 提高运营效率, 使运营商收益最大化。

2 WEB网关系统结构

2.1 WEB网关的系统模块

WEB网关的典型架构如下面的示意图所示:

WEB网关是一个模块化的开放的平台架构。WEB网关软件可以运行于标准的硬件服务器, 包括SUN公司, IBM公司的UNIX服务器, 从而保证了很好的扩展性。

WEB网关核心软件平台, 提供了统一的系统管理, TCP协议栈处理, 业务选择、用户数据库管理和session管理等功能。平台式集中处理提高了网络效率, 同时, 核心软件平台有开放的第三方接口, 很容易集成第三方提供的IP服务。

WEB网关上层是各种业务应用模块。

经营分析系统运行于核心软件平台并独立于各业务模块, 基于用户的访问明细, 可提供丰富的用户行为统计分析。

2.2 WEB网关的高可靠设计

WEB网关运行在运营商的网络中, 承载着大量实时用户访问请求, 通过如下的网络技术来平滑地处理大量并发用户请求:

负载均衡器:采用1+1的备份方式, 两台负载均衡器以主备方式工作, 如果处于工作状态的负载均衡器出现故障, 备用的负责均衡器将接管所有的工作。

管理服务器:采用1+1的备份方式, 两台管理服务器以主备方式工作。在任何一台上可以查看当前的主备状态, 主用的服务器对整个集群有控制权, 在服务器中的动态保存的用户会话状态数据和长期保存的用户个性化数据, 都会在两个服务期间实时同步, 当任何一台故障时, 另一台可以接管集群管理工作而不造成用户会话的中断。

页面适配服务器:采用N+1的备份方式, 服务器负责将请求均匀分配在各台页面适配服务器上, 当任何一台页面适配服务器故障时, 管理服务器会将其从列表中去除, 该服务器的负载将被重新分配在其他活动的页面服务器中。系统支持通过扩容服务器的方式平滑增加WEB网关的处理能力, 容纳更高的并发用户数。

3 手机页面适配技术概览

3.1 手机页面适配流程

WEB网关集群中的组件以及设备浏览器协同工作以提供内容适配服务。无需额外的客户端下载, 仅利用现有浏览器, 手机页面适配就可以为客户提供服务, 内容适配的一般过程如下:

(1) 用户启动手机浏览器。通常, 浏览器启动后显示一个门户页面, 该页面有常用链接及用户输入URL的表单。用户通过内建的浏览器控件输入URL, 然后通过无线网络发送标准HTTP请求。

(2) HTTP请求通过无线网络之后, 被WEB网关集群中运行在手机适配模块的网络代理拦截, 并进行内容适配的请求, 系统会将其识别为适于适配的请求。可以基于来源IP地址、RADIUS属性 (例如MSISDN, APN, SGSN IP等) 对用户进行识别与分组策略管理。也可以对于某些特定的域或者URL禁用服务选择。

可以选择相应的广告模块, 在适配的同时启用广告服务。

(3) 如果检测到HTTP请求需要内容适配服务, 它将会将请求发送到页面内容适配代理 (CAP) 。内容适配请求包含下列信息:请求URL及原始头信息;头信息包含来源及目标身份证明 (IP地址、端口、请求的域) ;头信息包含用户的唯一标识;头信息能够标识用户设备及用户代理 (从手机设备库查询) ;头信息能够唯一标识该请求;头信息表明该请求是否可以接收广告。

3.2 手机页面适配效果说明

手机上访问WEB页面, 经过WEB网关适配后, 可形成手机便于浏览的小页面, 同时访问速度得到了优化与提升, 也缩减了打开页面所需的内存空间, 提高了手机访问的稳定性。适配后的手机页面不需要左右滑动, 仅需上下滑动, 符合手机的阅读习惯, 子页面的划分及图片的压缩处理, 可有效利用手机的内存特点, 增强稳定性及页面打开速度, 适合各种类型的可上网手机, 能覆盖主流的2G/3G手机。

3.3 手机页面适配实现的关键功能

WEB网关通过手机页面适配技术可提供如下的关键功能:

(1) 页面首尾导航栏设置, 可方便地在适配后的子页面中进行切换跳转, 并可内嵌导航页面等扩展功能。

(2) 页面热键设置, 可定义手机键盘的快捷操作方式。

(3) 页面缓存功能, 提升手机用户的访问速度。

(4) 图片适配技术, 动态压缩图片, 方便手机用户浏览, 提升图片下载速度。

(5) 广告插入模块。

(6) 采用Small-Screen Rendering TM (SSR) 技术, 透明地改变网页内容。

小屏幕显示 (SSR) 算法将页面重新格式化为一列, 仅可以通过垂直滚动进行阅读 (某些情况例外) 。如果设备没有足够的内存能显示整个页面, 则网页会被分为尺寸小些的另外带有导航链接的子页面。

可以支持以下格式的输入:HTML, XHTML-MP, XHTML, CSS及WML等页面格式与元素。

支持各种图片的识别压缩与优化, 如GIF87, GI89a, JPEG, BMP, ICO, WBMP和PNG图像的尺寸并将其优化。

支持页面字体大小设置, 支持页面标题设置, 页面框架识别, 页面表格适配, Java Script, Cookie处理等。

摘要：无线互联业务的WEB网关是一个能解决用户用手机直接访问互联网所面临的各种主要障碍的节点。作为一个高度集成的能提供多种IP服务的移动数据业务提供和管理平台, 它能对用户访问互联网的WEB流量提供加速、适配等多种服务能力, 并提供详细的用户移动互联网行为数据, 激发相当多手机用户的访问互联网需求, 形成长期、稳定的数据业务量。通过在网络侧引入“WEB网关”, 面向所有通过移动设备接入移动互联网的用户提供浏览类业务的内容加速、内容适配等功能, 以提高手机终端用户的网页浏览体验。

关键词：移动互联网,手机页面适配,移动WEB网关

移动手机Web 篇2

解决移动终端Web页面的自适应显示问题有3种基本方法, 即客户端的自适应、中间件或代理技术、服务器端的自适应。例如, 参考文献[1]提到的小屏幕设备浏览器是较为典型的客户端自适应技术。参考文献[2]提出了一个自动代理端自适应系统, 它使用机器学习和启发式方法对标准网页进行自适应调整。服务器端自适应指自适应引擎在服务器上, 处理移动设备的自适应时, 网页开发人员可以进行更多的控制[3], 能克服移动设备处理能力的不足, 获得更好的自适应效果。在国内, 参考文献[4]详细论述了移动终端Web页面显示中的重组技术;参考文献[5]则提出移动终端Web页面的分块处理策略。参考文献[6]从构建网站时网页开发的角度讨论网页的自动生成或自适应显示技术, 对移动终端Web页面的显示处理有借鉴意义。但这些都没有考虑移动Web用户体验至上的准则。为了对移动终端Web作自适应显示处理并满足用户个性化需求, 本文提出在服务器端构建Web页面优化处理系统。

1 系统概述

1.1 问题背景

使用移动终端访问Web的问题, 除设备及网络等影响响应和下载速度外, 主要包括页面外观 (如结构、布局和使用的项) 以及链接导航等与电脑网页不同, 这其实是设计问题, 一般由下列因素造成:

(1) 网站移动版本问题。对大多数网站来说, 专门制作的移动版本有页面结构不同、页面上项不同。为查找内容, 加长滚动条和导航, 通过多层级寻找内容项和链接, 造成用户混乱, 有时移动版与标准版的更新也不一致。

(2) 自适应或代码转换问题。经常发现移动设备网页是自适应或代码转换后的, 或浏览器自动调整了, 造成混乱的布局、内容和过多的导航。偶尔地, 网页内容也被设计者想当然地改变了。

1.2 系统需求

移动互联网问题虽多, 但前景光明。在移动终端上浏览时, 通常希望网页的内容和结构类似于桌面电脑。由此, 分析得出以下需求:

(1) 确保相似的页面结构分发给所有类型的移动终端设备。类似的页面结构和用户熟悉的导航路径易于导航查找感兴趣的内容项。

(2) 确保在所有设备上网页显示项及其位置的一致性。共同项或主要项在同一位置可以避免用户交换使用不同类型设备时产生混乱。

(3) 页面显示最少项和减少导航。仅显示用户要求的内容, 将减少页面大小, 从而减少滚屏和导航, 便于更快地找到感兴趣的内容。

(4) 支持用户在多个不同类型设备上的访问。用户有不同的设备及要求, 基于设备和需求选择显示的项, 将提高Web浏览的体验。

1.3 提出的系统方案

为满足系统需求, 本文提出一个服务器端的自适应系统, 通过设置页面上项的优先级对Web页面作自适应调整。它不改变整个页面结构, 但允许删除一些项。在服务器端处理自适应, 基于以下考虑:

(1) 对移动终端的自适应是自动完成的, 适合任何设备不指定浏览器。移动终端开始时不下载整个页面, 减少了数据传输;自适应不在本地处理, 减少了显示时间, 节省CPU时间, 并延长电池时间。

(2) 不需要在设备上安装专用浏览器, 也不需要代理服务器, 用户不必配置设备到代理的连接。

(3) 开发人员能够控制自适应, 因为网站页面和优化引擎系统部署在同一服务器上。

优先级自适应方法允许用户定制网页项的优先级, 即确定最终显示在设备上的网页项。用户为每个项设定优先级后 (1为最高优先级, 数大优先级低) , 低的优先级项被删去。什么设备, 显示什么, 按什么顺序显示, 用户以此决定项优先级, 并可以修改其偏好 (首选项) 。对有些网站, 开发人员设定默认优先级, 首次使用时提供给用户, 用户可以自行再定制。

1.4 系统简介

设置优先级是为了维护整个布局即网页项的父子 (层次或嵌套) 关系看起来与原始页相同, 保存页面整个外观。系统维护所有项及其层次关系, 并允许用户设定在不同设备上显示项的数目和顺序。

优先级系统的目标是按照每个项的优先级显示页面。用户能够给每个项设定一个优先级值。低优先级的项被移去, 留下的项重新排序以形成最后的页面。系统流程框图如图1所示。

(1) 检测设备和用户。页面项的优先级处理取决于用户的偏好以及用于访问页面的移动终端设备。优先级引擎应能够识别用户、设备以及请求的页面。

(2) 加载首选项 (偏好) 。对于一个页面的每个浏览器会话, 依据请求该页的设备类型, 优先级引擎将加载用户的首选项。用户分为两类:非注册用户/匿名用户和注册用户/已知的用户。匿名用户自动获取默认首选项, 注册用户依据他们的特定偏好获得优先权。

(3) 优先级处理和显示项目。依据用户的偏好, 优先级引擎将重排序页面上的项。为此, 优先级引擎需要分配偏好值给可处理的项;移去那些没有偏好值或偏好值大于剪切值的项;排序和显示留下来的项。通过增加链接“更多…”, 以访问移去的页面项。

2 系统实现

服务器端页面优化自适应技术依据用户首选项进行优先级处理, 并针对设备自适应调整。不同设备访问具有唯一版本的网站时, 网站的开发和维护也只需一个版本。

该实现将分发给移动设备的页面内容或项作最小化处理, 暂不考虑如图片或视频媒体等其他自适应。优先级引擎主要实现以下功能: (1) 依据优先级对项进行重新排序; (2) 依据优先级来分发和显示感兴趣的内容; (3) 移去低优先级项, 插入“更多…”链接; (4) 依据页面请求的设备, 为用户提供默认首选项。优先级引擎保存页面的整体结构, 处理后页面项的父子关系不变。系统优化后, 再经客户浏览器的自适应处理, 整体外观也许会有微小的改变。

2.1 识别页面元素

2005年以后, 网页布局由表格 (table标签) 转变为由层 (div标签) 承担, 因此系统处理以div元素为结构布局的 (X) HTML页面。页面包含的程序脚本如Java Script等暂时先不予考虑。一个基本的HTML页面以div标签为结构, 组成页面上的项, 并可以嵌套, 使用CSS样式控制布局的表现, 以此实现、测试和讨论优先级引擎。

2.2 优先级系统引擎

引擎基于ASP.NET开发, 采用混合脚本语言编程, 操作XSLT更新、重排和显示页面。图2所示为优先级引擎框图。

2.3 存储和管理数据

用户的偏好需要永久存储, 并允许优先级引擎以可靠的机制快速查询和访问。另外, 需要存储用户ID和设备ID, 浏览会话时会用到。用户偏好可能存储在cookies、会话变量或者数据库中。选择使用关系数据库, 存储和管理用户的偏好 (首选项) , 这个方法保证了偏好可以永久存储, 并提供了可靠和灵活的存储机制。对大量的用户而言, 管理数据和增加记录等, 数据库提供了高性能和可伸缩性。数据库修改数据很灵活, 管理对用户偏好的修改很容易。而且, 存储用户的偏好 (首选项) 在数据库中, 当用户使用任何类型的设备访问页面时, 都能够获取他们的偏好, 不需要为新的设备类型对偏好进行重新设置。图3所示为系统使用的6个基表。

2.4 设计XSLT样式表

为重组页面, 需要排序和转换操作, 使用XSLT转换规则, 生成最终优先级处理后的页面版本。应用XML的XSLT样式表技术, 修改XML文档的结构和对文档作格式转换。系统使用的样式表代码如下。

2.5 优先级引擎的具体实现

(1) 用户登录。有两类用户:访客和注册用户。注册用户有个性化首选项存储在数据库中;而访客用户使用默认首选项。它要求用户输入用户名和密码, 验证有效, 则从数据库中查找user Id。user Id存储在会话变量中, 在整个用户的浏览会话过程中使用。

(2) 识别用户、设备和页面处理。识别用户后, user Id被传递给会话变量。引擎检查会话变量是否存在该user Id。如果没有, 系统分配用户为缺省user Id, 值设为1。识别设备类型时, 系统检查来自设备的用户代理字符串。系统从传入的URL变量, 确定被优先级处理的页面。如果有URL变量, 系统使用该变量的值作为页面名称;否则, 系统分配”home”作为页面名称。系统在会话变量中存储user Id和device Type, 以在整个浏览会话中使用。

(3) 从数据库中查询用户的偏好。系统识别用户、设备和页面后, 从数据库中查询优先的页面项、用户的偏好和剪切值。使用页面名称, 在数据库中查询页面优先级项的element IDs, 并将它们存储在数组page Item中。然后, 使用user Id、device Type和page Name查询用户对该页的偏好 (即element IDs和ranks) , 并将它们存储在另一个数组user Preference中。

(4) 更新页面项的偏好。当对Web页项处理时, 系统首先要识别出页面中的div块。选择使用XML的DOM解析器处理数据。

(1) 装载基本页。系统装载页面, 生成一个HTML的DOM节点树。一个Web页上所有可视内容和可优先级设置的项都是

元素的子节点。

根元素和元素为不可优先级设置的项, 直接复制在最终页面上。所以, 仅处理从

元素开始的节点树。

(2) 分配偏好值。基本页装载后, 系统分配偏好值给可优先级设置的div。为此, 系统遍历节点树, 检查每个div元素。首先, 检查每个div是否为可优先级设置的项。对每个可处理的div, 检查它是否为数组page Item中可设置的项, 是否有数组user Preferences中的偏好。如果div的id属性在page Item数组中, 则为该div创建一个新的属性rank, 然后读取user Preferences数组, 给rank属性赋值;否则, 如果div的id属性不在user Preferences数组中, 则给rank属性一个缺省偏好值, 缺省低优先级偏好值应等于或大于页面上所有项的总数和。

(3) 删除低优先级项, 增加“更多…”链接。可优先级设置的项被分配偏好值以后, 接下来删除低优先级项。系统遍历分配了偏好值的节点树, 删除rank属性大于剪切值的所有节点。然后, 创建一个新的div元素, 放置超链接“更多…”。

(5) 排序和显示优先级处理后的页面。删除低优先级项后, 系统重构页面, 按照它们的优先级重新排序页面上的项, 并转换成为最终的页面。使用XSLT处理器重新排序和转换页面。低优先级项删除后的新的节点树通过应用XSLT样式表的规则, 基于rank属性以升序排序。按层次深度对每层div进行排序, 嵌套的div也在双亲节点中排序, 有最高优先级 (值为1) 的首先被显示。

3 系统性能测试

系统性能测试时, 分别对用户数、页面项数、用户偏好数等主要参数作不同的设置。系统运行得到最终页面的时间几乎都在20 ms以内, 表明系统性能优良。

(1) 用户数对性能的影响。采用不同的数据行数测试, 最大的1 000K行大约是20万用户, 每个用户有5个偏好的数据库的状态。系统测试以一个页面、有50个div项、偏好剪切值设为5的情形, 运行系统15次的测试结果如表1所示。

(ms)

(2) 页面项数对性能的影响。数据库中数据行为1 000 K, 每页偏好数设为5, 运行测试15次的结果如表2所示。

(ms)

(3) 用户偏好数对性能的影响。数据库中数据行为1 000 K, 页面有50项, 剪切值随偏好数而变化, 运行测试15次的结果如表3所示。

(ms)

以div标签为布局的页面是优化引擎工作的基础, 从而实现基于用户偏好和移动终端类型的页面自适应。研究结果表明, 在服务器端系统优化处理的页面内容在不同类型的移动终端上能提供一致的和良好的用户体验。接下来的工作是设计和实现用户接口, 完成用户对个性化偏好的定制。更大的挑战是如何对页面上其他内容 (如图片等媒体信息) 依据用户偏好和移动终端的设备能力, 实施基于优先级的自适应调整, 这也是未来的工作方向。

摘要：移动终端的多样性及用户的个性化要求是传统Web页面遇到的挑战。为获得与电脑相一致的浏览效果, 提出一个服务器端的Web页面自适应方法, 通过优化系统处理生成自适应页面。该方法通过用户为设备设置Web页面上项的优先级, 系统对页面项进行重新排序、显示和删除处理。测试结果表明, 系统及自适应页面具有可用性。

关键词：移动终端,Web页面,自适应显示,优化处理,优先级

参考文献

[1]AHMADI H, KONG J.User-centric adaptation of Web information for small screens[J].Journal of Visual Languages and Computing, 2012, 23 (1) , 13-28.

[2]KULKARNI C E, KLEMMER S R.Automatically adapting Web pages toheterogeneous devices[C].Vancouver, BC, Canada:Proc of the 2011 Annual Conference Extended Abstracts on Human Factors in Computing Systems, 2011:115-129.

[3]LAAKKO T.Context-aware Web content adaptation for mobile user agents[C].Evolution of the Web in Artificial Intelligence Environments, 130 ed., Vol.130, Springer Berlin/Heidelberg, 2008:69-99.

[4]史晶, 吴庆波, 杨沙洲.面向移动终端的Web页面重组技术综述[J].计算机应用研究, 2011, 28 (12) :4405-4408.

[5]谈冉, 熊雄.基于移动终端的高效显示策略研究[J].计算机应用研究, 2008, 25 (2) :584-586.

基于HTML5的移动Web技术 篇3

随着智能机的出现, 我国网民接入互联网的方式发生了翻天覆地的变化。7月17日, 中国互联网络信息中心 (CNNIC) 发布了第32次《中国互联网络发展状况统计报告》[1]。报告显示, 截至2013年6月底, 我国网民数量达到5.91亿, 互联网普及率为44.1%, 较2012年底提升2%。与此同时, 我国手机网民数量达4.64亿, 较2012年底增加4379万人, 网民中使用手机上网的人群占比提升至78.5%。3G的普及、无线网络的发展和手机应用的创新促成了我国手机网民数量的快速提升, 手机成为我国最大的移动终端。由于手机移动终端屏幕较小、运行能力有限, 传统的网页并不适合设备直接访问。随着HTML5的提出, 其跨平台的特性为移动Web开发提供了广阔的前景。

1 HTML5介绍

HTML5超文本描述语言是下一代HTML的标准。HTML5有两大特点:首先强化了Web网页的表现能力, 其次追加了本地数据库等相关功能。所谓的HTML5实际上是指包括HTML、CSS和JavaScript在内的一套技术组合, 目前支持HTML5的主流浏览器有Google Chrome、Firefox、Internet Explorer 9和10等。

2 HTML5新特性

2.1 视频、音频

当我们浏览网页时或多或少都遇到过这样的问题, 比如打开不同的播放器需要安装不同的插件, 甚至更换浏览器后同样也需要安装插件。现在Web处于严重依赖插件的时代, 听歌、看视频、购物等都要依赖插件, 在不便的同时还存在着许多安全隐患。HTML5新增的视频

目前对于移动终端而言, HTML5的音频、视频功能应用是有限的。苹果的iPhone手机支持

2.2 表单

现在流行的移动设备大多采用触摸方式进行输入, 并且有一个虚拟的触摸键盘。由于移动设备本身屏幕较小, 按键大小和布局对用户的影响非常大, 过大或过小都会降低用户体验感。如果能做到输入不同的内容显示不同的键盘, 那么在提高用户体验的同时就提高了输入效率[3], HTML5的表单元素很好地解决了这一问题。不同元素与键盘的对应关系如表1所示。

表单元素中除了上面几个新增元素外, 还有Date pickers week、time、color等元素。HTML5中的表单组件是对HTML4表单的扩展, 增加了内置表单验证、输入框占位符、外部表单关联等[4], 避免了采用HTML4中的冗余代码验证和样式控制, 为网页开发带来了便捷。例如:就定义了一个遵循邮件地址格式的输入框, 在输入地址时系统会自动辨别格式是否正确, 若不正确不允许提交。以前这些相关验证都需要很复杂的代码才能实现, 现在只需几个简单的语句就能轻松完成。

2.3 画布

目前要在网页上绘图几乎不可能, 就连最基本的图形都很难实现。HTML5引入的Canvas绘画功能, 为开发人员提供了动态产出和图形渲染功能。开发人员不再依赖Flash来进行动画绘制, 利用Canvas就可以直接在网页上高效快速地绘制图形图表, 从而减少网络传输, 提高了效率。Canvas画布是一个矩形区域, 可以在其中随意画图, 也可以加载照片。Canvas元素本身没有绘画能力, 绘画工作必须在JavaScript内部才能完成。

2.4 离线应用

互联网拉近了彼此的距离, 让世界变成了地球村, 网络带给我们的方便不言而喻。众所周知, Web的应用非常强大, 但是它存在一个致命的缺陷就是严重依赖网络, 没有网络的Web就如离开水的鱼儿活不下去。虽然现在网络无处不在, 但是网络信号的好坏却各不相同。我们常常遇到掉线的情况, 很多时候掉线会带来严重的后果, 那么有什么办法能解决这个难题呢?HTML5给我们带来了希望。HTML5强大的功能就是离线应用, 将应用数据缓存到本地浏览器中, 掉线时一样可以浏览网页。

其实, 离线Web应用就是一个URL列[5], 列表中的URL可以指向HTML、CSS、JavaScript文件、图片或者其它资源, 该列表被称为Manifest File。通过创建Cache Manifest文件, 可以轻松创建Web应用的离线版本。当使用离线Web时, 会引入这一清单, 浏览器会从清单文件中读取相应的URL信息, 并下载相应的资源将其缓存到本地。因此, 在离线状态下访问Web应用时浏览器就会自动切换到从本地直接读取这些资源, 从而能够脱离网络使用。

2.5 标签和样式

移动终端因为受到屏幕尺寸和分辨率的限制, 无法将普通页面全屏显示在一个页面上, 就算通过屏幕缩放技术[6]来访问传统的网页也很难得到最佳体验。不过HTML5已经考虑到这点, 在网页头部加上就可以了。它根据终端屏幕尺寸来自动调整网页大小, 从而可以适应不同屏幕大小的移动终端设备。

3 移动Web设计原则

无论是手机还是平板电脑都不同于PC机, 这些设备屏幕较小、运行能力低, 若直接移植大屏幕界面的设计方案, 会给用户带来不便。为了提高界面设计效果和用户体验, 在设计界面时可以遵循以下原则。

3.1 简洁明了

我们浏览网页时往往一下子就被那些漂亮的图片所吸引, 这是因为图片对眼睛的吸引远远大于文字对眼睛的吸引。然而对于小屏幕而言, 图片并不是越多越好, 适当的图片会给人一种欣喜若狂的感觉, 起到画龙点睛的作用, 过多的图片会让人觉得眼花缭乱, 产生视觉疲劳, 过多的图片还会让人觉得信息杂乱无章, 没有重点。针对终端界面, 应该把一些图片、图形的数量减少, 隐藏不必要的信息。用户在浏览网页时不是“闲逛”, 而是寻找一些有用的信息, 因此, 要把关键信息布局在中间从而突出主题, 让用户能快速找到想要的信息。

一般情况下, 字号使用9~12号字体为宜。字体尽量选用罗马字体或者宋体这些好识别的字体[7]。由于字体过小, 我们可以利用颜色来突出重点或标题, 但是不宜过多, 同一页面的色彩不要超出3种[8]。

3.2 可订制性

手持移动终端本身是一个嵌入式系统, 根据市场的定位和用途的不同就会有不同的方案。有的对图形功能要求严格, 有的对定位功能要求精确。因此GUI必须要模块化设计, 可订制是它的基本要求。

3.3 以用户为中心

随着互联网的发展, 以用户为中心以人为本的方式越来越受到关注。用户体验对于一个网站而言比任何商品都重要, 具有良好用户体验的网页才能和客户建立良好关系。如果用户浏览一个网页时停留不到5s, 这个网站基本上属于吸引不了用户的网站。作为开发者首先要了解用户的需要, 换位思考一下用户需要什么, 在设计页面时要多站在用户的角度思考问题, 以人为本, 以用户为中心, 这样设计出来的页面才会让用户流连忘返。

4 结语

HTML5被越来越多的厂商接受, 它是未来网页制作的主要技术之一。它的出现, 减少了网页开发代码, 提高了工作效率, 但是, 其还存在着一些缺陷, 需要不断改善。相信HTML5未来会给我们带来更多的惊喜。

参考文献

[1]中国互联网发展状况统计报告[EB/OL].[2013-07-26].http://news.3snews.net/2013/lbs_0726/25820.html.

[2]崔玉梅.HTML5与移动平台[J].电脑编程技巧与维护, 2012 (18) :66-67.

[3]邢晓鹏.HTML5核心技术研究与价值分析[J].价值工程, 2011, 30 (22) :157-158.

[4]宋昭寿, 胡忠旭, 漆丽娟.HTML5网页设计探析[J].红河学院学报, 2012 (2) .

[5]严琦, 朱治国.HTML5对移动应用的影响[J].信息通信技术, 2012 (6) :64-68.

[6]钱海军.基于HTML5移动Web页面开发技术研究[J].电脑与信息技术, 2013 (1) .

[7]高亮, 隆梦琪.手持移动终端的小屏幕界面设计探究[J].硅谷, 2013 (1) .

移动手机Web 篇4

结合已有的单词记忆系统软件的功能与应用, 考虑到没有一个较好的平台来呈现与训练记忆相关植物信息, 本系统设计并完成了一个基于动态Ajax技术的在线植物辨识训练平台, 方便专业及非专业人士随时进行在线植物辨识认知训练。其中植物信息数据库统计由线下完成, 通过客户端可以在线实时进行植物认知训练。

2 植物在线辨识系统设计

本系统采用My SQL数据库 , HTML5[1]、CSS3、Java Script作为前端开发语言, Java作为后端开发语言。采用MVC开发框架并结合Ajax技术[2]实现上述基本功能。

2.1 系统构成

该系统平台主要由两部分组成: 植物查询与植物辨识训练。植物查询是基于构建植物信息数据库的基础上实现的一个模糊查询功能, 用户通过输入关键字的形式搜索相关植物信息; 植物辨识训练是基于Ajax动态更新技术基础实现的在线实时植 物认知训 练系统 , 界面每次 出现4幅相关植 物图片, 用户通过点击图片进行选择, 系统进行判断用户是否选择正确。

2.2 建立植物信息数据库

本平台采 用My SQL数据库进 行数据存 储 , 建立植物 信息表:

plants(id,name,pname,content);

其中id代表植物唯一标识, 为主键 ; name代表植物 名称, 非空; pname代表与植物对应存储图片名称; content代表植物相关信息描述, 用于介绍相关植物。

2.3 植物辨识训练系统

系统采用基于J2EE技术的B/S体系结构[3], 通过MVC三层模式把用户表示和数据库代码分开。用户通过移动终端对应用进行访问, 在线实时进行植物信息模糊查询与植物辨识训练。体系结构[4]如图1所示。

3 系统实现

应用已有移动Web网站制作知识, 使用JSP技术, 结合Ajax技术基础实现植物搜索与植物辨识功能。

3.1 植物搜索

本模块实现植物信息的模糊查询; 本页面主要包含一个搜索框、一个搜索按钮和一个结果展示列表。用户通过在搜索栏输入关键字并点击搜索按钮的方式进行查询。关键代码如下所示:

上述为点击搜索按钮后触发的Java Script代码, xml Http.open (" POST" ," search?name=" + name) 语句调用了Java语言实现的植物信息数据库查询功能Servlet, name代表搜索框中输入的关键词。之后通过回调函数check Userid Callback() 接收搜索结果并显示在界面上。其中xml Http.response Text;用来获取搜索返回的结果。

3.2 植物辨识训练

3.2.1 模块介绍

本模块实现植物辨识训练功能。界面如图2所示。

界面中包含一个植物名称标签、4张图片、选择结果提示标签以及一个确认按钮。用户通过界面提示信息, 选择相应的图片, 系统将根据用户选择进行反馈, 输出结果如图3、图4所示。分别代表正确与错误情况 。选择完毕可以点击NEXT按钮继续植物辨识训练。植物辨识训练过程如图5所示。

3.2.2 功能实现

(1) 系统使用浏览器Cookie记录当前训练进度。

(2) 系统通过上方Label记录植物标识 , 并随机生成1-4之间的数字number, 从数据库中取出4张图片, 将其中正确的一张放 至上述number代表的位 置上 , 剩余3张图随意 摆放。关键代码如下:

其中request.get Parameter (" userid") 获取用户训练进度参数 ; 之后使用SELECT name,id,pname FROM plants WHEREid>=" + num + " ORDER BY id asc limit 0,4;SQL语句查询当前训练进度植物之后的4个连续编号植物的名称、id与对应图片名称; 最后使用out.print (news); 将查询结果返回前端界面进行处理。

这里部分代码为Ajax异步传输回调函数check Userid Callback() 中的部分关键代码 , 其中var text = xml Http.response Text获取后端查询数据; t = text.split (';') 使用正则表达式分割获得的查询结果; var rand = Get Random Num (1,4) 获取1-4随机数; 其余代码完成显示图片等功能。

(3) 用户单击选择图片 , 系统给出反馈。关键代码如下 :

程序通过界面Label属性与用户点击图片属性判断用户是否选择正确并显示结果。

(4) 当用户回答完毕 , 点击界面NEXT按钮时 , 将调用使用Java语言实现 的选择下 一部分4张图片功 能的servlet,通过Ajax异步传输提交Cookie序号参数, 并通过回调函数接收接下来4张图片的名称。其中第1张图片代表要辨识的植物, 其余3张代表相似图片, 起模糊正确答案作用。使得用户可以继续答题过程。

3.3 应用调试

系统使用My-eclipse开发平台进行编写, Tomcat作为服务器, 分别使用Chrome、Safari、百度浏览器、360浏览器进行测试, 应用效果反映良好, 基本可以满足上述应用需求。

3.4 系统发布

系统使用新浪云作为最终发布平台, 通过购买云豆获取新浪云使用权限, 使用My-eclipse导出系统War包, 并在新浪云上导入相关植物信息数据库, 进行用户体验测试, 效果良好。

4 结语

移动手机Web 篇5

2007年,Tim Berners-Lee提出了Web的三个发展方向,即“Web可以通过各种网络和不同设备来访问”,“Web应用将会在人类社会变得更加普及”[1]。随着今日网络环境的变化,如2009年1月3G牌照在中国发放[2],以及出售移动应用的在线软件商店模式流行,使得这种预见正变成现实。因此在移动平台上部署Web应用成为一种趋势。

当前移动平台上的Web信息交互方式主要有两种,一种是利用手机浏览器,如国内的优视动景推出的UCWEB系列;另一种是利用Web service技术。出于安全性考虑,浏览器一般不能操作手机的底层数据,比如用户的通信录、地理位置等信息。因此限制了基于浏览器的Web应用的社交特性和使用范围。使用Web Service技术是实现交互的较好方案,具有客户端访问权限大、Web服务功能单一、效率高等优势。本文在后者基础上提出了面向移动平台的Web信息交互模型。该模型可以快捷、高效地完成Web服务器与移动设备的交互,如智能手机、PDA、laptop等。

模型总体上可分为三层:网络通信层、网络服务代理层和信息表现层,如图1所示。分层设计具有层与层之间耦合度低、各层逻辑可复用等优势。

1 网络通信层

1.1 主要作用

该层主要实现智能设备与服务提供商之间的通信,即实现了HTTP协议在移动设备上的封装,形成一个可供模型上层使用的通信模块。

1.2 该层实现所面对的问题及解决方案

由于移动设备具有低带宽、社交网络内容具有隐私性等特点,该层所面对的问题主要有以下三个方面:

1.2.1 网络数据传输量的大小不一

针对简单的文本类型数据,如操作指令、评论内容等,使用HTTP中的GET或者POST方式直接封装成HTTP协议数据包传输。

针对复杂的、大量的流媒体类型数据,如图片、音频、视频等,使用二进制流的方式传输。

1.2.2 通信方式各异

网络通信有异步、同步两种方式,模型采用了委托模式实现了异步传输回调机制。它的优势在于,允许开发者通过委托类自定义当网络数据传输成功、失败、到达等行为发生时,移动应用执行的特定回调函数,而不用一直等待传输的完成,比同步传输更加高效和灵活,可以使用户有更好的使用体验。但某些情况下同步传输也是需要的,比如得到用户授权的过程就比较适合发起同步请求,待用户授权后才开始继续下面的请求。

1.2.3 网络分发内容具有隐私性

在使用API的过程中,不可避免的要遇到授权问题,常用的授权手段主要有两种方式:一是基于用户名和密码的体系,这种方式需要用户向第三方开发者暴露用户名和密码,安全性不高;另外一种是基于OAUTH[3]协议的开放授权认证体系,该协议已经获得各大互联网公司的普便认可和实现,可见其安全性还是有保证的。本文结合当前Web平台授权方式的使用习惯以及未来发展趋势,在模型中仅引入了基于OAUTH协议的授权方式。实现描述请参见1.3节。

1.3 认证模块

OAUTH认证实现的过程就是客户端和OAUTH服务提供商交互的过程,本节主要分析了OAUTH的关键URL以及认证流程。

1.3.1 OAUTH认证中的三个关键URL

1) 获取未经用户授权的TOKEN(令牌)

该URL的作用是获取用户授权TOKEN,同样也使得第三方应用程序必须接受服务提供商的验证,确保应用程序的安全性。如https://www.google.com/accounts/OAuthGetRequestToken。

2) 获取用户授权的TOKEN

服务商提供登录页面供用户授权,如https://www.google.com/accounts/OAuthAuthorizeToken。

3) 以用户授权TOKEN换取ACCESS TOKEN

该ACCESS TOKEN是第三方应用程序访问的通行证,可用来操作用户的受保护资源,一般情况下,该TOKEN是一个用户对应一个,可以保存供下次使用。如https://www.google.com/accounts/OAuthGetAccessToken。

1.3.2 OAUTH认证的流程图

1.4 实 现

1.4.1 OFHttpClient类

完成的具体的底层网络通信功能。类图如图3所示。

1.4.2 OFHttpClientDelegate接口

定义了异步网络通信的回调函数集合,网络传输完成后,实现该接口的类进行数据存储以及异常处理。

1.4.3 OFHttpClient类

实现客户端OAUTH认证的功能模块。描述详见1.3节。

1.5 该层实现流程图

2 网络服务代理层

2.1 主要作用

将远程服务本地化,即通过代理类将远程资源API调用转换为本地函数调用。该层的实现涉及到高效的服务器资源设计以及客户端代理的实现。

2.2 开放服务器端的资源

模型没有使用基于SOAP协议的Web service,而是采取了符合REST[4]风格的、面向资源的Web服务架构。REST风格由Roy T. Fielding定义,它强调组件之间要有一个统一的接口[4];在面向资源的架构中,请求的内容信息包含在URI中。可以这样简单比喻这两者的结合,前者提供方法(GET、POST、PUT、DELETE等标准的HTTP方法),后者提供方法的参数。

2.2.1 REST风格的特征

在文献[4]中已经很全面地说明了REST风格的软件框架,因此本文并不赘述REST的全部风格,而是分析模型所依赖的部分REST风格的特征:

1) 服务器响应的请求方法不是像“getSomeObjects”一样的自定义方法,而是标准的、在HTTP协议中良好定义的方法,如GET、PUT等。由于当前网络服务提供的多样性,这样的方法定义就简化了客户端的实现,使得通用客户端成为可能。这也是简化模型第一层实现的基础——仅需实现GET、PUT等方法。

2) 有效的、简单的缓存实现机制,这是HTTP协议本身支持的,不再需要其他额外的、甚至有时候是复杂的配置,比如SOAP协议需要附加的机制来实现缓存。无线网络的主要弊端就是带宽小,尽管随着3G的应用,问题得到了进一步的缓解,但是带宽无论什么时候都是宝贵的资源,缓存机制的引入对于移动设备的应用可说是必须的。

3) REST方法的返回值都是标准化的、独立于平台的,他们由HTTP协议中定义的响应码,以及请求内容的XML、JSON表示组成。同样的原因——服务以及服务提供商的多样性,使得标准化的响应表示更有利于服务之间的连接,模型第三层所推荐的服务应用之一——MASHUP[5]正是依赖这一特性,请参见3.1节描述。

2.2.2 面向资源的框架

该框架是基于REST风格衍生出来的一种设计理念,它依赖于HTTP设计的初衷——HTTP方法操作的都是资源,Web上的每样东西都需要用URI来描述。综合各种对“资源”的定义,本文认为,资源就是服务想要对外提供的东西,可以是一个数据库表、一个文档、一个action甚至是一个算法的最后结果。

在面向资源的框架中,最重要的部分在于设计合理的、符合REST接口类型的资源表示。它遵循如下的设计原则:

1) 所有的服务都是以资源的方式暴露的,包括像上传一张图片这样的动作行为。

2) 各种资源之间尽可能地做到松散耦合。

例如,针对一个图片分享服务的资源设计如表1所示。

2.3 服务的客户端代理实现数据结构

因特网上服务具有多样化的特点,同样客户端设备也具有多样化的特点,因此没有一个适用于各种平台的特定服务API的实现。但是,本文结合在各种主要手机平台(IPHONE、SYMBIAN、Windows Mobile等)上实现FLICKR客户端的经验,整理出一套较为通用的实现流程,可以减轻用户构造客户端的负担。

2.3.1 CONTEXT类

该类的主要作用是在客户端上记录远程服务分配给移动应用的上下文基本信息,比如用于针对用户访问授权用的KEY、SECRET、授权后获得TOKEN以及该服务提供的所有API的入口地址(URI)等。这相当于该移动应用在服务提供商的注册信息。

2.3.2 REQUEST类

该类是模型实现的HTTP通信子层的实例,用来完成真正的URI请求。针对两种类型的数据传输,模型提供了不同的方法实现:

1) 文本类型的GET、POST、PUT、DELETE方法,方法原型如下所示:

performMethod:(NSString*)strMethodName methodType:(NSUInteger)iType withArgument:(CInArg)objArgument{}

2) 流媒体类型的POST方法,该方法从上传的媒体数据源创建一个输入流(InputStream),然后设置HTTP协议的Head部分,比如将“Content-Type”设置为“image/jpg”或者“binary”等,再将该输入流设置为HTTP协议的Body部分,最后发起异步传输请求。

2.3.3 CONTEXT类以及REQUEST类交互的数据结构

2.3.4 XMLParser、JSONParser类

用于XML文件或者JSON文件的构建、解析,是该模型的主要辅助类。由于该类用途广泛且有很多的开源实现,因此本文不再赘述。

2.3.5 附加资源

由服务提供商的说明文档提供,可以使用配置文件引入,无需特定数据结构。

1) API的endpoints——即特定服务API的URI;

2) 以及服务提供商确定的数据响应格式,常用的有XML和JSON两种类型。

2.4 实现的流程图

2.5 实现的困难和解决方案

2.5.1 服务器响应异步请求

一般情况下,异步请求操作都会持续较长时间,且如果客户端的数量较多,比如千万级,并都保持连接,那会消耗掉所有的服务器资源。模型中采纳了SUN公司的Cloud API工作组提出的一种符合REST的解决方案,该方案正在持续改进中且有望成为标准。从总体上考虑,该方案由三部分组成[6]:

1) 为每个异步操作创建对应的HTTP资源类型——状态码资源,它用来表示该操作的完成进度,可以通过向客户端和服务器协商好的URI发送GET请求获得该状态码的资源表示,借此判断操作是否完成;

2) 服务器接收到异步请求后立即向客户端返回HTTP协议的201响应码,表示操作已经开始,同时初始化1)中描述的状态码资源,并将其作为响应的“body”部分;

3) 方案定义了类似“WebHook”的回调机制,一旦操作完成,服务器会通过协商好的回调URI通知客户端。

2.5.2 与传统的基于SOAP协议的Web Service对比

传统的Web Service调用称之为RPC风格;另外一种就是REST风格。后者更适合移动应用程序,原因如下:

1)完成同样的功能,从交互的数据量对比上,REST实现更少,因此,REST实现的数据传输速率就更快。这里有一组对比数据,见表2,完成的任务是,分别使用AMAZON提供的REST和SOAP接口从其服务器上获得所有有关“Harry Potter”的书籍信息。

2) REST仅使用HTTP协议,这样移动平台上的客户端程序的实现复杂度就会降低。这对于移动设备宝贵的CPU资源也是有利的。

综上,从带宽、计算资源等方面考虑REST比SOAP更适于提供针对移动设备的服务。

2.5.3 代理类的动态实现

随着互联网上服务数量的增加,由人工从服务提供商提供的文档转换为本地API调用会带来很大的负担。文献[7]提出来一种动态的、异步的调用Web服务的框架,它的主要原理是定义一整套独立于特定服务的消息机制,开发者使用的是该框架内已定义的消息类型,之后由框架负责将该消息类型转变到针对特定服务的请求。由于SOAP和REST风格的不同,该框架解析特定请求的方式也不同,针对SOAP请求,使用的是WSDL解析器,而对REST请求是从特定的REST请求实例中得到的规则之后,再解析其他类似请求。因此,该框架对REST请求的解析还存在局限性。随着REST优势的显现,也有许多互联网公司提出了针对REST服务的描述语言,即Web应用程序描述语言(WADL),它类似于SOAP使用的WSDL。当前已经有这样的在线服务如:REST Describe[8]。但是,由于WADL只能对以XML格式表示的资源进行描述以及外界质疑WADL本身的必要性,因此WADL还没有得到权威组织的认可,距离标准化还有一段路要走。

3 信息表现层

模型选择MASHUP作为信息表现的方式,组合从模型第二层所获得服务数据。

3.1 移动MASHUP

3.1.1 MASHUP的定义

在wiki上,MASHUP定义为从多个外部数据源组合数据或者服务形成新服务的Web网页或者应用程序。它和OPEN API——本文第二层描述的服务提供方式,具有天生的关联性。

3.1.2 选择MASHUP的意义

1) MASHUP从本质上符合REST规范,这与本文的第二层选择的API服务提供体系结构相符,因此MASHUP具有了REST的优势,适合部署在移动平台上的应用。

2) MASHUP是移动设备自身服务接入Web服务的有效方式,比如GPS信息服务与Google Maps服务的MASHUP。

3.1.3 情景举例

用户A的手机查询Facebook上的好友B的生日信息,以及B在Amazon上购物计划清单信息,便可以在用户A经过销售这些物品的商店时通知他,然后A可以经过网上送货服务转交给B。这个场景完全具有可行性,但是没有哪一个服务商可以独立地做到。而MASHUP正好可以适应这种生活趋势。

3.2 研究现状以及未来的挑战

MASHUP在2007年兴起之后,至今已经发展较为成熟,并且也已经出现了可视化的MASHUP制作工具,如Google Mashup Editor、Yahoo Pipes!等。但是,移动MASHUP尚有许多挑战,如可视化的移动MASHUP工具、语义信息的使用以及社会化挑战等[9]。

4 模型应用举例

模型的一个应用实例是iPhone native应用Thingstodo-opentodo,该应用程序已经在应用商店出售(http://www.appstorehq.com/thingstodo-opentodo-iphone-29366/app/buy?ref=search.appcraver.com)。主要功能是,用户随时地添加日程,设置提醒时间等特性后(如图6所示),通过指定URL(http://65.232.1.70/opentodo/task)以POST方式上传到Web服务器。服务器会在设定的时间到达时通知日程指定的接受用户群,从而完成日程分配。同时,接受用户通过特定的URL(http://65.232.1.70/opentodo/username)以GET方式获得日程,从而完成日程的下载。该应用的后期版本支持了Google日历同步功能,利用Google Calendar API实现了Web服务器和Google服务器的交互,获得约5000份的下载量,充分展现了MASHUP的优势。

5 结 论

模型完成了服务提供者和资源消费者之间的连接,本质上与浏览器有着类似的功能,但有更大的灵活性,更适应于移动设备专一的业务需求,以及未来Web用户对服务的可定制化要求。从国内外各大SNS网站,如Google、Facebook、Flickr等,所提供的手机客户端应用程序来看,其中的设计理念都与本文的模型较为类似。在同一个平台上,实现模型的一、三层之后就很容易复用以前的代码,这会大大减小开发者的工作量,加快应用的开发。

摘要：随着移动时代的来临,Web上的信息交互平台开始由浏览器转向移动客户端。信息的可定制化以及可交互性是移动Web应用所面临的问题,通过对整个Web信息的交互过程进行抽象,提出了三层信息交互模型。第一层实现了移动客户端上的通信模块,向上层提供了标准的HTTP操作接口。第二层调用API与服务器通信,服务器借用RESTFUL API的方式对外提供资源。第三层使用MASHUP方式展现客户端集成的服务。整个模型提供了针对移动平台部署服务、获取服务以及展现服务的快速解决方案。

关键词：移动平台,信息交互,RESTFUL API,移动MASHUP

参考文献

[1]Tim Berners-Lee.The Future of the World Wide Web[R/OL].CSAILDecentralized Information Group:Massachusetts Institute of Technology[2007-03-01].http://dig.csail.mit.edu/2007/03/01-ushouse-future-of-the-web.html.

[2]Zhaoll.国外3G发展的现状与经验[S/OL].科技日报[2009-01-15].http://industry.tech110.net/html/article_385796_1.html.

[3]Mark Atwood.OAuth Core 1.0[S/OL].OAuth community[2007-12-04].http://oauth.net/core/1.0.

[4]Roy Thomas Fielding.Architectural Styles and the Design of Network-based Software Architectures[D].Irvine:University of California,2000.

[5]Wikimedia Foundation Inc.Mashup(web application hybrid)[S/OL].Wikipedia.[2009-03-03].http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid).

[6]Craig McClanahan.PROPOSAL:Handling Asynchronous Operation Re-quests[EB/OL].Sun Microsystems,Inc[2009-06-09].http://kenai.com/projects/suncloudapis/forums/forum/topics/911-PROPOSAL-Han-dling-Asynchronous-Operation-Requests.

[7]Philipp Leitner.Daios-Efficient Dynamic Web Service Invocation[J].IEEE Internet Computing,2009(3):72 80.

[8]Thomas Steiner.RESTDescribe&Compile Documentation[EB/OL].Google,Inc[2007-08-01].

移动手机Web 篇6

1 基于响应式Web系统的设计流程

基于响应式Web的交互系统的设计基本流程为以下三步:第一, 确定需要兼容的设备类型、屏幕尺寸等硬件信息, 以及交互的信息流需求信息等;第二, 根据第一步的硬件需求尺寸制作线框模型, 根据交互信息需求设计功能模块;第三, 进行UI效果设计, 进行交互功能的定义及详细设计;最后, 通过前端程序设计实现。

2 响应式Web的基本原理

基于响应式Web设计 (Responsive Web design) 的理念是, 页面的设计与开发应当根据用户行为以及设备环境 (系统平台、屏幕尺寸、屏幕定向等) 进行相应的响应和调整。具体的实践方式由多方面组成, 包括弹性网格和布局、图片、CSS media query的使用等。无论用户正在使用笔记本还是i Pad, 我们的页面都应该能够自动切换分辨率、图片尺寸及相关脚本功能等, 以适应不同设备;换句话说, 页面应该有能力去自动响应用户的设备环境。这样, 我们就可以不必为不断到来的新设备做专门的版本设计和开发了。简而言之, 我们的Web设计应该做到根据不同设备环境自动响应及调整, 不过, 我们无法像其它工程领域一样使用类似于运动传感器或是机器人技术去感知用户, 响应式Web设计更多需要的是抽象思维。目前, 液态布局、帮助页面重新格式化的media queries和脚本等技术已经开始应用, 但是响应式Web设计不仅仅是关于屏幕分辨率自适应以及自动缩放的图片等等, 它更像是一种对于设计的全新思维模式。

3 响应式Web实现的关键

构建响应式Web的有些关键技术与关键环节, 其中应用最关键的技术有:HTML5技术、CSS3 Media Query技术, 最重要的环节部分为流体布局 (fluid grid) 、流体图片 (liquid image) 、以及媒体查询 (media query) 。

3.1 HTML5与CSS3技术介绍

HTML5是用于取代1999年所制定的HTML4.01和XHTML1.0标准的HTML标准版本, 现在仍处于发展阶段, 但大部分浏览器已经支持某些HTML5技术。HTML5有两大特点:首先, 强化了Web网页的表现性能。其次, 追加了本地数据库等Web应用的功能。广义论及HTML5时, 实际指的是包括HTML、CSS和Java Script在内的一套技术组合。它希望能够减少浏览器对于需要插件的丰富性网络应用服务 (plug-in-based rich internet application, RIA) , 如Adobe Flash、Microsoft Silverlight, 与Oracle Java FX的需求, 并且提供更多能有效增强网络应用的标准集。

CSS即层叠样式表 (Cascading Stylesheet) 。在网页制作时采用CSS技术, 可以有效地对页面的布局、字体、颜色、背景和其它效果实现更加精确的控制。只要对相应的代码做一些简单的修改, 就可以改变同一页面的不同部分, 或者页数不同的网页的外观和格式。CSS3是CSS技术的升级版本, CSS3语言开发是朝着模块化发展的。以前的规范作为一个模块实在是太庞大而且比较复杂, 所以, 把它分解为一些小的模块, 更多新的模块也被加入进来。这些模块包括:盒子模型、列表模块、超链接方式、语言模块、背景和边框、文字特效、多栏布局等。

3.2 流体布局 (fluid grid)

流体布局其实就是在我们实现PC终端的页面基础上, 将一些元素的宽高由原来的固定多少像素 (px) 调整为百分比 (%) 或字体比例 (em) (或布局方面的margin、padding、left、top等以px为单位的值) , 这也是当前实现响应式布局的两种主要实现方法。第一种用百分比 (%) , 就是以该元素的父容器的宽高为100%, 其他元素的宽高相对于其父容器的比例, 只要将具体的像素值相对于他的父容器的一个百分比折算即可。当然这种方法的换算有点复杂, 因为很多相对的宽高折算的百分比系数是带小数的, 所以这时候可能要你有足够的耐心才能实现。下例为一个实现例子代码:

上面代码中通过百分比定义容器的长宽高, 其实还可以采用另外一种使用字号比例 (em) 去实现控制的流体布局方法, 其实方法是跟上面一样的, 只不过我们将%换成了em, 这种方法就是某元素具体的宽高 (px) 在当前基准字号 (font-size) 下折算出多少个em。一个在480分辨率下宽高为64px*64px的元素, 其父容器的字号 (font-size) 为20px, 那么它折算成em为单位就是3.2em*3.2em。当其父容器字号基准根据不同的分辨率变化的时候, 该元素宽高也能根据这个字号基准成比例的缩放, 就能实现响应式变化。

3.3 流体图片 (liquid image)

在目前所了解的很多资料和实际应用中, 在图片处理上, 如果要使图片能根据分辨率来适应, 而且还不失真, 是比较困难的。但其实设计中我们其实不用考虑的那么复杂, 我们要做的只是让图片能根据不同分辨率自适应罢了, 我们不管图片会不会因为被拉伸而失真, 因为真的遇到这样的情况, 我们可以考虑在不同分辨率下使用不同的图片, 这样就简单多了。所以让图片尺寸自适应, 我们只要不给图片设定具体的宽高尺寸, 只要在样式中给该图片一个width:100%, 这样图片就能根据它父容器的尺寸自动调整了。

3.4 媒体查询 (media query)

响应式页面的一个关键是实现媒体查询, 即能够根据不同的分辨率去调整一些不同的样式。通过这样的媒体查询结构, 我们可以设定在不同分辨率下选用不同的样式来调整响应式页面。像前面第二点流体布局上, 我们使用百分比或字号比例去实现流体布局的时候, 第一种方法是可以不用媒体查询直接实现流体布局的, 就是元素的宽高能自适应不同分辨率屏幕。但第二种方法用字号比例 (em) 去实现流体布局的时候, 我们就必须要结合媒体查询了, 因为我们的字号比例是根据基准字号来实现的, 就是说在基准字号一定的情况下, 该元素的大小就是固定的, 而我们要实现该元素尺寸自适应, 就只能通过调整基准字号来实现了。

通过媒体查询, 我们可以让在基准字号font-size在不同分辨率下不一样, 这样其子元素相对于该字号的比例em算出来的像素px就不一样了, 这样就能实现响应式了。所以我们兼容不同的分辨率的时候, 可以先在某个分辨率下, 实现完美的重构, 然后将所有元素具体的尺寸 (px) 折算为em (根据父容器的fontsize) , 然后再通过媒体查询, 调整不同分辨率下的基准字号font-size就能实现具体的响应式了。在具体的项目过程中, 采用媒体查询主要是调整不同分辨率下的基准字号的大小, 具体如下面的代码所示:

通过媒体查询的功能是根据不同的分辨率适配不同的样式, 我们可以通过上面的做法是实现流体布局, 还可以通过媒体查询来细调具体的页面在不同分辨率下的不同表现形式。

4 结束语

相对于传统的Web应用实现方式, 响应式Web实现有以下几个优点:

4.1 对用户友好

很显然, 响应式Web设计可以向用户提供友好的Web界面, 因为它可以适应几乎所有设备的屏幕。现在技术发展日新月异, 每天都会有新款智能手机推出。如果你拥有响应式Web设计, 用户可以与网站一直保持联系, 而这正是开发响应式网站的目的所在。在响应式网站的帮助下, 你的应用可以很好支持移动智能终端用户, 你需要做的只是创建一个移动应用。

4.2 积累分享

响应式Web设计可以让你 (作为网站的拥有者) 通过单一的URL地址收集所有的社交分享链接。你可以为创建更好、更友好的网站而做出积极贡献。

4.3 无重定向和更少维护

响应式Web设计最大的优点之一是, 你不必在乎任何重定向, 它包含无用户代理定向。所以当你很少负责解决重定向及定向用户时, 这是一件很棒的事情。开发一个独立的移动网站, 会增加你的工作负担。实际上你就拥有了两个独立网站。如果你有一个响应式网站, 维护的成本将会很小, 因为它只有一个布局, 且可工作在所有类型的设备上, 而这可以明显地减少你的工作量。

当然基于响应式Web应用还存在一些诸如加载时间稍慢的问题, 它并非适合所有类型的网站, 本文也中的实现也具有一定的局限性, 需要以后不断结合新技术进行改进。

摘要：随着智能手机为代表移动终端设备的普及和发展, 提高基于不同设备的交互体验成了交互系统是否被认可的关键。本文通过采用基于响应式Web的自适应系统设计, 通过在系统的表示层甑别不同设备类型, 针对性提供界面需求, 提高了用户体验。

关键词：响应式Web,交互,移动终端

参考文献

[1]秀野堂主, 蒋宇捷, 罗睿.论道HTML5[D].北京:人民邮电出版社, 2012.[1]秀野堂主, 蒋宇捷, 罗睿.论道HTML5[D].北京:人民邮电出版社, 2012.

[2]张凤.基于Web Service的三层分布式系统应用研究[D].长春理工大学, 2009年.[2]张凤.基于Web Service的三层分布式系统应用研究[D].长春理工大学, 2009年.

[3]朱印宏.CSS商业网站布局之道[M].北京:清华大学出版社, 2007年.[3]朱印宏.CSS商业网站布局之道[M].北京:清华大学出版社, 2007年.

移动手机Web 篇7

Web Service也叫XML Web Service, 是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求, 轻量级的独立的通讯技术。是通过SOAP在Web上提供的软件服务, 使用WSDL文件进行说明, 并通过UDDI进行注册。Web Service的主要目标是跨平台的可互操作性。为了实现这一目标, Web Service完全基于XML、XSD等独立于平台、独立于软件供应商的标准, 是创建可互操作的、分布式应用程序的新平台。因此, Web Service有着跨防火墙的通信、应用程序集成、B2B的集成、软件和数据重用等显著特点。从上述特点我们可以看出, Web Service在通过Web进行互操作或远程调用的时候是最有用的, 也正是本例的特色所在。

二、服务器端设计介绍

本文是选择微软公司的V S 2008作为开发工具, 开发语言选择C++, 数据库直接访问内部办公网的数据库, 创建了名为Read News的WEB服务, 根据本单位内部办公网在校外不能直接访问的特点, 智能手机不能采用H T T P的访问方式, 故采取了在服务器上架设一个W E B服务, 考虑到安全性, 方法的设计包含了教师身份验证。设计了用于数据库的访问类DB.CS, 包含了Return_Data Set (string SQL) , Login_Check (string uname, string upwd) , E x e c u t e S Q L (s t r i n g S Q L) 3个常用的方法, 在index.asmx中编写了两个[Web Method], 分别是Read Top News (int Show Count, string uname, string upwd) 和Read By ID (int newsid, string uname, string upwd) 。

在服务器端, 通过上述设计, 实现了访问的身份验证, 更新最新发布的信息, 阅读某条具体信息这3个基本功能。主要设计了两个[Web Method], 简要代码如下:

[Web Method]

public System.Data.Data Set Read Top News (int Show Count, string uname, string upwd)

{

略

}

[Web Method]

public System.Data.Data Set Read By ID (intnewsid, string uname, string upwd)

{

略

}

三、客户端端设计介绍

在客户端的设计上, V S2008再带了W i n d o w s Mobile 5的移动开发模拟环境, 如需使用Windows M o b i l e 6作为调试环境, 需到微软网站下载安装Windows Mobile 6的SDK, 由于笔者使用的是倚天X650手机, 为了方便调试, 故选择手机运行环境为Windows Mobile 6 Professional, 当然也可以直接在自带的模拟器中进行调试, 使用起来非常方便。

客户端主要分为信息列表、信息检索、账号设置、在线更新、信息阅读几个功能模块。主要的设计思想是, 通过访问Web Service将最新的信息获得并存储在客户端的数据库中, 便于在客户端进行检索与阅读等操作, 基本结构如图1所示。

1. 客户端数据库设计

在客户端的设置上, 我们采用Microsoft SQL Server Compact Edition, 配合VS 2008开发工具, 为客户端应用程序提供低维护、精简的嵌入式数据库服务, 部署在Windows Mobile 6系统中比较方便, 在库中建了信息表, 包含了编号, 标题, 类别, 来源, 阅读次数, 阅读序号, 内容几个字段。

在手机端用数据库将更新的信息存储起来, 便于离线的阅读与信息的检索, 方便日后的信息维护, 从实际执行效果看, Microsoft SQL Server Compact Edition数据库已经达到了比较理想的运行效果。

2. 主要功能代码简要介绍 (见图2)

在客户端功能设计上, 主要分为:信息列表、信息检索、账号设置、信息更新几方面, 其设计代码略。

通过上述设计, 我们实现了在Windows Mobile系统中通过Web Service技术作为中介, 访问服务器端的MS SQL 2005数据库, 将获取的信息存储到本地的MS SQL Server Compact Edition数据中, 实现了随时随地轻松了解最新信息动态的功能, 在笔者的手机上, 无论是通过WIFI, 还是GPRS都实现了较好的访问速度。

四、结束语