jQuery Mobile #1 開始建立一個新的 jQuery Mobile 專案

image

這幾天非常的慘烈,奉勸如果有想要進來開發 Mobile Web 的同好,一定要謹慎評估 Framework 的使用,話說最初我也是非常堅持在效果上,如果能做到像 app.ft.com 這種水準的網站,真的是作夢都會笑。不過最終繞了一大圈,我還是又回到了 jQuery 的懷抱。當然有非常多的原因,時程的壓力、擴充性跟可維護性、不過讓我最後下定決心的還是因為客戶希望時程內要能在 windows phone & IE 上正常瀏覽。

雖然百般無奈,但是開始用了 jQuery Mobile 三個小時之後,其實比我想像中的還要好一些。而且最重要的是,我開始懷抱過年可以賴在家看電視的夢想了。

基本 html 架構

<!DOCTYPE>
<
html>
<
head>
<
title></title>
</
head>
<
body>
<
div data-role="page">
<
div data-role="header">
</
div>
<
div data-role="content">
</
div>
<
div data-role="footer">
</
div>
</
div>
</
body>
</
html>

  • 如果要使用 jQuery Mobile 預設會需要這幾個 div 用 data-role 去設定,分別是 page,header,content,footer,有了這幾個 div 預設的動作才會正常,不然會一直呈現鬼打牆狀態,像是超連結點下去沒有反應之類的…。我第一件發現的事情是 jQuery Mobile 把全部 <a> 的動作都吃掉了(如果超連結是 http:// | https:// 開頭的不會,吃掉的是站內連結),預設會取代成 ajax loading 來做換頁的效果。
  • 使用預設的 ajax loading 的時候,載入的頁面也必須包含這幾個 div , jQuery Mobile 在背景做 loading 頁面的動作,然後把 <div data-role=”page”></div> 之間的資料做更新的動作。
  • jQuery Mobile 最大的優點就是他真的在跨瀏覽器上面做了很多的功夫,像是 pushState 還有 webkit transform 這些很不錯但是又有人不支援的功能,都有默默的判斷。如果說將來 Mobile OS 市場愈來愈多人加入戰局的話,考慮使用 jQuery Mobile 的應該也會大增。


jQuery Mobile | jQuery Mobile

HTML5 applicationCache javascript Events

image

利用 manifest 可以做到 application cache 在頁面載入的時候,瀏覽器就會先確定 manifest 中每個文件是不是都已經存在 application cache 裡面,上面的畫面就是 chrome 在確認的時候 console 顯示的資訊。

appCache = window.applicationCache;
appCache.addEventListener('cached', handleCacheEvent, false);
appCache.addEventListener('checking', handleCacheEvent, false);
appCache.addEventListener('downloading', handleCacheEvent, false);
appCache.addEventListener('error', handleCacheError, false);
appCache.addEventListener('noupdate', handleCacheEvent, false);
appCache.addEventListener('obsolete', handleCacheEvent, false);
appCache.addEventListener('progress', handleCacheEvent, false);
appCache.addEventListener('updateready', handleCacheEvent, false);

IE7,8 在 addEventListener 會沒有第三個參數,不過反正 IE 7,8 也不支援 application cache ….

checking

每次重新載入頁面都會觸發這個 event ,檢查 application cache 的檔案

downloading

manifest 檔案有被修改過,開始下載前觸發

progress

下載檔案的時候觸發,注意的是每下載完一個檔案就會觸發一次喔

cached

檔案全部被 cache 了,但是這個事件是第一次進入的時候 cache 完成發生的。

noupdate

manifest 檔案沒有修改過

updateready

不是第一次進入這個頁面,manifest 有修改過,而且下載已經完成,cached,noupdate,updateready 都是 application cache 沒有發生異常的狀況下最後一個事件。

obsolete

如果 manifest 檔案回傳給你 404 或 410 就會發生這個 event

Error

就是發生錯誤的時候囉,瀏覽器在一開始確認跟最後的時候都會確認 manifest 檔案。之前就發生過一個狀況是因為我不想要每次測試都修改 manifest 檔案,所以就讓 manifest 動態產生,再給他一個 # 加上 Datetime.Now.ToString,結果每次都錯誤,因為瀏覽器在第一次 checking 跟最後確認的時候取得的 manifest 檔案是不一樣的。

另外 manifest 檔案的 MIME 必須是 text/cache-manifest 而且編碼是 UTF-8,如果適用 IIS Server 就必須在 IIS 下的 MIME 額外去設定附檔名對應,預設副檔名 manifest 對應的是 application/x-ms-manifest ,目前看起來針對 application 的 manifest 似乎也沒有公認的副檔名,各家網站設定也都不一樣,反正只要回傳的 MIME 是 text/cache-manifest 就 OK 了


6.6 Offline Web applications — HTML Standard

HTML5 Rocks – A Beginner’s Guide to Using the Application Cache

Using HTML5 Offline Application Cache Events In Javascript

Javascript mobile frameworks

最近需要開發一個新的專案,專門為了手機的平台的 Website ,其實基本上就是 Web 但是希望可以做到 App 的效果,可想而知會花很多時間在 Javascript 的部分作調校,每一行 js 都自己 code 就太累了,趕快在準備階段先來找找好用的相關工具。

主要考量的也只有少少幾個方向

1.換頁特效流暢度

既然特地為了 mobile 裝置作開發,當然要能有更好的使用者體驗,雖然說為了跨平台還選擇了 Web 的方式,但是當然是希望能夠做到 App 的效果。

2.相容性

既然說是 Mobile Framework 就不能只有在少數裝置能使用,其他裝置上就算硬體不能做到特效也是必須要能正常瀏覽不破圖。

3.開發便利性以及整合性

希望可以好開發、好維護,大家都是這樣想的吧

jQuery Mobile

JQuery 這就不用說了,就算沒見過豬走路也吃過豬肉,在 Web 上負有盛名的 JQuery 也出了 Mobile 版本的 plugin。不過在實際操作 demo 跟其他 framework 相比之下真的就被比了下去,在特效處理下就差了蠻多的。

image

▲jQuery Mobile 的預設換頁特效,加入 js 之後所有的換頁連結都會被取代

不過在嘗試之中才發現,其實他還是保有了 JQuery 的精神,容易學習,還有支援跨瀏覽器 (jQuery Mobile Supported Platforms)清單真的是非常豪華,為了讓這張清單洋洋灑灑的,jQuery Mobile 可以說是犧牲掉了非常多的東西,值不值得就見仁見智了

Sencha Touch

這套 framework 畫面還有特效流暢度都比 jQuery Mobile 流暢很多,但是缺點就是這套 framework 開發方式已經不太像開發 Web 了,官方範例的頁面完全都是從 js 裡面去動態產生。這大大的增加了從 Web 要入手的難易度,還有一個重點是這套 Framework 大量的使用了 webkit 的 CSS 3 ,所以才能達到這麼好的效果。

因為使用了大量的 webkit css 效果在 Mobile 上面是比 jQuery Mobile 好的多,實際操作流暢程度真的有差,問題就是並不是每一款行動裝置都支援,除了瀏覽器使用 webkit 核心的裝置外,其他裝置上面會連顯示都有問題,或著是安裝了其他種類的瀏覽器在 Mobile 上也會無法正常執行。

DHTMLX Touch

這款基本上特色跟 Sencha Touch 差不多,也是針對 Webkit 作優化,在非 webkit 上面的狀態會比 Sencha Touch 好一些,但是真正要發布的時候還是在 user Agent 排除掉非 webkit 的瀏覽器吧。

jQTouch

為了讓 jQery Mobile 能夠有更好的體驗,所以 jQTouch 幫 jQuery Mobile 加上了 Webkit 部分的效果,主要是針對 iOS 的裝置作的效果。在其他裝置上就不太行了。

Compendium

大部分的 js Framework 都想要能夠達到 navitve app 的效果,一開始要執行 Mobile Web 的時候我也是這麼想的。現在 Mobile 效能確實提升很多,各種 App 也讓我們忘記他的配備等級其實是很差的,要求能跟一般個人電腦一樣的效果其實真的很不容易。所以很多廠商都直接跳進了 CSS 3 之中,即使 CSS 3 的標準還不是各家瀏覽器都有支援。在我看來 jQuery Mobile 跟 Sencha Touch 正好站在天秤的兩端,一邊是號稱支援幾乎全部的 Mobile 裝置,在每一台機器上都得到一樣的體驗,比瀏覽一般網頁好一些些的體驗。另一邊是讓你忘了你只是在瀏覽 Mobile Web,如果你拿的是 iOS & Android。

Reference

用HTML和Javascript開發iPhone/Android原生軟體-Mobile Web App Framework總整理

JQuery Mobile

ASP.NET MVC – MaxLength & MinLength Client 驗證

在 Mvc 的 Model 屬性中有 MaxLength 跟 MinLength 的限制屬性,一般情況像是 [Required] 必填還有 Regex 的限制都可以搭配 jquery.validate 做到 Client 的 javascript 驗證效果。我本來以為 MaxLength 跟 MinLength 應該也可以達到同樣的效果在 Javascript 先行驗證。

image

▲在 Model 加上長度限制

image

▲可是在 View 使用 TextboxFor 產出的 Html 並沒有加入 jquery.validate 的屬性

原本想說會不會是內建的方法沒有支援,但是怎麼想都覺得不太可能,這麼常用的方法,不支援也太不合常理了吧。爬了網路上的文章才發現如果要限制字串的長度的話,需要用 [StringLength] Attribute,才會在 TextboxFor 的時候自動加入 jquery.validate 的屬性。

image

▲需要用 [StringLength] Attribute

image

▲加入了 jquery.validate 需要的屬性

image

▲[StringLength] Attribute 也提供了最小長度的具名參數

image

▲Html Helper 產出的 Html

Reference

MaxLength Attribute not generating client-side validation attributes

http://stackoverflow.com/questions/6801656/maxlength-attribute-not-generating-client-side-validation-attributes