iPhone和Android的WEB应用开发详解

iPhone和Android的WEB应用开发详解在我们现在的生活中，移动设备的作用日益重要。我们使用它们进行交流。我们使用它们进行导航。我们甚至可以将它们用作方便的手电筒。面向iPhone和Android平台的定制应用程序极其普及，与此同时，移动Web应用程序也开始崭露头角。本文是由两部分组成的系列文章的第一篇，这个系列主要围绕的是开发面向iPhone和Android的基于浏览器的应用程序。在这个系列文章中，我们将构建能运行在桌面以及这两个移动浏览器内的一个简单的网络监视应用程序。简介iPhone和Android平台加起来已经有10万多个应用程序可供从二者各自的应用程序库下载。本机应用程序指的是那些用某个平台的SDK构建、然后再编译和安装到某个设备上的应用程序。这些本机应用程序提供了对该设备固有功能的全面访问，包括诸如无线联网、蓝牙、数据存储、加速计、指南针和其他使这些设备变得十分吸引人的出色功能。虽然面向iPhone和Android平台的本机或定制应用程序极为普及，但移动Web应用程序也开始展露了巨大的潜力。移动技术渐趋成熟—移动Web也随之而来。本文是由两部分组成的系列文章的第一篇，这个系列主要围绕的是开发面向iPhone和Android的基于浏览器的应用程序，旨在帮助您开发您自己的移动Web应用程序。移动Web应用程序的威力不仅仅是在一个移动设备上呈现一个网站。我们还将接触到使移动Web开发如此势不可挡的某些核心技术和技巧。Web已经成为了平台的不二之选，因为它解决了困扰应用程序开发人员和系统管理员的诸多问题。如下例举了其中的几个解决方案：*Web应用程序容易部署—只需将它们安装或复制到服务器，并让您的客户将其浏览器指向正确的URL。*Web应用程序在高性能的数据中心内可以由服务器群很好地伸缩并能被既有的网站管理工具服务。*Web应用程序集中化数据存储并进而简化了灾难恢复计划。*HTML、CascadingStyleSheets(CSS)、JavaScript以及图像的综合提供了一种优化的用户界面体验，远远超出了本机SDK（缺少一种全身心投入的浸入式的游戏体验）的能力并且大多数应用程序体验均不保证游戏或kiosk体验。*大多数应用程序要求简单易用的UI元素来指导用户进行一系列的日常操作。Web应用程序发布模型的一个最为吸引人的地方是将软件转变为一种面向订阅的服务，这是一种实实在在的双赢。“为什么？”您不禁要问。让我们一起来看一看。Web部署模型允许顾客在购买之前先试用，这样以来，就将顾客的风险和成本减到了最少。如果顾客对试用很满意，那么只需进行一次信用卡（或PayPal）支付就可以继续使用此服务。软件供应商亦可以从中受益，因为系统升级被大大简化，减少了支持成本并最终减少了转嫁到顾客上的成本。并且，SaaS（softwareasaservice）模型还让顾客在享受了软件的种种好处的同时，无需大量的预先投入—投资回报在同一个月就可实现，而不是在不可预知的未来。听起来不错。适合Web的概念同样对移动奏效么？这个问题的答案常常是否，直到iPhone的出现。为何如此呢？实际情况是移动Web浏览器体验一直非常缺乏。但这一切有了改观，这要归功于一种新技术的出现，即WebKit，而iPhone则让WebKit成为了移动领域标志性的大事件。在短短几年时间内，iPhone已经从最初的尝试之举成为了移动Web客户机的鳌头。为何如此？因为WebKit加上可靠的Internet连接使得Web同样适于移动—并且与到目前为止的任何其他的浏览器相比，这一点尤其突出。移动市场的其他玩家已经注意到了这一动态并正在开始使用WebKit，或正在重新审视它，当然也有人反对它。那么，什么是WebKit？WebKit和HTML5WebKit是一种浏览器引擎，支撑着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=viewportcontent=width=device-width/。当这个metatag被添加到一个HTML页面后，我们看到此页面被缩放到更为适合这个移动设备的大小，如图2所示。如果浏览器不支持此标记，它会简单地忽略此标记。图2.页面被缩放到更为适合这个移动设备的大小当这个metatag被添加到一个HTML页面后，我们看到此页面被缩放到更为适合这个移动设备的大小在某些情况下，最为理想的方式是提前将窗口缩放到一个合适的值，如图3所示。图3.提前缩放窗口最为理想的方式是提前将窗口缩放到一个合适的值为了设置特定的值，将viewportmetatag的content属性设为一个显式的值：metaname=viewportcontent=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覆盖。迄今，我们已经看到了Web