iPhone和Android的WEB应用开发详解Word文档格式.docx
- 文档编号:3914297
- 上传时间:2023-05-02
- 格式:DOCX
- 页数:30
- 大小:388.55KB
iPhone和Android的WEB应用开发详解Word文档格式.docx
《iPhone和Android的WEB应用开发详解Word文档格式.docx》由会员分享,可在线阅读,更多相关《iPhone和Android的WEB应用开发详解Word文档格式.docx(30页珍藏版)》请在冰点文库上搜索。
如果顾客对试用很满意,那么只需进行一次信用卡(或PayPal)支付就可以继续使用此服务。
软件供应商亦可以从中受益,因为系统升级被大大简化,减少了支持成本并最终减少了转嫁到顾客上的成本。
并且,SaaS(softwareasaservice)模型还让顾客在享受了软件的种种好处的同时,无需大量的预先投入—投资回报在同一个月就可实现,而不是在不可预知的未来。
听起来不错。
适合Web的概念同样对移动奏效么?
这个问题的答案常常是否,直到iPhone的出现。
为何如此呢?
实际情况是移动Web浏览器体验一直非常缺乏。
但这一切有了改观,这要归功于一种新技术的出现,即WebKit,而iPhone则让WebKit成为了移动领域标志性的大事件。
在短短几年时间内,iPhone已经从最初的尝试之举成为了移动Web客户机的鳌头。
为何如此?
因为WebKit加上可靠的Internet连接使得Web同样适于移动—并且与到目前为止的任何其他的浏览器相比,这一点尤其突出。
移动市场的其他玩家已经注意到了这一动态并正在开始使用WebKit,或正在重新审视它,当然也有人反对它。
那么,什么是WebKit?
WebKit和HTML5
WebKit是一种浏览器引擎,支撑着iPhone内的MobileSafari浏览器以及Android内的浏览器背后的技术。
WebKit也在其他的移动环境内有自己的用武之地,但是我们还是将我们的讨论集中于iPhone和Android平台。
WebKit是一个开源项目,其起源可追溯到KDesktopEnvironment(KDE)。
WebKit项目催生了面向移动设备的现代Web应用程序。
虽然设备本身的能力和形态因素都相当重要,但移动用户最热衷的仍然是内容。
如果移动用户可用的内容只是Internet用户可用内容的一个很小的子集,那么用户体验充其量也只能划分为二等。
我们当中的大多数人都更希望生活是连贯的—如果我们在家中的笔记本上访问了一个网站,我们同样希望在火车上旅行时仍然访问到同样的内容。
内容是最好的应用程序。
不管我们身在何处、在做什么,我们都想要访问到我们的数据。
WebKit让iPhone和Android平台上可以有丰富的内容。
有一点很值得注意,即WebKit还应用在了桌面的Safari浏览器内,该浏览器是MacOSX平台默认的浏览器。
不管我们讨论的是桌面版本还是iPhone或Android上的浏览器引擎,WebKit均优先支持HTML和CSS特性。
实际上,WebKit还支持尚未被其他浏览器采纳的一些CSS样式—这些特性正在得到HTML5规范的考虑。
HTML5规范是一个技术草案集,涵盖了各种基于浏览器的技术,包括客户端SQL存储、转变、转型、转换等。
HTML5的出现已经有些时间了,虽然尚未完成,但是一旦其特性集因主要浏览器平台支持的加入而逐渐稳定后,Web应用程序的简陋开端将成为永久的记忆。
Web应用程序开发将成为主导—并且不只是在传统的桌面浏览器空间,还将在移动领域。
移动将一跃成为首要考虑,而不再是后备之选。
移动Web应用程序的考虑
为了访问Web开发技术,如今,应用程序开发人员有几个选择。
第一,应用程序可严格编写为服务器上的HTML、CSS和JavaScript文件。
当然,HTML内容可以产生自静态HTML文件,也可以从任何的服务器端技术(比如PHP、ASP.NET、JavaServlets等)动态生成。
所有这些技术追根到底都可简单地用术语HTML指代—这不是本文讨论的重点所在—并且最为重要的是,受WebKit-支撑的浏览器能够在移动设备上解析和呈现HTML。
用户通过在移动设备上(即iPhone或Android)打开浏览器应用程序并输入目标服务器对应的URL:
来访问Web应用程序。
特定的某个移动Web应用程序总是能找到自己的位置:
从一般的Web站点到高度特定于平台的移动Web应用程序。
一般站点的呈现
WebKit内的呈现引擎,再配以iPhone和Android平台上的高度直观的UI,实际上就使得几乎任何一个基于HTML的Web站点都能呈现在此设备上。
Web页能被正确呈现,不再像原来的移动浏览器体验:
内容被包裹起来或是根本不显示。
当页面加载后,内容通常被完全缩放以便整个页面都可见,尽管内容会被缩放得非常小,甚至不可读,如图1所示。
不过,页面是可滚动、放大、缩小的,这就提供了对全部内容的访问。
默认地,浏览器使用980像素宽的视见区或逻辑尺寸。
图1.加载时Web页面被完全缩小
当页面加载后,内容通常被完全缩小以便整个页面都可见,但是会被缩放得非常小
尽管这能提供对整个页面的访问,是原来的移动Web体验上的一个巨大进步,但还是需要做很多事情才能进一步改进移动体验。
移动友好性
要想使Web页面从一般的页面变成支持移动设备的页面,Web应用程序可以在几个方面进行修改。
虽然页面可以在WebKit中正确呈现,但是,一个以鼠标为中心的设备(比如笔记本或台式机)与一个以触摸为中心的设备(比如一个iPhone或Android智能手机)还是有区别的。
其中主要的一些差异包括“可单击”区域的物理大小、“悬浮样式”的缺少以及完全不同的事件顺序。
如下所列的是在设计一个能被移动用户正常查看的Web站点时需要注意的一些事情:
*iPhone/Android浏览器呈现的屏幕是可读的—大大好于传统的移动浏览器—所以不要急于草草制作您网站的移动版本。
*手指要大过鼠标指针。
在设计可单击的导航时要特别注意这一点—不要把链接放得相互太靠近,因为用户不太可能单击了一个链接而不触及相邻的链接。
*悬浮样式将不再奏效,因为用手指不能进行用鼠标指针进行的“悬浮”。
*诸如mouse-down、mouse-move等事件在基于触摸的设备上自然大相径庭。
这类事件中有一些将被取消,不要指望移动设备上的事件顺序与桌面浏览器上的一样。
这其中的细节在iPhoneinAction内有详述(参见参考资料)。
而从我们的目的考虑,我们将更多地着重于WebKit所能做的,而不是它不能做的。
让我们来看看要使一个Web站点对iPhone或Android访客具有友好性所面临的最为明显的一个挑战:
屏幕大小。
我们今天使用的实际移动屏幕尺寸是320x480。
请注意由于用户可能会选择横向查看Web内容,所以屏幕大小也可以是480x320。
正如我们在图1中看到的,WebKit将能很好地呈现面向桌面的Web页面,但是文本可能会太小以至于若不进行缩放或其他操作就无法有效阅读内容。
那么,我们该如何应对这个问题呢?
最为直观也是最不唐突的适合移动用户的方式是通过使用一个特殊的metatag:
viewport。
metatag是一个放入HTML文档的head元素内的HTML标记。
如下是一个使用viewport标记的简单例子:
<
metaname="
viewport"
content="
width=device-width"
/>
。
当这个metatag被添加到一个HTML页面后,我们看到此页面被缩放到更为适合这个移动设备的大小,如图2所示。
如果浏览器不支持此标记,它会简单地忽略此标记。
图2.页面被缩放到更为适合这个移动设备的大小
当这个metatag被添加到一个HTML页面后,我们看到此页面被缩放到更为适合这个移动设备的大小
在某些情况下,最为理想的方式是提前将窗口缩放到一个合适的值,如图3所示。
图3.提前缩放窗口
最为理想的方式是提前将窗口缩放到一个合适的值
为了设置特定的值,将viewportmetatag的content属性设为一个显式的值:
<
width=device-width,initial-scale=1.0user-scalable=yes"
通过改变初始值,屏幕就可以按要求被放大或缩小。
将值分别设置在1.0和1.3之间对于iPhone和Android平台是比较合适的。
viewportmetatag还支持最小和最大伸缩,可用来限制用户对呈现页面的控制力。
自具有320x480布局的iPhone面世以来,其形态系数就一直没有改变过,而随着来自不同制造商、针对不同用户群的更多设备的出现,Android则有望具备更多样的物理特点。
在开发应用程序并以诸如Android这类移动设备为目标时,一定要考虑屏幕尺寸、形态系数以及分辨率方面的潜在多样性。
除了Android设备与其他设备之间的这些物理差异之外,经验还表明Android的软件还通过设备内置的(on-device)浏览器设置对页面的呈现实施了更多控制。
不仅稳定,Android平台还很灵活。
取决于SDK等级和制造商,某个设备上的设置很可能不同于您的开发环境。
图4显示了取自AndroidEmulatorV1.6的浏览器应用程序的设置页面。
这个设置屏幕允许用户将一个设备设置为一个预先定义的缩放等级(far、near、medium)或请求此设备自动适应页面。
图4.AndroidEmulator的设置页面
取自AndroidEmulatorV1.6的浏览器应用程序的设置页面
在移动世界,变化无时无刻不在发生,我们这里所讨论的也不是一成不变的。
比如,针对浏览器SprintHero的设置就页面呈现而言具有完全不同的一组选项集。
Hero构建于AndroidV1.5之上外加一些HTC-提供的增强。
幸运的是,如果呈现在您的Web页面内,这些设置将被viewportmetatag覆盖。
迄今,我们已经看到了WebKit能很好地呈现一个常规的Web页面,尽管在不进行缩放的情况下,页面有些小并很难阅读。
接下来,我们将实施更多的控制,即通过使用viewportmetatag控制页面如何在设备上被查看。
这就使得页面更易读和易于导航。
但是如果我们想要更进一步,让站点看起来和感觉上更像一个移动应用程序,该如何做呢?
为移动量身打造
现在,让我们来看看以移动用户为目标进行设计时所应采用的设计策略。
我们举一个简单的例子,让我们来看看Google的GMail电子邮件服务的登录页面。
先来看看这个桌面浏览器体验,如图5所示。
图5.桌面浏览器
桌面浏览器体验
这个桌面主屏幕在左边具有信息性内容,在右边有一个登录区域。
将这个桌面视图与图6内所示的特定于移动的视图(取自iPhone)相比较。
图6.来自iPhone的特定于移动的视图(
来自iPhone的特定于移动的视图
图6内的屏幕很显然针对的是一个移动用户。
此用户被直接提示继续运行这个应用程序所需采用的步骤—无需缩放或滚动。
接下来,让我们看看这个移动GMail应用程序在阅读消息时的功能。
由于可被这个应用程序使用的资产有限,消息阅读窗口很少有机会展示按钮或导航。
任何专用于导航的空间都会占用用于阅读内容的空间。
而且,如果我们能够避免,我们绝对不想使用多个框架或滚动div元素。
移动GMail通过提供一个简单的、能在页面停止滚动时就立即出现的浮动菜单解决了这个问题。
此菜单具有三个按钮:
Archive、Delete和More。
选择More按钮,还会显示出额外的菜单项,如图7所示。
图7.浮动菜单
选择More按钮,会显示出额外的菜单项
这个应用程序就是为移动量身定做的。
另一个需要留意的事情是我们不想让运行着功能强大的浏览器(例如运行于iPhone或Android平台上的浏览器)的那些访客的移动体验大打折扣。
最后,请看GMail在页面底部所显示的内容,如图8所示。
图8.让用户决定
让用户决定
如果用户倾向于桌面版本更为强大的功能,那么就让他使用。
只要可能,就让用户决定。
现在,我们假设需要构建一个使用Web技术的应用程序,但该程序必须实际看上去更像是一个本机应用程序。
特定于平台的内容
下一个步骤是创建特定于平台的内容,通过格式化一个页面以使其看上去更接近目标平台的本机感观,而不是一般的Web站点。
本机究竟是何意思?
在深入挖掘如何让一个Web页面的观感更像是目标平台的一个本机应用程序之前,让我们先花点时间,比较一下iPhone和Android作为平台在视觉效果方面的差异—暂时不考虑二者很强的基于服务器的相同点。
iPhone的观感很独特。
如果把iPhone的一个屏幕快照显示给别人看,除非这个人一直居住于荒野,否则他很可能会一眼就识别出该屏幕快照来自一个iPhone。
但是如果把Android设备的屏幕快照给人看,那么结果很可能不同。
为什么会如此呢?
可能的原因有几个。
主要的原因在于iPhone上市已久并且拥有大量的近乎狂热的拥护者。
为了购买价格不菲的限量版特制V1iPhone,人们不惜排数小时的队。
不管您有没有一台iPhone,Apple的这一杰作都已经是当今市场中的偶像产品。
那么,Android境况如何呢?
Android还相对较新,并且在很多方面都与iPhone相悖,比如它接纳开源社区。
Android将被用在多个设备上(电话和其他家用电器类型的设备)。
目前,我们的讨论只限于移动手机以便让事情尽量地简化。
随着时间的推移,全球范围内面向Android的设备数量将有可能超过iPhone。
这是因为受Android支撑的设备由多个厂商制作并将可在多个运营商网络上应用。
随着加入到Android市场的玩家的增多,在感观方面自然要有分别。
从HTC提供的SenseUI界面不难看出这一点。
这种诱人的观感在核心AndroidSDK内并不具备,而且并不是与所有设备兼容。
Motorola、Google和Verizon已经结成团队来共同创建一种新的Android设备:
DROID。
它是第一个运行在2.0平台上的商业Android设备。
对比Android的多样性与iPhone的统一外观。
iPhone是Apple公司一个极具竞争力的专有产品。
iPhone的外观可能会与时俱进,但是几乎不太可能出现较大差别,而Android在其早期就经历了分别和差异。
那么,我们如何才能得到一个本机的观感呢?
在Web2.0出现以前,这将是一个很大的挑战。
为了支持多个客户浏览器(移动的和非移动的)所进行的早期尝试包括几个不同的技术,比如:
*完全并行的站点
*基于userAgent动态生成的内容
*Proxy服务器将内容提取到设备;
RIM已经将这种方式大量应用在了设备内置的电子邮件呈现中并取得了成功。
这些方式对于资金充足的大型团队而言可能是可以接受的,但是其他的情况又当如何呢?
我们不具备时间、人力或资金来换取这种功能。
并且,我们经过深思已经认识到昨天的移动Web的不足,所以我们决不想重蹈覆辙。
幸运的是我们不必如此。
在WebKit和CSS的年代,这些差异已经通过样式表和媒体查询(mediaquery)的使用得到了妥当的解决。
正如之前介绍的,一个媒体查询是一种获得客户相关信息的技术。
之前的传统做法是,浏览器发送一个userAgent字符串,用来标识此浏览器,而服务器则负责确定该向这个设备发送哪些内容(根据上述讨论)。
而有了媒体查询,浏览器就可以基于其能力作出决定。
下面就是获得针对smartphone的样式表的例子:
linkrel="
stylesheet"
type="
text/css"
href="
smartphone.css"
media="
onlyscreenand(max-device-width:
480px)"
而这里则是一个针对桌面计算机的媒体查询:
onlyscreenand(min-device-width:
481px)"
要更多地了解媒体查询,请查阅相关的草案规范(参见参考资料)。
接下来,我们将着重介绍一个例子,以展示这种方式在用以显示网络状态的示例应用程序的上下文中的应用。
网络监视应用程序
此应用程序的目的是为了监视多个服务器。
独立的软件开发人员通常会跨多个服务器支持多个应用程序。
如果在这个领域的从业时间很长,那么服务器的类型以及应用程序的类型就更有可能不同。
所有这些只是为了说明一个简单的工具无法监视各个应用程序的各个方面。
这也是引入NetworkMonitor(netmon)移动应用程序的原因所在。
它并未被设计成在移动设备上面面俱到,而是灵活和方便的。
netmon应用程序包含感兴趣的服务器列表。
其中的每一项显示关键性能指示器(KPI)。
KPI很早就被MBA学生用来衡量一个企业运转是否健康。
在Web应用程序托管领域,一些重要的KPI有:
*在最近一段时期内事务的数量:
o订单
o目录请求
oE-mail消息
o页面浏览量
*自上一次事务后的一段时期:
oEDI文档
o业务伙伴消息
o来自供应商的FTP文件
*数据库是否可用?
*最后一次已知备份的日期
*每个订单的平均金额
*剩余的磁盘空间
*过去一个小时、一天、一个月内所传输的带宽
这些数据项和任何其他的操作数据都是为了给出特定系统或应用程序的健康状况。
在节日期间,我们会实际察看在我们的一些站点上的订单数。
如果订单数没有出现逐小时稳步增长,那么我们就需要进一步探查问题了。
由于每个应用程序的需要以及所需资源不同,因而netmon应用程序必须灵活才能适应于每个应用程序的特殊性。
为了满足灵活性的要求,我们用一个最为基础的数据结构来代表特定应用程序的健康状况;
在本系列的第2部分,我们将着重关注于这些数据从何而来以及如何更新。
现在,我们只需关心如下所列的信息:
*站点的名称
*站点URL(主页)
*要更新的URL
*状态:
OK与否?
*总结:
对条件的大致描述;
或者是OK,或者是一个文本式的字符串来描述最高优先级的问题
*条目:
这是用来表达站点的当前操作数据或KPI的名称/值对的集合。
我们的应用程序将以一种易于导航的方式列出这些条目、利用CSS、jQuery和WebKit功能来使这些项突出出来。
正如之前所提到的,我们的目标是为了让此应用程序能够运行在iPhone、Android以及Safari的桌面版本之上。
构建一个应用程序
如今,Web页面应该以一种声明式的方式创建,只提供组织和内容。
所有定位和格式化都通过CascadingStyleSheets实现,并通常还有JavaScript的协助。
实际上,JavaScript库已经如此流行以至于成为了一种规范,而不再是例外。
在本文的示例应用程序内,我们使用了流行的jQueryJavaScript框架。
这个示例应用程序将呈现在iPhone、Android以及桌面上。
HTML内容则完全相同。
差异存在于选中的样式表。
提醒您:
我们并未对如何让应用程序的外观光鲜诱人给予过多的关注。
实际上,为了突出此应用程序的样式表组织,我们过多地强调了背景颜色。
我们将在本系列的第2部分中全面讨论应用程序的外观。
应用程序相应的HTML如清单1所示。
清单1.此应用程序的HTML
!
DOCTYPEhtmlPUBLIC"
-//W3C//DTDXHTML1.1//EN"
"
http:
//www.w3.org/TR/xhtml11/DTD/xhtm
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- iPhone Android WEB 应用 开发 详解