我與 mobile web – Env. 補完計畫

mobile web 一直都是這些年來的新興的玩意兒, 不過由於 APP 的排擠效應, 以及 mobile browser 的 performance issue, 所以它總是很容易就被冷落到一旁.

現在很多 APP 的開發模式是採用 Hybrid 的方式來組成, 由原生的 native code 搭配 mobile web 的呈現相輔相成, 便可以快速的完成功能開發與佈署, 也就是說 mobile web 可以應用的範圍便更加的寬廣了.

不過同樣的 page 針對不同環境下 (standalone || in app) 的功能或者呈現可能會有所差異, 比方說被內嵌到 APP 中可能 header 和 footer 就不需要呈現, 部分 feature 的操作行為亦有機會需要做調整. 想讓 mobile web 發揮其最大功效的話, 勢必得在環境判斷上下點功夫, 動點手腳.

究竟要如何在最短的時間內達到這類的環境判斷呢 ?!

於是乎便開發了這樣的禁斷咒術, 如同先前的 remPolyfill, 筆者在 navigator 上作擴展, 多了 inAPP 以及 isMobile 這兩個變數來讓我們做此類的環境判斷, 如此一來 developers 便可以透過取得這些變數來讓當前的 mobile web 在長相或者操作上可以更加的靈活變化. 達到力與美兩者兼具的境地.

※ 歡迎點擊下方連結進行觀看 : inAPP: http://mei.homin.com.tw/inAPPProtot…

上方的 demo link 便是透過環境變數的取得, 在畫面中顯示當前環境的狀態, 所以我們可以看到下列三種狀態

使用非 mobile 的裝置進行瀏覽

使用 mobile 裝置, 且為獨立的 mobile browser, 比方說 Safari, Chrome

使用 mobile 裝置, 且當前的瀏覽器被內嵌於 APP 當中

使用方法:

使用方法可以說是簡單非常, 首先, 我們要先把相關的 JavaScript require 到頁面中

inAPP.js 會自動幫我們進行 navigator 的功能擴展, 接下來我們便可以直接讀取 navigator 相關的變數便可以了解到當前的環境設置喔!

  • navigator.isMobile: 用來偵測當前環境是否為 mobile device, 判斷的依據是採用 feature detect, 只要是有支援 touch event 或者是 MS pointer event 的 device, 一律當被認定為 mobile device

  • navigator.inAPP: 用來偵測當前的 browser 是 standalone 或者是 inAPP, OS 對像為 Android 以及 iOS, 採用 userAgent 的差異來做主要的判斷依據, 早期 userAgent 其實蠻亂的, 不過隨著 OS 慢慢的成熟, 其實規則也可以被慢慢的收攏起來, 甚至 google 都出文件告知 developer 箇中差異, 所以筆者便是 follow 這樣的準則進行開發, 由於這類的判斷和後續的維護有一定風險, 這也是筆者將之稱為「禁斷咒術」的主要原因

以上便是 Env. 補完計畫的主要內容, 算是 mobile web 開發的前置作業, 相信有了這些判斷之後, 可以讓 mobile web 揮灑的更加淋漓盡致, 希望對同為 developer 的各位有所助益.

開發出來的東西總是需要透過層層考驗才能成就它的價值, 所以如果在使用上有發現任何問題的話, 請不吝與筆者進行分享與 feedback, 讓筆者將不足或者是缺失的地方補上, 發揮其更大功效, 謝謝

測試環境:

  • OS: iOS 9.x, Android 4.1 ↑
  • Browser: mobile Safari, Chrome for iOS, Chrome for Android, Facebook IM app (iOS), Line (iOS), hipchat (iOS), Android browser

Reference:

轉載文章 – 我與 mobile web – Env. 補完計畫

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *