Adobe Air 应用实践：“乐宝”

 

 

乐道“乐宝”网站： http://www.likenote.com/air/index.html

最初接触 Adobe Air 还是在去年七八月的时候，好像那时它还叫做 Apollo ，我专门为它做了个简单的动态页面，用来显示最新的用户留言，然后调用其组件访问这个页面，把这个页面包装为一个 Apollo 应用，一句代码都没写，总共不超过10行代码。感觉还是很不错的（当时apollo好像连在线安装的功能都没有），我将它起名为“乐宝”。后来在关注 django 框架的时候我注意到一个叫做 Pownce 的网站， 它和其它新兴起的 web 2.0 网站最大的区别是它提供了一个 Adobe air 的应用，这个应用写的很好，让我对用 air 做桌面应用产生了极大的兴趣。当时 air 只出了个 1.0 beta ，而且不断的在变化，到后来我自己的那个“乐宝”都无法运行了，于是我觉得还是暂时放弃学习它，等这门技术成熟了再说。后来去了家新公司，不停地被 java 项目催着也没机会再去关注它，一晃一年过去了， adobe air 1.1 已经出来了。最近几个月我不断地学习 Actionscript 3 和 flex 以重新修改乐道的几个 flash ，随着对这些技术的掌握，我觉得重新开发“乐宝”的时机到了。

 

为什么要开发“乐宝”呢？

其实原因很简单，主要是为了解决访问“乐道”的乐友无法收藏自己喜欢的推荐这个问题。“乐道”是一个“少数人写，多数人听和看”的网站，这种模式源于几个原因：1：保持推荐的品质，2：不增加服务器负担，3：没有商业支持。 所以短时间内这个模式是无法改变的。那么如何解决收藏音乐推荐的问题呢？其实我早在一年前就考虑好了一个解决方案：就是开发一个桌面应用，让用户把喜欢的推荐保存在自己的本机系统中。几个月的 flex 开发让我对这个方案的可能性越发有了信心。学习和开发 air 的过程并没有碰到太多的困难，我感觉 air 只是在 flex 和 Flash 基础上添加了一些库，基本开发方式没有什么变化，主要是多了一些对本地文件访问，拖拽，剪裁版操作和数据库访问的支持。掌握了一些概念后，我立刻开始撰写“乐宝”，基本的功能需求早已在我脑海中有了雏形。 于是 9.29 号我就开始开发这个程序，关键问题就是解决分页和本地收藏。开发意外的顺利，这两个问题两天内就得到解决了，“乐宝”1.0在9.30发布了。于是乎接下来的四天里，“乐宝”每天都在更新添加新功能，一直发展到现在这个版本。更新的开发过程是愉快的，最麻烦是发布1.0 的那两天。

 

点击放大

 

这些天的开发和学习让我有了一些感想：

 

Adobe Air 的优缺点:

 

优点：

1：跨平台桌面应用。

 

跨平台桌面应用表现在我最先开发它是用的苹果机 macbook ， 开发到一半转移到了PC平台，后来我再也没有打开过苹果机去测试，发布了好几个版本后，让我一个朋友在苹果机上测试，一点问题都没有。 虽然 air 本来就是支持 windows, mac 两个平台的，但是这个结果还是让我很兴奋。

 

2： 在线安装

 

在线安装的优势就更明显了，在假期里我找了几个测试的朋友，大多是电脑盲，让他们去下载应用然后安装简直就是要他们的命。而在线安装无疑解决了一个大问题。只需要点击图片按照提示的做，就可以非常方便的安装本地应用。

 

3：在线更新

 

内置的在线更新功能非常方便，我将更新代码内置在“乐宝”中，每次发布了新版本后，“乐宝”会自动探测新版本信息，然后下载安装，这种升级的方便性也得到了一些朋友的好评。 我每次发布新版本就无需通知他们，他们也能在启动的时候得到版本的最新信息。

 

4：内置 Sqlite3 数据库

 

好像 Google Gear 也是采用的 Sqlite3 作为本地数据库的，这种内置的数据库对于开发本地应用来说实在是太方便了。 只是 AIR 的数据库操作是异步的，这的确让刚开始用它开发的我很迷惑了一阵， 平时我们开发数据库程序都无需考虑异步访问，结果集都是等待得到的。 而在 air 中，每一条 sql 指令都要建立 resultHandler 和 faultHandler 事件响应程序，然后添加监听器。这的确很麻烦。 我的感觉就是：“同步”是属于完美快速的未来世界的现象，而“异步”则是缓慢的现实世界的状况。

 

 

缺点：

对 adobe air 的诟病之声从来没断过，在我看来，最大的问题在于 Adobe air runtime 太大，第一次在线安装需要的时间太长。 我想问题可能在于兼容以前的 AS 2.0 以及同时支持HTML网页开发 air 应用的关系。对于像我这样只用 flex 和 AS 3 开发 air 应用的人群，如果 Adobe 能单独提供一类裁剪后的 AIR 运行环境，那么肯定有助于推广这门技术，这就类似于消费类 JRE 一样， 至于 Air 有什么其它的问题我还没发现。

 

1： 没有哪个技术是很完美的

 

