移动Web2.0:Ajax在移动开发领域的影响
转自http://webservices.ctocio.com.cn/tips/429/6645429.shtml
?
一、关注点:
这篇文章阐述了一些我从前表达的观点，同时也在文中增加了一些新的观点。本文主要关注在Ajax在移动开发中的影响力(我们并不在这里大肆讨论Ajax)。
讨论议题:
1.什么限制了移动设备上的浏览器模式的发展，如何战胜它? 2.Ajax在移动开发中的影响力。 3.Ajax/浏览器模式的潜力将使应用定位在更加广泛的消费群体。二、对草地保龄球和长尾(long tails)的思考:
请想象一下如下情景:
正如大多数体育爱好者一样，你正热切地关注在墨尔本召开的联邦运动会。但是，和别人不同的是你喜欢的运动是“草地保龄球”。
“草地保龄球是什么?”人们经常会这样问你。因为很少有人(除了那些关注联邦运动会的)听说过这项运动(呵呵，这项运动将作为北京2008奥运会的表演项目)。于是你很兴奋于至少墨尔本正在进行这项比赛。但从宽泛的观点来看，像游泳、拳击这样“有魅力”的比赛才能获得所有的声誉。“草地保龄球”的确太冷门了。
而正当你将这个状况和Geek(技术迷)朋友聊起时，他会把一个称为“长尾”(long tails)的概念作为给你的解释。很明显，你就是“长尾”中的一员。
多数情况下，80%的收入来自于20%的产品或者服务(下图中的红色部分)。剩余80%的产品具有低需求和低销量的特征。它们组成了“长尾”(就象草地保龄球一样)。“长尾”原理所说明的是:那些低数量、低销售量的产品构成了市场的主力，它们与少数畅销产品相持平甚至超出后者，前者提供了广泛的分配渠道和价格低廉的产品。
“长尾”示意图
现在假使我们为联邦运动会设计一个移动应用，并已经进行了几个月的准备。但是设计者可能不重视“草地保龄球”这一部分。
但作为草地保龄球的铁杆球迷，你期待着全部的应用:blog、投票、图片、个人档案等等。
移动Web2.0，Ajax和部件设计对这个场景有所帮助吗?下文便见分晓。文章主要按以下范围讨论:
1.所有的移动应用都能采用浏览器技术实现吗? 2.采用移动Ajax的可能性。 3.移动Ajax技术的进化和Opera声明的意义。 4.“围墙花园”与“开放花园”。 5.来自JAVA ME的回应。 6.谈谈移动游戏。 7.为什么Ajax将代替J2me和HTML成为移动应用开发中的首选平台??
三、所有的移动应用都能采用浏览器技术实现吗?
在我们开始讨论移动应用和Ajax前，让我们思考一个这样的问题:所有移动应用都能采用浏览器技术实现吗?在PC/Internet的世界中，浏览器飞速成为了一个通用的客户端。但在PC世界和浏览器世界之间存在着天壤之别。
在PC世界，我们需要一种程序来执行一个特殊类型的应用(就像word用来读写word文档、excel用来读写表格一样)。而相对的，我们使用浏览器查看任何一种应用。这使应用开发被大幅度地优化，它受到运行在客户端的软件的影响更小。
让我们看一下浏览器和移动领域应用。假设移动设备具有更高的性能、更快速的带宽。那么在这个假设的前提下，所有的移动应用能以浏览器技术去实现吗?毕竟，工作在PC上的浏览器作为一个通用的客户端——为什么不能在移动设备上成行那?对这个问题的推断可能是:在移动设备上的浏览与在pc上使用的web浏览具有许多根本上的不同。
为了更好的了解这些不同，我们来考虑如下的因素:
1.间断的网络连接:
不像在pc上使用的web那样，无线网络相对不稳定，常收到信号覆盖的影响(如果进入隧道的话，你将失去连接)。
2.带宽限制:
即使3G覆盖提前实现，实际的带宽也不足以满足需要。
3.在客户端的数据存储:
如果设备没有本地存储，所有的数据将不得不被重复下载。而连接的间断性和昂贵的带宽又把这种存储方式逼入了绝地。
4.最后，也是最重要的——本地应用程序提供了丰富的用户体验，特别是对像游戏之类的应用而言。
这里还有诸如用户输入能力、屏幕尺寸之类的限制。上面因素中的一些会随着设备和技术的进步而得以改善。但是整体的用户体验仍然是重要的因素之一。
因此，我们这个假设问题的答案是——不能，我们不能仅使用浏览器开发所有的移动应用。但浏览式应用的框架正在改变，在浏览式和下载式应用之间的界限已经不如从前那样明显了。
在另一方面，本机和本地(native)应用提供了一项优势——更好的用户接口。但它们遭受了一些显著的缺陷——在应用中不得不覆盖多种不同的设备、操作系统、屏幕尺寸、用户接口、多个软件发布版本等问题。这也导致了移动领域的“割据”局面。
四、采用移动Ajax的可能性:
抛离上面的说法，我相信Ajax将导致浏览式应用的复苏，它将克服我们现在所面对的一些问题，理由如下:
1.到浏览器的抽象转移:
基于浏览器的应用相对易于升级、并能用在跨运营商的领域。这将吸引一个较大的目标用户群。开发者能访问消费者中核心群体来促进应用开发更有价值。正因为浏览器提供了一种通用客户端，所以它也减少了应用的分离(fragmentation)。
2.Ajax提供了更佳的浏览器体验核数据管理能力。
3.来自Internet上的开发者对Ajax的支持。
重量级的产业力量正在转移他们的支持到Ajax上来(IBM对Open Ajax的支持就是个好例子)。
4.部件设计的概念并非新鲜事物。
本文中，部件指的是一种可下载的交互软件对象，它提供了单一的服务(如地图、新闻feed等)。Ajax提供了在浏览器上实现部件的机制。
5.Ajax为部件写作市场(widget authoring market)提供了温床，就象Apple widgets 和 Opera widgets那样。
我相信Ajax通过提供丰富的体验、更大的用户群体、数据管理能力、部件写作工具而使浏览式应用的复苏更进一步。
另外，开发者的支持(包括在web领域和移动领域的)将引领Ajax形成一个我们难以想象的强大系统。
五、移动Ajax技术的进化和Opera声明的意义
Opera平台由以下主要特性组成:
1.全屏模式的Opera web浏览器; 2.一个运行多个部件/应用的Ajax框架; 3.通过抽象层访问设备本地功能(native functionality)。仅在2005年，Opera就已经在17000万移动浏览器上支持Ajax。这意味着凭借现有的Opera浏览器你可以使用桌面Ajax服务:例如Gmail、Google Maps等。
四、采用移动Ajax的可能性
抛离上面的说法，我相信Ajax将导致浏览式应用的复苏，它将克服我们现在所面对的一些问题，理由如下：
1.到浏览器的抽象转移:
基于浏览器的应用相对易于升级、并能用在跨运营商的领域。这将吸引一个较大的目标用户群。开发者能访问消费者中核心群体来促进应用开发更有价值。正因为浏览器提供了一种通用客户端，所以它也减少了应用的分离(fragmentation)。
2.Ajax提供了更佳的浏览器体验核数据管理能力。
3.来自Internet上的开发者对Ajax的支持。
重量级的产业力量正在转移他们的支持到Ajax上来(IBM对Open Ajax的支持就是个好例子)。
4.部件设计的概念并非新鲜事物。
本文中，部件指的是一种可下载的交互软件对象，它提供了单一的服务(如地图、新闻feed等)。Ajax提供了在浏览器上实现部件的机制。
5.Ajax为部件写作市场(widget authoring market)提供了温床，就象Apple widgets 和 Opera widgets那样。
我相信Ajax通过提供丰富的体验、更大的用户群体、数据管理能力、部件写作工具而使浏览式应用的复苏更进一步。
另外，开发者的支持(包括在web领域和移动领域的)将引领Ajax形成一个我们难以想象的强大系统。
五、移动Ajax技术的进化和Opera声明的意义
Opera平台由以下主要特性组成：
1.全屏模式的Opera web浏览器;
2.一个运行多个部件/应用的Ajax框架;
3.通过抽象层访问设备本地功能(native functionality)。
仅在2005年，Opera就已经在17000万移动浏览器上支持Ajax。这意味着凭借现有的Opera浏览器你可以使用桌面Ajax服务:例如Gmail、Google Maps等。
但是，其意义远远不止支持Ajax这一点：
1.Opera平台是首创的移动Ajax框架。
它也是一个名副其实的浏览器框架。但，和其它框架比如Zimbra (zimlets) 和 Backbase不同，它完全是为移动设备而设计的。它在浏览器和移动设备的设计上采用了相同的代码库。通过微小的改变，桌面浏览器部件也能运行在移动设备上。从开发者的角度看，这是一个再好不过的使部件(桌面、移动设备、浏览器)最大化获利的方法。Opera声明对移动应用开发意义深远的一点是它把一个庞大的代码库与获利紧密结合在一起。
2.部件调用其它部件。
复杂的应用可以由简单的、基于浏览器的组件开发而成。
3.Opera平台允许访问底层设备API。
为了说明这个概念，我们首先考虑一下浏览器模式在建筑学上的不足。
浏览器模式是基于标记(mark-up)语言、以文档为核心的。而相对的，那些被下载的或是本地的应用则以应用为中心，因为它们是基于某种编程语言的。
为了达到实用需要，任何移动应用开发模式必须具有访问那些和设备紧密耦合的数据成员。它们包括电话API、电话簿、短消息、消息API、呼叫记录、SIM卡、日历、蓝牙堆栈、媒体播放器、文件系统等。
运行在手机上的应用能够通过API访问这些服务。而在大多数情况中，运行在浏览器的应用却不能访问这些功能(除了一些厂商私有的解决方案)。
Opera平台是一个基于浏览器的编程环境，它通过一套javascript API将本地设备API进行了抽象，这样来提供给开发者从浏览器访问设备底层功能。它使建立的更加丰富的浏览器应用成为了可能。
让我们回到“草地保龄球”的话题，对Ajax、部件进行一些说明:Ajax的能力在于建立桌面极的部件。通过Opera平台的方式，同一个部件能被重用在移动设备上。这些部件便具有了从“长尾”获得收入的能力。在联邦运动会这个场景中，它应有可能为草地保龄球迷们提供低成本的部件。这些部件无论运行在桌面浏览器或是在移动浏览器上都运行良好。这就是Ajax方式的重大意义。
有人会站出来争辩:这个方式不是纯正基于浏览器的方式(因为客户端需要以某些软件的形式在本地执行)。另外，请注意平台方式和使用插件是不同的，因为插件是可以被下载。而平台却作为设备的一部分被生产厂商安装在设备中。
我同意称这种方式不够“纯正”的说法。但是以这种方式，开发者将处理很少的平台，而不是他们不得不去与之斗争的数以百计的变化体。
这种方式不是开发的。在一个平台开发的应用只能运行在此平台。并且此方式并没有获得开放移动联盟(这里简称为OMA)的认可。整个问题对于移动运营商来讲还太早，因为它还需要经过由浏览器厂商到设备生产商再到运营商的过程。但W3C mobile web initiative也可以作为与OMA协作的一个标准体。
最后，这种方式对于一些应用类型(例如游戏)来讲还不够“丰富”。
但无论如何，这也是在前进路上迈出的一大步，因为我们具有一个更统一、跨运营商的“运动场”。
从历史上看，流行技术常常依赖于产业支持。比如粗糙陈旧的SQL，软件厂商们(例如Sybase、Informix等)都各自发布一个SQL的程序版本(例如Oracle的PLSQL)。SQL和PLSQL在某些方面是矛盾的，因为SQL是基于集合的，而PLSQL是程序式的。
但是“程序式”的SQL由于产业需要而存在了下来。我们在Ajax身上印证了同样的现象。
