jquery mobile + sae开发手记

Jquery mobile无疑是一个优秀的JS框架,但到现在为止,还是没有看到基于jqm在移动平台上让人眼前一亮的应用,大家都在观望,到底webApp在移动平台上的定位如何。

这个月,基于SAE提供的移动平台开发了一个在线看漫画的应用,采用jquery mobile,实际体验了一把webApp的潜力及限制。

网站地址:http://kukubird.sinaapp.com

代码地址:https://github.com/memoryboxes/kukubird

系统架构:

SERVER:sae新建一个项目,用REST接口提供server端服务(我用了python+webpy,非常简洁):

  • 为前端提供漫画名称、类别、卷/话等数据
  • 为前端提供漫画地址解析
  • 提供用户认证,浏览历史记录
CLIENT:sae新建一个移动项目,采用JQM提供前端浏览界面

采用CS分离的做法有几个优点:
  1. SERVER端的漫画录入,修改是不会影响前端的,想要添加一部漫画,只要在后台加一下地址就可以了。
  2. 为扩展提供可能性,事实上,我们现在就是利用SERVER端的接口,写个脚本就一键将刚收录的漫画下载到本地了,目前网上不少漫画下载器就是这个道理。
  3. 前端的数据交互都用Ajax完成,完全是JS+CSS+HTML5完成,可以方便的用phoneGap打包。另外SAE也为移动项目提供了打包功能,什么本地环境也不用配,就可以拿到apk包及ios调试包了。
  4. 系统资源消耗是非常少的,server端开启memcache后,目前80个用户一天2个云豆就可以。当然图片的流量需要独立服务器支持。
系统细节:

让我们看一下一个完整的交互过程:
热门漫画浏览:
用户打开页面-->前端Ajax发送消息-->SERVER端跨域回应-->前端接受热门漫画列表-->重载pageshow事件,用listview渲染-->结束

漫画卷/话数浏览:
用户点击单一漫画-->前端Ajax发送消息-->SERVER端跨域回应-->前端接受漫画卷列表-->重载pageshow事件,用listview渲染-->结束

漫画页浏览类似

这样看来,没有什么了不起的,不过是将原来动态数据请求的部分,从直接操作数据库转移到Ajax方式而已。剩下的就是稳定性和前端的表现了。就我一点点测试来看,40W条数据内,SAE负担绰绰有余。数据量变大后,只要做好索引及表拆分,sae是绝对可以胜任的。

一点经验:

  • 一般一个jqm应用由几个页面组成,不同页面间需要一些数据传递,有以下两个办法:

    1. 采用url写入data-xxx的传递办法,这里有比较详细的讨论。这个适用于点击一个连接传递给另一个页面数据的场景。
    2. 采用html5的本地存储接口:localStorage,这个方法很简洁,适用于多个页面共享同一数据的场景

  • 页面强刷的问题,有时候前台更新了数据,需要重载整个页面,我在jqm1.1.0中试验了很多方法,最终是reload比较靠谱,详见我上一篇博文。

  • 在IOS系统中的优化,IOS系统中,safari对webApp的支持还是比较给力的,添加到主屏幕后,像这种漫画应用,浏览体验同原生的差不多。具体办法参考这里

目前的缺陷:

  • 如果对应用的UI要求比较苛刻的话,基本上后期就变成了改造jqm+重写CSS+自写效果的痛苦历程,我认为jqm暂时还不能胜任。对于非前端人员,还是老老实实用默认主题好了。

  • 运行速度还是有待提高,在一些低配的手持设备上,还会卡,但在ipad之类设备上面,基本上流畅了。

  • 最致命的问题,目前据我的实验,所有的OAUTH认证接入,都需要弹窗,浏览器访问webApp就罢了,但是在IOS系统中,添加到主屏幕,全屏访问你的webApp时,OAUTH认证便不能跳转回你指定的回调地址了,phoneGap打包的应用亦然,也就是说,你没法完美实现"用QQ号登录"这样的功能。目前我没有找到解决办法,如果大家有类似的需求,在使用jqm之前,需要好好考虑。


总体来说,目前的JQM是可以实现一些比较简单的数据交互网站,但如果你需要UI复杂,数据量巨大的交互应用,还是得原生App,当然,像 m.oschina.net这样的资讯类应用,JQM完全可以胜任。


ps:我对于前端开发并不熟悉,javascript也只是刚学习1个月而已,以上都是个人的主观感觉,仅供参考,不当的地方还请大家拍砖。




你可能感兴趣的:(jquery,python,sae,mobile,webapp)