关于 Adobe air 和 Silver light, JavaFX 的讨论无论在 csdn ，还是 javaeye 上都很多，大家都在处于观望的态度。查看一下 Adobe air 的官方网站，发现国外有很多成功案例。很多人都说 Air 不够强大，缺少一些本应用的功能。就我看来这根本不是问题，因为没有什么技术从一开始就是很强大的，尤其是对于跨平台的技术，要解决的问题有很多，Adobe air 对 linux 桌面的支持也已经开始了，尽管现在的 air for linux 版本连装都装不上,但是我还是对它抱有期望。 Air 的功能对于大多数桌面网络应用来说已经够用了，与其等一个技术完全强大起来，还不如先用它来开发自己的应用，看看它是否能满足你的要求。大多数时候我们对一个技术的期许都太高和太完美，其实没必要。对于开发自己的东西，我的做法和大多数人不一样，通常别人都是技术向需求低头，而我是需求向技术低头。如果技术暂时无法实现，那么我就先不实现这个需求，而是改变或裁剪需求，直到技术可以实现需求了再说。在长期做 java 项目的过程中，我非常厌倦被动地接受需求而按照指定的进度期限内完成任务的做法，管理方和公司老板在开始阶段不管你采用什么方式来实现功能，只要求你完成进度，而当你完成了进度后，他会在项目出现问题的时候责备这种实现的不合理性，而这个时候却没人会去考虑在开始阶段的需求是否合理。 我的这种做法肯定是不会被大多数公司所接受的，但是我还坚持用来开发我自己的项目。 没有一个技术的功能能完全达到你的需求，因此放弃它是不可取的，只要技术能满足你80% 的需求就应该考虑一下它，剩下的就等待它的发展了，只要你看好它的前途。

 

2：如果能在开始阶段解决的问题，就尽量在功能还很简单的时候做。

 

在开发“乐宝”的后期我开始研究 Flex 的框架 Cairngorm ， 这是一款 MVC 框架，正如同那些 Java Framework 一样，每个框架都说自己是 MVC ， 但是每个框架对 MVC 的解释都完全不同。Cairngorm 把 Controller 作为业务逻辑层的做法对于那些用 java 框架的人来说肯定是不可接受的，我个人对它在事件响应中重新 dispatch Business Event 的做法也感觉很别扭，但是我还是决定尝试一下这个框架，因为我这个人比较相信官方出品的东西，Cairngorm  毕竟得到了 Adobe 的支持，不过有点另外担心的是这个框架从去年中期就没有再更新了，不知道 Adobe 怎么想的。我曾经跟朋友讨论过，对于一个 flex 小应用是否应该采用 Caringorm ，他似乎认为不应该，我则相反。按照 Cairngorm 自己的说法, 它适合中到大型应用。其实任何一个框架对应用的适用性不光体现是在应用的大小，框架对于整理和规范代码来说也是非常好的。现在的“乐宝”已经有了第二个分支，我在这个分支上在采用 Cairngorm 做修改。一旦修改完毕，就将发布 1.1 版本。而这种修改现在变得有点麻烦，因为代码已经也写了很多，再开始按照框架来变化显得有点力不从心了。所以说：不应该认为框架只适合中大型应用就对小应用不采用它，因为小应用也往往会变得复杂起来。所以，如果能在开始阶段解决的问题，就尽量在功能还很简单的时候做。Cairngorm 虽然是 MVC 框架，但是并不是一个 COC(默认设置优先配置）的框架，它对于文件存放的目录有一些建议，但是没有硬性设置，这就可能使得每个使用它的人都使用自己的命名规则，这是个缺点。我也在逐渐形成我自己的一个命名规范，一旦成熟，准备开发一个 gem 用于生成一些必须的文件，引入 FlexUnit ,生成默认测试用例等等。

 

3：没有一种语言可以解决所有的问题。

 

对于未来的"乐宝"，我最希望加入的功能是"聊天"。在我还不懂 java 的之前，我曾经用 Adobe director 做过将近三年多的多媒体开发。其中曾经用 MultiUser 做过一个聊天室，这个软件是内置在 Director 8以前的版本中的，所以我一直对聊天功能很感兴趣。这几年的 java 和 ruby 编程让我觉得它们不是很适合开发聊天室服务端，于是最近我一直在学习 erlang ，这个高并发分布式编程语言似乎最适合用来开发聊天应用的服务端。 Flex 本身有良好的 Socket 支持。所以两者结合起来应该是最好的聊天应用开发组合。很多人喜欢用一种语言去解决所有的问题，这是一种避免再学习新技术的做法，只要找一门通用性很强的语言学习就可以了。但是现今没有哪门语言是“万灵药”，就如同《Ruby way》的作者所言：“我们认为OOP是很好的工具，但我们不认为它能治疗癌症”一样。多语言并存的现象将长期存在，所以找最合适的语言来开发应用是合理的解决方案。 因为 erlang 不是一门通用语言就因此不学习它是不可取的。 erlang 在并发，并行和分布式上面的优势可能是其它语言在短期内无法达到的，所以值得投入时间学习一下。至于“乐宝”的聊天功能什么时候能实现，就要看我对 erlang 的学习进度了。FP 式语言对于长期使用命令式语言的我来说，有点难理解，看起来还是很头疼的。