我們所開發的網站應用大多時候都是預設給多人同時上線使用，但是你要怎麼確認這個網站能夠容納多少人同時上線呢？網站負載壓力測試(web performance testing, web speed testing, load testing)就是模擬許多使用者同時上線存取網站內容，並記錄網站的反應時間以及超出負荷而當機的上限。
網站負載壓力測試工具中較為知名的跨平台工具是Apache JMeter，但它的設定較為複雜，操作門檻高。所以我用Electron另外開發了一個簡單版的網站負載測試器Electron Web Speed Test ，希望讓大家更容易測試自己網站的負載容量。
(more...)之前我介紹用HTML撰寫的混合應用程式框架點閱數意外的很高(本社比)，藉著2018年底停車場的薑黃喵被好心人收養之際，我用混合應用程式框架開發了「薑黃喵討摸摸」的APP，可以在網頁開啟、Windows直接執行、也已經在Google Play上架，可在Android上安裝。這篇就記錄一下這個「薑黃喵討摸摸」APP吧。
(more...)書籤小工具(bookmarklet)是一種可以在任意網頁上執行預先寫好的JavaScript程式碼的做法。舉例來說，當你想要用console來撰寫jQuery語法來調整資料顯示結果時，卻發現該網站並沒有載入jQuery函式庫，這時候就可以用書籤小工具來為這個網頁載入jQuery函式庫，讓網頁工程師更方便到處測試。
我把載入jQuery函式的書籤小工具做成了書籤小工具產生器。除了預設的「Load jQuery」書籤小工具之外，你也可以自訂書籤小工具的名稱與JavaScript程式腳本的內容。讓我們來看看怎麼使用這個書籤小工具吧。
(more...)
HTML5 (JavaScript + CSS3)可以在網頁上跨平臺執行已經是眾所皆知的常理，但是要如何用HTML5來開發能在瀏覽器上執行、能夠在桌面作業系統上安裝、還能夠在行動裝置(手機、平板)上安裝的應用程式呢？這個OnsenUI+Vue.js+Electron+PhoneGap Build的「混合應用程式框架」就是我的答案。
因為這只是最近心血來潮整理出來的混合做法，架構上並不是很漂亮，我也沒有打算寫太多文件。但對於想要發揮HTML5極限的開發者來說，應該是個不錯的參考。
混合應用程式框架保存在GitHub中，任何人都可以自由下載、修改、發佈。
在混合應用程式框架中，我們只要開發一個HTML5框架，就可讓它以在網頁瀏覽器、桌面端應用程式、行動端應用程式執行。你可以實際玩玩看，看看混合應用程式框架會是什麼樣子：
接下來我用以下幾張截圖跟照片來讓大家看看它在不同平臺上的樣子：
這是在Chrome網頁瀏覽器上的畫面。
這是在Windows桌面端執行的畫面。
這是在Android手機上執行的畫面。
這個是在Android平板 (8吋)上執行的畫面。
除了一些元件的位置怪怪的之外，大致上畫面都能夠正常呈現，很不錯吧。
接下來就讓我們來看看混合應用程式框架怎麼做到這件事情的吧。
我把「混合應用程式框架」的架構整理成上面四個層次：顯示畫面 (Display)、平臺轉接(Platform Transport)、裝置(Client Device)、作業系統(Client Operation System, OS)。其中藍色的部分是我們可以掌握的元件，而灰色的部分對應不同使用者會用的客戶端。以下說明顯示畫面跟平臺轉接的細節。
這邊使用的是Onsen UI，一個成熟的HTML5顯示框架。而控制資料邏輯的MVVM架構使用的是Vue 2。
我已經在「政大借書籃」跟「Voc4Fun全民樂單字」使用Onsen UI框架，但那時候Onsen UI只有跟Angular.js整合。現在Onsen UI已經開發到第二版，而且可以跟jQuery、Vue 2整合。
站在一個想要追求快速開發的角度，Vue算是相當好上手的MVVM架構。而這裡我選擇的是不編譯的Vue架構，因此可以直接在瀏覽器上執行，不需要任何打包或封裝。
混合應用程式框架基本上可以直接用網頁瀏覽器開啟，但如果要打包成不同裝置上可以安裝的應用程式(APP)，我們需要藉助一些平臺轉接的框架。
(圖片來源：維基百科)
為了產生可以在桌面端作業系統安裝的應用程式，我們使用的是GitHub開發的知名框架Electron。
Electron可以產生給Windows、Mac OS、Linux使用的應用程式。這邊我主要只用Windows，Electron會在Windows平臺中產生可執行檔案，我寫了AutoIT將設定包裹成exe檔案，讓使用者可以直接點選執行。未來也可以更進一步使用InnoSetup打包成安裝檔。
至於Linux跟Mac OS我則沒有測試過，Linux可以直接用Electron打包，但我沒試過能不能執行。至於Mac OS，則必須要在Mac環境下打包才能使用，因此我也沒有試過。
之前我已經在「試做Electron桌面應用程式：webapp-wrapper」整理了一個簡單的基礎，現在我把它整合到混合應用程式框架中，讓Electron更容易將HTML5打包成桌面端應用程式。
(圖片來源：boston technology)
為了產生可以安裝在行動裝置上的應用程式，包括手機、平板，我們使用的是PhoneGap Build。
PhoneGap Build提供了將HTML5程式打包成Android、iOS、Windows Phone三種平臺APP的功能。不過因為建構iOS APP需要具備開發者身份(每年需繳交不少費用)，而Windows Phone已經沒落，所以實際上我只有用PhoneGap Build打包成Android APK而已。
我以前就有在「PhoneGap網頁樣板：簡單建立網站APP」寫過使用PhoneGap Build來建構網站APP的做法，跟Electron一樣，我也把它整合到混合應用程式框架中，成為大框架下的一份子。
值得一提的是PhoneGap Build雖然採用的是Apache Cordova核心，但這個名稱卻是描述在Adobe提供的伺服器上打包APP的整個流程，而不是像是Cordova在本機端部署環境、打包應用程式的做法。
在混合應用程式框架中，我整理了一些在開發中可能會用到的功能，這是為了未來開發做的準備。這些功能包括了作為一個應用程式(APP)所需要的排版(包括主畫面、上方的工具列、左方的滑動選單)、主畫面的換頁、通知對話視窗、開啟外部連結、儲存由JSON產生的試算表檔案ODS、MVVM資料綁定、國際化語系、以遊戲引擎運作。以下簡單說明這些功能。
混合應用程式使用了行動裝置為主的APP排版，主要畫面分成3大部分：1. 主畫面、2. 工具列 (toolbar)、3. 滑動選單 (sliding menu)。主畫面顯示該頁的主要內容，工具列會一直固定在畫面上方，而左邊的滑動選單則是會隨著你的畫面寬度動態的顯示、隱藏，你也可以按下工具列的選單按鈕來顯示滑動選單。
受益於OnsenUI的Auto Style功能，功能元件在不同平臺上會有些微的不同。舉例來說，下圖是iOS中的工具列：
下圖則是Android中的工具列：
我把換頁的方法包裝在onsenui_helper中，JavaScript語法如下：
onsenui_helper.switch_page(about)
混合應用程式框架的使用了OnsenUI的$ons.notification功能來實作對話視窗。
受益於OnsenUI的Auto Style功能，上圖iOS風格的對話視窗在Android底下會變成下圖這個樣子：
通知功能的JavaScript語法如下：
vm.$ons.notification.confirm({ message: i18n.t("Are you sure to visit About?"), callback: function (_result) { console.log(_result); }
});
點下一些非APP內的連結時，混合應用程式框架提供了一些方法來讓他使用你預設的瀏覽器開啟。這部分我用hybird_app_helper來處理不同平臺的做法，JavaScript語法如下：
hybird_app_helper.open_window('https://github.com/pulipulichen/HTML5-Hybird-APP-Framework')
這邊使用了JS-XLSX套件來讓JSON物件轉換成ODS試算表格式。JS-XLSX的功能複雜，網路上大部分的教學都亂七八糟，最好的用法還是官方自己提供的上傳分析與轉換下載範例。我整理了JSON轉換成ODS Base64編碼的做法，寫在xlsx-helper.js檔案中。
另外的問題是如何讓裝置下載，或是說儲存、分享檔案。在網頁上，我使用的是FileSaver.js。在桌面端，我使用了Electron的ipcMain跟ipcRenderer來交換資料，讓網頁介面跟背後的Electron能夠彼此溝通，交給Electron寫入檔案。雖然Electron端已經很複雜了，但比不上在行動端的麻煩。在PhoneGap Build中，我先用cordova-plugin-file將ODS檔案寫入到cache暫存資料夾，然後使用PhoneGap / Cordova Social Sharing plugin來分享檔案。
混合應用程式框架使用了Vue.js的MVVM框架讓資料與顯示雙向綁定。主畫面中的「Hello, world!」綁定的是JavaScript中的「main_page.data.message」。顯示的程式設定如下：
而這個「main_page.data.message」則是寫在main_page.js中，資料的程式設定如下：
只要修改「main_page.data.message」的值，顯示畫面也會跟著改變。這是Vue.js這種MVVC框架的基本應用，相信熟悉MVVC框架的開發者應該很容易理解。
混合應用程式框架使用了javascript-i18n-core來作為語系檔的框架。以工具列中間的標題為例，我們可以用這個JavaScript語法來取得索引名稱「TITLE」的翻譯設定如下：
{{ i18n.t("TITLE") }}語系檔放在www/locale資料夾中，裡面可以設定各個語系與對應索引名稱。
為了挑戰混合應用程式框架的極限，我試著加入了Cocoon.js遊戲引擎框架所開發的兩款展示遊戲：SpaceSimDemo跟Super Mario Bros。
大家可以看看混合應用程式框架在網路瀏覽器、桌面端、行動裝置上玩遊戲是什麼感覺，也許未來也可以取代OnsenUI，使用Cocoon.js開發遊戲呢？
混合應用程式框架只是我為了未來可能會開發真正的跨平臺應用程式而做的一個小小的準備。我怕我現在不整理，以後可能就會忘記，所以做到這邊就趕快記錄一下。
(圖片來源：幫趣)
這整篇並沒有什麼提供給開發者的文件，請有心要使用這個框架的開發者自行trace code，程式碼都在GitHub上，請自行研讀、fork或下載吧。
接著來聊聊一些開發過程的想法。
混合應用程式框架實際上是要寫UI顯示畫面邏輯、 Electron跟桌面端底層作業系統的溝通、PhoneGap Build跟手機端底層裝置溝通的龐大架構。雖然都是用JavaScript來寫，但是不同框架下面使用的API都完全不一樣。雖然號稱跨平臺，但是還是要為不同平臺下很多功夫，實際上並沒有真的這麼跨平臺。
現在有很多開發框架是更加的跨平臺，像是Unity，但畢竟這個門檻比較高，不能直接將網頁使用的技術帶過去使用。而且對快速開發來說也不見得是比較方便。
用網頁來寫UI還是可以讓開發者有很大的自由度，特別是現在CSS3發展成熟，許多特別的UI介面又漂亮又好用，還能作出驚人的特效。我想未來我還是會繼續使用網頁來開發任何應用吧。
在開發的過程中很多人會問的是速度問題，這是PhoneGap令許多開發者詬病的問題。這個速度問題其實細分起來有兩個層面。第一個是載入，PhoneGap在開啟程式的時候，需要用「document.addEventListener("deviceready",function () {});」來確保cordova核心套件有正常載入，因此不管硬體效能多好，通常載入時間還是需要0.5秒。
一般來說我們會使用splash載入畫面讓使用者不會覺得太過突兀，在混合應用程式框架中也會預設使用icon.png作為載入背景畫面。
另一個問題是畫面運作時的流暢度。在Ionic Framework vs React Native Comparison這個影片中，我們可以看到基於Ionic Framework包裝的應用程式運作效能非常的差，已經到了妨礙使用體驗的程度了。但這個問題通常是因為程式寫的不好，最常見的情況，是因為開發者在轉場動畫上使用連續改變物件位置參數來營造動畫感，這卻是相當不流暢的做法。
現在比較好的做法是採用較好的顯示畫面框架，像是Onsen UI。或是根據How to Make High Performance PhoneGap Apps來修正你的程式架構。不過光是混合應用程式框架現在的架構，在各個平臺運作起來就已經很流暢了，我想就一般的應用程式來說是已經足夠使用。
如果要到玩遊戲的話，雖然看起來是可以運作Cocoon.js這種遊戲框架，但是還是不知道它的流暢度極限到底在那裡。但因為我可能比較不會朝遊戲的方向開發，這部分就待有心人士來測試吧。
比起原生應用，我仍然比較偏好可以跨平臺的框架。
儘管許多知名的框架號稱自己是跨平臺，但其實也都是限制於行動裝置的平臺或桌面端的平臺，並不是真的能夠橫跨網頁、桌面端與行動裝置端，這也是我做這個混合應用程式框架的動機。
大部分的跨平臺框架有許多門檻，像是React Native跟NativeScript。當然，這些門檻在混合應用框架裡面也是難以避免。
第一個門檻是編譯。幾乎現在主流的跨平臺框架都需要先進行編譯，然後才能展示最後的成果。只要框架使用了作業系統上的原生UI，幾乎都需要編譯後才能使用。React Native提供了Hot Reloading減少重複編譯的問題，但是還是需要部屬相關的編譯環境。相較之下，混合應用程式框架藉助了Adobe PhoneGab Build來編譯行動端的應用程式，我們只要用Git或壓縮成zip上傳即可，部屬環境不需要煩惱。但是如果要用Electron編譯成桌面端應用程式，那還是要用npm來安裝Electron需要的環境。Electron編譯環境所需要的指令請看README說明。
第二個門檻是API。雖然框架提供了跨平臺都能使用的UI API，像是特定的按鈕、特定的工具列寫法，但這個框架的API常常已經有別於傳統網頁的做法，並非一般網頁開發者所謂的HTML5，幾乎等於你要重學一個語言。而這語言使用的API並不能帶到其他平臺上，像是網頁或桌面端的Electron，因此不能說是真的跨平臺。儘管混合應用框架本身也用了OnsenUI跟Vue.js等框架，讓人需要重新學習這些框架的用法。不過至少OnsenUI上所寫的工具列是真的可以在網頁、桌面端跟行動端正常顯示，而不會被原生UI的限制所綁架。
相較於行動裝置端有許多大紅大紫的知名跨平臺框架，桌面端的跨平臺框架倒是只有Electron比較知名。混合應用程式框架也是使用Electron來實作桌面端應用程式的跨平臺開發。
然而，Electron最大的問題，還是它編譯出來的檔案大小實在是太大了。在www中的主要程式其實只有16MB左右，但混合應用程式框架最後編譯出來的檔案大小居然來到136MB，壓縮成7z也還有35MB之多。網路上有許多人對Electron檔案大小感到疑惑，Expected app bundle size? 中zcbenz說就是這樣大小，沒辦法。我也覺得很無奈。
剛好今天看到了新的桌面端跨平臺框架出現：Vuido，這是用Vue.js撰寫桌面端應用程式的框架，可以使用桌面端原生的UI元件，而不是像我使用混合應用框架中實際上是寫一個網頁來模擬UI介面的做法。檔案大小似乎比Electron還要小，速度上也應該會比Electron還要快吧。不過我個人還是比較喜歡寫網頁，用網頁做UI介面，因此應該不會選擇這個方案，還是繼續使用Electron吧。
好啦，混合應用程式框架就聊到這邊了。
你有想過要開發跨平臺的應用程式嗎？以前你都是怎麼做的呢？除了像混合應用程式框架使用的OnsenUI + Vue.js + Electron + PhoneGap Build之外，你還知道什麼不錯的框架嗎？對混合應用程式框架什麼問題的話，歡迎你在下面的留言發問。如果你也覺得混合應用程式框架是個開發跨平臺應用程式不錯的起點，請幫我在AddThis分享工具按讚、將這篇分享到Facebook等社群媒體吧！感謝你的耐心閱讀，讓我們下一篇見。
(more...)(圖片來源：e-Tutorial World)
文本分析時常會用到詞性(Part of Speech，簡稱POS)作為判斷依據。現在流行的中文斷詞器結巴(Jieba)具備詞性判斷的功能，這篇將整理56種詞性標記代號的意義，並加上標點符號的自訂詞典以補足結巴無法辨識標點符號的問題。此外，結巴僅會將英文詞性標示為「eng」，這難以用在中英混雜的文本中。因此我又另外找了Node.js上的pos函式庫，這是基於Mark Waston的FastTag詞性標註演算法，能夠為英文字分辨出45種不同的詞性。
(more...)這是一個將CSV格式資料轉換成關聯式資料庫插入表格與資料SQL語法的網頁工具。可適用於SQLite、PostgreSQL與MySQL等關聯式資料庫。傳統做研究時比較常用Excel、SPSS等試算表資料，但其實加入到資料庫之後，就能更容易跟其他資料交互比對、分析，也能用資料庫內建的聚合函數(aggregate functions)計算平均數、標準差等統計常用的資料中心與離度，讓資料分析更容易處理喔。
(more...)這是2016年年初我與學弟共同開發的單字學習行動應用程式，名為「Voc4Fun 全民樂單字」。這個應用程式包含了客戶端 voc4fun-client 跟伺服器端 voc4fun-server，全部在GitHub儲存庫保存。該程式的客戶端是以Onsen UI 2開發，並可能夠直接使用Adobe PhoneGap Build來封裝成APP。而伺服器端則是我用RedBeanPHP開發的特製Log型資料庫，以詳細記錄各個行為歷程細節，再用view視圖功能做成普通的資料表。
這篇就為全民樂單字 Voc4Fun的功能做個介紹，記錄我做過的這個單字學習行動應用程式吧。
(more...)畫了一張圖、拍了漂亮的照片，還可以做什麼加值應用呢？我參考Venkat Pola的程式碼，將我很喜歡玩的遊戲「滑塊拼圖」做成了可直接在瀏覽器執行的線上遊戲，而滑塊拼圖的圖片還可以由使用者自訂喔。這篇就來說明我做的這個滑塊拼圖遊戲吧。
說到編輯HTML的編輯器，你會想到那個工具呢？純寫程式碼用的Sublime Text、Notepad++？給不會程式碼用的Word轉存HTML格式？混合編輯的Dreamweaver？真要我說的話，目前我看過最好、最乾淨、各種編輯器之間轉換最漂亮的編輯器，就是TinyMCE。
TinyMCE一般只是作為網站裡面將<textarea>轉變為所見即得編輯器的小工具，能像是編輯Word一樣地編輯HTML網頁，最後產生的HTML程式碼又乾淨又漂亮。我因為太常使用TinyMCE來編輯HTML網頁程式碼，特別是表格的編輯，所以乾脆索性把TinyMCE做成獨立的布丁版TinyMCE編輯器，讓人需要的時候就直接打開網頁、使用TinyMCE編輯網頁吧。
如果要用試算表資料搭配有格式的文件，批次地產生大量檔案的話，要怎麼呢？Word為主的合併列印方案都只能在單一檔案中產生許多重複範本的內容，不符合我的需求。於是我乾脆重新寫一個能夠以CSV試算表檔案搭配HTML網頁範本產生合併列印效果的線上版合併列印小工具：HTML Mail Merger。它會讀取CSV中的欄位資料以及檔案名稱(filename)欄位，以此批次產生取代以大括弧「{}」夾住的佔位符號和指定檔案名稱的檔案。合併列印再也不用仰賴Word，直接線上就處理完成吧。
(more...)
現在很多網頁內容都是以動態的方式產生，例如Facebook會在開啟網頁之後再來讀取網頁內容，就連「布丁布丁吃什麼？」也是在網頁開啟之後再來慢慢載入旁邊的小工具。這種使用AJAX技巧來調整畫面的網頁，雖然便於一般使用者用瀏覽器查看，但是卻會造成伺服器端用程式抓取網頁的困難。
還好，現在我們可以用Node.js寫成的虛擬瀏覽器PhantomJS來幫我們載入完整的網頁內容。為此我寫了一些搭配PhantomJS使用的命令列腳本，讓我們可以在Linux 32位元環境下以指令端擷取指定網址，並配合jQuery選取器抽取出需要的網頁元素，最後直接回傳顯示在螢幕上。
(more...)
這是我為了文本探勘所撰寫的一個小工具。有些文字會在固定的寬度斷行，就像是BBS的畫面一樣。這樣文字探勘時會對句子、斷詞造成誤判。因此我寫了一個文字檔案斷行連結工具來將文字斷行的地方重新連接成一行。整理後的文本就比較容易進行後續的分析了。
(more...)
將試算表表格的直行與橫列的資料彼此交換，這種操作叫做「轉置」(Transpose)。大多試算表都有提供資料轉置的功能，包括Excel、LibreOffice Calc或Google試算表。但只是為了做個簡單的轉置，每次都要開啟試算表這種大工具不免讓人麻煩，而且轉置指令也常常藏在深處，我每次都會忘記。所以我乾脆做一個線上轉置資料的工具，讓大家用網頁就能夠轉置純文字的資料！
(more...)
在寫程式或是處理資料的時候，有時會需要文字資料限定只能為英文與數字，中文、空格等其他字元都要替換成「_」之類的符號。這可以用正規表達式來完成這個目的。所以我就寫了一個線上英文與數字過濾器，只要貼上文字或上傳純文字檔案，就能產生一個只剩下英文與數字的文字檔喔。
(more...)
有時候文本探勘會需要比較文章前、中、後各個不同位置的寫作風格是否有所差異，所以我寫了一個純文字線上的分割器，可以將一篇很長的純文字檔案切割成多個小的文字檔。這個做法跟分割壓縮檔不太一樣，分割之後的個別檔案都是獨立的文字檔喔。
(more...)
很多人會希望在閱讀網頁的時候也能像是紙本一樣畫重點。雖然我以前做過閱讀知識合作標註學習系統KALS可以做到這功能，但它太過龐大、老舊，而且畫重點前還需要註冊，使用上諸多不便。我後來發現AnnotateIt之類的新形態網頁標註工具開始採用了Rangy選取函式庫，它使用現代瀏覽器支援的選擇功能，能夠從根本上改善KALS的問題。所以我就用Rangy做了一個簡易的單機版網頁標註外掛：Rangy Highlighter Cookie。網站架設者只要在HTML程式碼中嵌入JavaScript就能夠使用。標註的資料直接儲存在使用者個人的Cookie中，不需要登入或仰賴其他伺服器。雖然功能簡單，但這可以解決大多人在網頁上畫重點的需求，也是為了未來發展複雜功能所做的一個基石。
(more...)
我在KALS專案中有用到以jQuery動態載入CSS的技巧，但是最近在Chrome上卻意外不能執行。研究之後才發現這是因為我在載入CSS途中去修改CSS載入標籤的title屬性，造成CSS載入失敗。解決方法是應該在建立載入CSS的標籤時就加入title屬性，而不要事後修改。
(more...)
這學期準備教材的時候，我想要製作一組隨機的通訊錄。我找到了可以一次產生大量姓名的中文姓名產生器，但是這個電話號碼&手機號碼生成器卻一次只能產生一組，不太方便讓人一口氣製作大量通訊錄資料。所以我乾脆自己手動寫一個手機號碼批次產生機，方便用來製作大量的隨機通訊錄。
根據電話號碼產生&手機號碼生成這篇的設定，臺灣的電話號碼開頭4個數字其實是有一定的範圍，其變化有：0910、0911、0912、0913、0914、0915、0916、0917、0918、0919、0920、0921、0922、0923、0924、0925、0926、0927、0928、0929、0930、0931、0932、0933、0934、0935、0936、0937、0938、0939、0952、0953、0954、0955、0956、0958、0960、0961、0963、0968、0970、0971、0972、0982、0986、0987、0988、0989，總共這48種變化而已。
為了避免這個行動電話隨機產生器被誤用，所以以下所產生的號碼的前4碼將會避開這48種變化，這樣產生的號碼也就不能實際撥打，只能作為練習展示用而已。
很久以前我就在一篇文章裡面提到，我一直很想用Bootstrap來將Blog的版面重新修整。而自調整之後已經過半個月了，現在讀者們看到的這個樣子就是改版後的結果。這篇就跟大家來聊一下這次的改版。
(more...)
這個月受邀到中華電信學院演講一門微課程「從網頁開發到Android APP行動應用程式開發」。這是給有HTML5基礎的前端網頁設計師開發Android APP的教學，講述AppsGeyser跟PhoneGap (Apache Cordova)的開發方法。
本次微課程將介紹如何從前端網頁開發技術進入到行動應用程式(APP)開發的領域，特別適合具備前端網頁開發能力的工程師來聆聽。演講內容將概述各種行動應用程式開發的技術，再聚焦到以網頁技術來開發行動應用程式的兩種方法：AppsGeyser 與 PhoneGap。只要會製作行動版網頁，聽完這個演講，您就能夠製作可以上架的行動應用程式！
投影片下載：Google Drive、OneDrive、Box.net、SlideShare
備註：由於當天演講時間太短，所以投影片有所刪減，這一份則是完整的版本。
這次的演講跟以往大家講述APP開發的內容相比，有幾個比較值得一提的地方。
以往大家對APP開發方法的分類只有三種：「原生型APP」、「網頁型APP」、「混合型APP」。但其實這是從PhoneGap的觀點來看APP開發方式，並不能夠含括所有的APP開發方法。
Wikipedia的Mobile Application development給我們一個比較完整的分類：前端型、後端型以及系統型。而前述的三種分類則是隸屬於前端型開發中。而我又進一步將前端型開發方式分類成四種開發方法：
我試著用這個分類來讓學員瞭解自己適合的開發方式，讓大家知道原來除了原生型開發方法之外，還有很多其他的途徑可以開發APP。
市面上已經有很多書籍在講PhoneGap開發了，那我講這個PhoneGap開發豈不是再次老調重彈？實際上我這次講得內容並不是單純的PhoneGap開發，而是使用Adobe PhoneGap Build來封裝APP。
如果你仔細比較一下PhoneGap的開發方式，會發現他要做的前置作業就跟開發原生型APP一樣複雜。實際上也是如此，因為PhoneGap就是基於原生型APP之上在添加的功能。如果要開發Android的APP，就要先佈置Android的開發環境；如果要開發iOS (iPhone或iPad)的APP，就要先佈置iOS的開發環境。教過MIT APP Inventor之後，我覺得這種要花很多時間才能進行開發的方式並不利於教學。
而這個Adobe PhoneGap Build則是一種雲端服務的開發環境。我們只要把PhoneGap專案準備好、上傳，就能夠封裝成各種平臺的APP。這大幅度地降低了開發環境的配置需求，只要瀏覽器、能夠撰寫HTML的工具(像是ATOM)，我們就能夠開始開發了。
然而，PhoneGap專案跟上傳到PhoneGap Build的專案內容其實有很多的差異，但是卻很少人在介紹如何製作PhoneGap Build的專案。尤其是加入簽署檔案(.keystore)讓APP可以上架的這些細節更是很少人提及，這也是我這份演講比較獨特的地方。
這篇演講介紹了jQuery Mobile、Dojo Mobile跟Sencha Touch這三種行動網頁框架。但我想要強調的是「佈景主題」(theme)的問題，也就是如何能在該平臺上呈現該平臺的使用介面的能力。我讚賞Sencha Touch對於佈景主題的自動偵測與切換，在Android上他是Holo Dark的風格，在iOS上則能夠維持iOS的風格。
這種能夠相應於該系統而自動切換佈景主題的功能，對於使用者體驗(User Experience, UX)來說至關重要。這表示使用者可以在自己的系統上操作熟悉的UI，而不是APP特立獨行的佈景主題。
Dojo Mobile跟Sencha Touch都有不同的主題可以套用。雖然jQuery Mobile也可以找到一些第三方主題使用，但比較麻煩。至於其他的Bootstrap、Semantic UI、Ionic、Angular Mobile等行動網頁框架就更是如此。
不過實際開發時，應該還要考慮到這些框架跟後端資料庫做交換的方式、是否能夠整合其他JavaScript函式庫、或是語法是否容易理解等問題才是。也許隨著經驗越多，這個看法也會隨之改變吧。
在準備這個演講的同時，我也一併在進行MIT APP Inventor的家教。我本來以為這兩件事情可以合併在一起做，但仔細想想之後還是放棄這個念頭。APP Inventor是給不會寫程式的人來學習的，做完的成果難以到實際應用的層次。這次的演講是給擁有網頁基礎的人來聽的，主要要講網頁技術跟APP之間的關聯。所以最後我是分開來做這兩件事情。
這個微課程只是一個先導性的簡介，之後會在安排一整天的工作坊，讓學員能夠一步一步地製作行動版網頁、以PhoneGap Build封裝，然後到Google Play上架。
儘管這次的教學跟我的專業有很密切的關係，而學員的程度也都很高，講的內容也可以深入不少。但我自己也擔心起實務經驗上是否有所不足，畢竟我跟專門開發APP的工程師相比，還是有很大的差距(這就是學界與業界的差別啦)。雖然是這樣說，懂得如何做一個非常複雜APP的知識，跟如何讓學員瞭解製作APP的教學方法，這兩件事情仍然是不太一樣。
接下來要努力準備工作坊的內容，加油！
(more...)
Comments