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個月而已，以上都是我的的主觀感受，僅供參考，不當的地方還請你們拍磚。