图 7. 浮动菜单
选择 More 按钮，会显示出额外的菜单项
这个应用程序就是为移动量身定做的。
另一个需要留意的事情是我们不想让运行着功能强大的浏览器（例如运行于 iPhone 或 Android 平台上的浏览器）的那些访客的移动体验大打折扣。最后，请看 GMail 在页面底部所显示的内容，如图 8 所示。
图 8. 让用户决定
让用户决定
如果用户倾向于桌面版本更为强大的功能，那么就让他使用。只要可能，就让用户决定。
现在，我们假设需要构建一个使用 Web 技术的应用程序，但该程序必须实际看
上去更像是一个本机应用程序。
特定于平台的内容
下一个步骤是创建特定于平台的内容，通过格式化一个页面以使其看上去更接近目标平台的本机感观，而不是一般的 Web 站点。本机究竟是何意思？
在深入挖掘如何让一个 Web 页面的观感更像是目标平台的一个本机应用程序之前，让我们先花点时间，比较一下 iPhone 和 Android 作为平台在视觉效果方面的差异 — 暂时不考虑二者很强的基于服务器的相同点。
iPhone 的观感很独特。如果把 iPhone 的一个屏幕快照显示给别人看，除非这个人一直居住于荒野，否则他很可能会一眼就识别出该屏幕快照来自一个
iPhone。但是如果把 Android 设备的屏幕快照给人看，那么结果很可能不同。为什么会如此呢？可能的原因有几个。主要的原因在于 iPhone 上市已久并且拥有大量的近乎狂热的拥护者。为了购买价格不菲的限量版特制 V1 iPhone，人们不惜排数小时的队。不管您有没有一台 iPhone，Apple 的这一杰作都已经是当今市场中的偶像产品。那么，Android 境况如何呢？
Android 还相对较新，并且在很多方面都与 iPhone 相悖，比如它接纳开源社区。Android 将被用在多个设备上（电话和其他家用电器类型的设备）。目前，我们的讨论只限于移动手机以便让事情尽量地简化。
随着时间的推移，全球范围内面向 Android 的设备数量将有可能超过 iPhone。这是因为受 Android 支撑的设备由多个厂商制作并将可在多个运营商网络上应用。随着加入到 Android 市场的玩家的增多，在感观方面自然要有分别。从 HTC 提供的 SenseUI 界面不难看出这一点。这种诱人的观感在核心 Android SDK 内并不具备，而且并不是与所有设备兼容。Motorola、Google 和 Verizon 已经结成团队来共同创建一种新的 Android 设备：DROID。它是第一个运行在 2.0 平台上的商业 Android 设备。
对比 Android 的多样性与 iPhone 的统一外观。iPhone 是 Apple 公司一个极具竞争力的专有产品。iPhone 的外观可能会与时俱进，但是几乎不太可能出现较大差别，而 Android 在其早期就经历了分别和差异。
那么，我们如何才能得到一个本机的观感呢？
在 Web 2.0 出现以前，这将是一个很大的挑战。为了支持多个客户浏览器（移动的和非移动的）所进行的早期尝试包括几个不同的技术，比如：
* 完全并行的站点
* 基于 userAgent 动态生成的内容 * Proxy 服务器将内容提取到设备；RIM 已经将这种方式大量应用在了设备内置的电子邮件呈现中并取得了成功。
这些方式对于资金充足的大型团队而言可能是可以接受的，但是其他的情况又当如何呢？我们不具备时间、人力或资金来换取这种功能。并且，我们经过深思已经认识到昨天的移动 Web 的不足，所以我们决不想重蹈覆辙。
幸运的是我们不必如此。在 WebKit 和 CSS 的年代，这些差异已经通过样式表和媒体查询（media query）的使用得到了妥当的解决。正如之前介绍的，一个媒体查询是一种获得客户相关信息的技术。之前的传统做法是，浏览器发送一个 userAgent 字符串，用来标识此浏览器，而服务器则负责确定该向这个设备发送哪些内容（根据上述讨论）。而有了媒体查询，浏览器就可以基于其能力作出决定。下面就是获 得针对 smartphone 的样式表的例子：
rel=\screen and (max-device-width: 480px)\/>。而这里则是一个针对桌面计算机的媒体查询：
href=\media=\screen and (min-device-width: 481px)\/>。
要更多地了解媒体查询，请查阅相关的草案规范（参见 参 考资料）。
接下来，我们将着重介绍一个例子，以展示这种方式在用以显示网络状态的示例应用程序的上下文中的应用。
网络监视应用程序
此应用程序的目的是为了监视多个服务器。独立的软件开发人员通常会跨多个服务器支持多个应用程序。如果在这个领域的从业时间很长，那么服务器的类型以及应 用程序的类型就更有可能不同。所有这些只是为了说明一个简单的工具无法监视各个应用程序的各个方面。这也是引入 Network Monitor (netmon) 移动应用程序的原因所在。它并未被设计成在移动设备上面面俱到，而是灵活和方便的。
netmon 应用程序包含感兴趣的服务器列表。其中的每一项显示关键性能指示器（KPI）。 KPI 很早就被 MBA 学生用来衡量一个企业运转是否健康。在 Web 应用程序托管领域，一些重要的 KPI 有：
* 在最近一段时期内事务的数量： o 订单
o 目录请求
o E-mail 消息 o 页面浏览量
* 自上一次事务后的一段时期： o 订单
o EDI 文档
o 业务伙伴消息
o 来自供应商的 FTP 文件 * 数据库是否可用？
* 最后一次已知备份的日期 * 每个订单的平均金额 * 剩余的磁盘空间
* 过去一个小时、一天、一个月内所传输的带宽
这些数据项和任何其他的操作数据都是为了给出特定系统或应用程序的健康状况。在节日期间，我们会实际察看在我们的一些站点上的订单数。如果订单数没有出现逐小时稳步增长，那么我们就需要进一步探查问题了。
由于每个应用程序的需要以及所需资源不同，因而 netmon 应用程序必须灵活才能适应于每个应用程序的特殊性。为了满足灵活性的要求，我们用一个最为基础的数据结构来代表特定应用程序的健康状况；在本系列的第 2 部分，我们将着重关注于这些数据从何而来以及如何更新。现在，我们只需关心如下所列的信息：
* 站点的名称
* 站点 URL（主页） * 要更新的 URL * 状态：OK 与否？
* 总结：对条件的大致描述；或者是 OK，或者是一个文本式的字符串来描述最高优先级的问题
* 条目：这是用来表达站点的当前操作数据或 KPI 的名称/值对的集合。
我们的应用程序将以一种易于导航的方式列出这些条目、利用 CSS、jQuery 和 WebKit 功能来使这些项突出出来。正如之前所提到的，我们的目标是为了让此应用程序能够运行在 iPhone、Android 以及 Safari 的桌面版本之上。
构建一个应用程序
如今，Web 页面应该以一种声明式的方式创建，只提供组织和内容。所有定位和
格式化都通过 Cascading Style Sheets 实现，并通常还有 JavaScript 的协助。实际上，JavaScript 库已经如此流行以至于成为了一种规范，而不再是例外。在本文的示例应用程序内，我们使用了流行的 jQuery JavaScript 框架。这个示例应用程序将呈现在 iPhone、Android 以及桌面上。HTML 内容则完全相同。差异存在于选中的样式表。提醒您：我们并未对如何让应用程序的外观光鲜诱人给予过多的关注。实际上，为了突出此应用程序的样式表组织，我 们过多地强调了背景颜色。我们将在本系列的第 2 部分中全面讨论应用程序的外观。应用程序相应的 HTML 如清单 1 所示。
清单 1. 此应用程序的 HTML