我做了一款 app 可以隨機顯示聖嚴師父的108則自在語。希望對大家有幫助。可在各 app 商店下載，或用瀏覽器安裝。 iOS 14+, macOS 10.11+:https://apps.apple.com/app/id1634911913 Android 6+:https://play.google.com/store/apps/details?id=io.github.myhpwa.sy108q Windows 10+:https://www.microsoft.com/store/apps/9N6PT9RL8P1D Linux:https://snapcraft.io/sy108q PWA 網頁版：https://myhpwa.github.io/sy108qPWA 安裝教學 （這是我之前寫的另一款電子佛典 PWA）：https://github.com/MrMYHuang/cbetar2/blob/master/PwaInstall.md 開放原始碼：https://github.com/MrMYHuang/sy108q

這是一款成語遊戲 + 成語詞典的 app。遊戲部分：可作為聚會遊戲。玩法是出題者，點擊遊戲開始，會隨機由離線成語資料抓題，並依設定答題時間一題題切換。每題成語，出題者不可說出其中任何一字，只能用比手畫腳方式讓答題者猜是什麽成語。如果在限時內，答題者猜中成語，出題者請按綠色勾。若答題者放棄，出題者可按紅色叉跳過或等答題逾時。所有題目完成後，最後會顯示分數，與每題答題狀況。另外有些成語用字較生僻，建議在玩時可以自行判定相似成語為答對。 iOS 14.0+, macOS 10.11+:https://apps.apple.com/app/id1634551497 Android 6.0+:https://play.google.com/store/apps/details?id=io.github.myhpwa.ygig Windows 10+:https://www.microsoft.com/store/apps/9PHK9WGRCL9Z Snap Store (Linux):https://snapcraft.io/ygig PWA 網頁版：https://myhpwa.github.io/ygig 開放原始碼：https://github.com/MrMYHuang/ygig

上個禮拜六、日，我又想到我這款電子佛典 app – cbetar2 可以加什麼新功能。我這款 app 起初是為手機、平板的觸控裝置設計，因此它的 UI 較適合觸控，其中佛經目錄的瀏覽是一頁一層目錄列表呈現，這種好處是每列可以足夠大，方便手指觸控。但操作時想從目前一層往上跳 n 層，就得按 n 次向上鈕，不過這也是不得已的妥協。 然而我這款 app 另一設計訴求就是跨平台，不止觸控裝置可以用，桌機、各種作業系統都可以用。因此此種觸控 UI 在桌機上運作就不是這麼適合，雖然堪用，例如過大的 UI 讓滑鼠的滑動距離變有些長。 後來參照一些桌機用的電子佛典 app，發現它們都使用樹狀目錄，較適合滑鼠操作，這使得我想改造我的 app 支援可切換觸控與鍵鼠 UI。要做樹狀的佛經目錄 UI，首先要有樹狀結構的佛經目錄資料、樹狀 UI 元件，還有將資料轉為 UI 的演算法。CBETA 經文檔有提供樹狀佛經目錄資料，格式是 XML，把它讀入記憶體後，可以作一些處理，產生新的樹狀資料，例如把分開的樹狀目錄資料合併成單一樹狀資料。 “遞迴”是一個操作樹狀結構很好用的演算法，很適合做上述樹狀資料的處理與樹狀 UI 的生成。要了解遞迴如何處理一棵樹，首先可以將樹表示為節點與分枝的組成。一棵樹由根節點開始作分枝，長出子節點。這些子節點又能再分枝長出它們的子節點。而遞迴處理的切入點就是每個節點都做類似的事，以程式來講可以表示為一個 function：每個節點除了作自己負責的事，也可以呼叫它的子節點作事。而這些子節點也是作類似的事，也就是用同一個 function 作事。如此一來只要從樹的根節點啟動 function call，就能讓每個節點都作事。這種 function 呼叫自己的演算法就是遞迴。遞迴還有一重要注意事項，就是在最終端的”葉節點”，要終止遞迴下去，忘了寫這條件可是會造成無窮遞迴。以下為一段遞迴 function 的範例： 有了樹狀資料，接著仍是使用遞迴將它們對應成樹狀 UI 元件即可。但我遇到一個小挑戰，就是我這支 app 是基於 react + Ionic Framework 寫 UI，但…

最近在改良我的電子佛典 app – cbetar2，其中新增一項大功能就是支援匯入 CBETA 經文檔 zip 作離線瀏覽。起初的版本我只在我的 hTC U19e 6 GB RAM Android 手機與 iPad 模擬器測過。但後來發現 iPad 模擬器與實機有一重大差異 – 硬體資源，主要是 CPU, RAM, 儲存空間這些部分基本上模擬器的資源就是開發機(我的 MacBook Air M1 2020)的資源，而不是 iPad 實機的資源。而往往開發機的資源會比實機好上很多，因此這個部分模擬器的表現與實機不同。的確我的 app 在模擬器可以順利運行，但在實機 iPad 6 2 GB RAM 就會當掉。 我的 app 在匯入小檔 zip 時都可以順利運作，但匯入完整 CBETA 經文檔 zip 才會在 iPad 當掉。因此這顯然是匯入時作 zip 解壓縮的部分耗掉太多 RAM 所致。經研究我原本使用的解壓縮程式 adm-zip 只支援一次將…

As discussed on chromium.org in Sep 2018, Chrome iframe has a service worker (SW) inheritance limitation with srcdoc and about:blank. This limitation invalidates the offline and cache capabilities provided by service worker for progressive web app (PWA), if iframe with srcdoc or about:blank is used in PWA. This issue can hurts PWA, e.g., a PWA…

2022/06/02 星期四端午節前夕，搭電車回家的路上，我在想我開發的 CBETA 電子佛典 app 還能支援什麼新功能、作什麼改善？這款 app 之前已支援離線瀏覽，但僅限於整合 Electron app 的版本，若單純用 PWA, 只能用連線版資料庫。因此我就在想有沒有辦法克服此問題。 這問題的影響面涉及 iOS, Android 平台不支援 Electron app (特別是 App Store 禁止此類 app 上架)，因此我的 app 在這兩平台缺乏對離線瀏覽資料庫的支援。這兩個平台的用戶數是主流，因此這是一個值得解決的問題。 起初研究此問題，要先探討可行性，例如現有的系統、程式能不能達成需求，例如經文資料檔要存哪、目標功能能不能用 JavaScript 完成、需要多少時間能做得出來？如果不可能，就不必繼續了😭探討完可行性，就是整理有哪些工要做。 以這次的問題來說，經文資料檔有幾 GB，在 PWA 環境得試著用 IndexedDB 才可能儲存，而實際測試發現不同平台有不同限制。例如在 iOS 把 PWA 新增至桌面後，會限制 IndexedDB 最大空間 1 GB😭、在 Android 讀取 1 GB 多檔案會出現錯誤😭 iOS 的問題，我後來想到經文原檔中排除用不到的檔案，再壓縮後由 3 GB 變為 600+…

我開發的一款”非官方 CBETA 電子佛典 2″ app 近期的重要改進有兩個。一個是支援全螢幕顯示經文、另一個是效能上的明顯改進。 原本 app 在手機上（橫向）顯示的版面如圖： 空間利用不太好，有許多空白處不能拿來顯示經文。這就促使我開發全螢幕閱讀經文的功能。下圖是成品全螢幕模式，完整利用所有空間顯示經文。至於一些 app 功能呼叫，可以利用浮動按鈕（圖中右下一半隱形淡藍色按鈕），雖然目前放的功能不多。 另一個重要改進則是使用楷書字形的效能。之前因為寫 PWA 必須考量各執行環境差異、限制，導致每次載入經文要重新載入楷書字型。這問題源自於 Chrome 瀏覽器的 iframe 無法共享主視窗的 service workers，因此也無法共享 PWA 離線瀏覽的特色。為了避開此問題，我將字型檔存致本地 IndexedDB 作離線使用，在需要時用 JavaScript 載入主視窗與 iframe。但 iframe 的限制只要載入不同卷經文內容，字型就要重新載入，頗消耗電腦效能。特別是後來完整支援全字庫楷書更耗電腦效能，尤其是手機。 這問題存在一年半，一直沒想到怎麼解決。最近突然有想法並作實驗，發現在記憶體快取字型後，字型只須在 app 啟動時載入記憶體 1 次，結果經文載入效能明顯改善。以阿彌陀經為例，原本在我的 hTC U19e Android 手機開啟約 8 秒，使用快取後，降為 2 秒（4倍快！)，幾乎與使用手機內建字型的效能差不多，而且能顯示的字也較多。 以下是各種 app 安裝通路：App 商店安裝：Apple App Store (macOS 10.11+ x86_64 & arm64, iOS…

NodeJS 是一款 JavaScript (JS) 的直譯器 (interpreter) 或執行環境 (runtime)。不過 JS 最早是在瀏覽器 (browser) 上執行的，可用來寫網頁應用程式 (web apps)，後來才有 NodeJS 可以用來開發獨立運作的應用程式 (standalone apps)。 這兩類 JS 直譯器，browser (pure JS) vs NodeJS，雖然都是基於 JS 語言，但卻有一重大差異：除了語法、一部分核心 APIs 相同，但有些核心 APIs 不相同。例如前者獨有網頁相關的 DOM APIs, 而後者獨有檔案系統讀寫 APIs。之所以會有這些差異，源自於它們一開始的定位不同，一種重於 web apps 開發、另一個重於單機程式開發。除了出發點發展的差異，另一種是本質上的限制造成 APIs 差異，例如 web apps 為了確保其安全，瀏覽器不提供它們直接對使用者裝置的檔案作讀寫，而 NodeJS apps 則沒有這限制。因此在寫 JS 時，知道一個 API 是否支援 browser 還是 NodeJS 是很重要的，用錯是基本行不通的。因此常久以來，兩種 JS…

這個假日在練習 React app 支援多語言，使用的是 react-i18next 套件。其實我之前就用它寫了一個範例程式 pwa-react18-redux-i18n-ts-example 放在 GitHub。在使用一項新的程式架構時，我個人很建議先用它寫範例程式、放上 GitHub，接著再用在大程式上。因為大程式往往很吃硬體資源，要較長的編譯時間，系統也複雜不易修改，所以可以避免的話，不建議拿它來實驗一項新程式架構。而把範例程式放到 GitHub 或其它地方也是很重要的一步，將來要用到時，找出來複製、修改比較快，這些看似平凡的程式碼，背後卻有不知花了多少時間才想出的作法！因此它的價值可不要被它的表面低估了，即便是幾10行的程式碼，也可能是思考了1天才想出。 初步熟悉新工具 react-i18next，接著就要把它用在實際的應用上。我想到我可以拿我過去寫的 apps 作應用。我的 apps 可概略分為2類：1類是特定區域的應用，如電子佛典、台灣水庫、台灣藥品…等。另1類則非特定區域，全球都可用的，如幸運輪盤、雙重認證，這一類 app 就很適合支援多語，因此我決定拿幸運輪盤 app 作練習。 練習的過程包括 app 的修改，要把每個靜態字串用動態程式改寫，才可依不同語言傳回不同字串。而每個字串都要有每個語言的版本。甚至 app 要上架至 Apple App Store, Google Play Store, …等，螢幕擷圖裡的文字也要有各語的版本。雖然作這種重複性的事，會有一些煩人😅，所以我只做了中文、英文兩個語言。但考量到 app 的親切度，還是覺得這麼作是有意義的。試想一支只有你看不懂語言的 app，你應該也不太想用。 我這支 app 前端是用 PWA，因此可以直接推送給使用者。而後端則須上架至各 app 商店。截至目前為止，iOS apps, Android apps, Snap apps 都上架成功了。其它還在審查。不過後端變更不大，只是修改 logo，所以即便是從商店裝舊版，前端 PWA 還是最新的。以下是 app 的各個下載連結： 商店下載：Apple…

最近又在 GitHub 練功改程式，我平常滿喜歡作這事的。GitHub 是一個程式碼存放、合作的網路服務。它上面有許多開放的程式專案，可以自由下載、追蹤、討論、修改、貢獻、編譯程式。每個人可以建立自己的帳號，儲存自己喜愛的程式專案。也可以貢獻自己的程式，GitHub 都會有記錄，小到幾行 codes 都算。 GitHub 這種服務很適合服務開放原始碼。我開發的 apps 多多少少會使用開放原始碼，由於它容易取得的特性。而且有許多高品質的開原程式，讓我能快速的開發多功能的 apps。但程式難免會有 bugs 或不合自己使用，開原的好處就是遇到 bugs 時我們較有機會查清程式哪個部分造成的，進一步小 bugs 可以自行修正，但大 bugs 往往還是要向原作者尋求協助。自行修正後，可以把它貢獻至 GitHub 幫助別人，展現自己的實力😄，這可是頗有成就感。 我尤其喜歡在 GitHub 修別人程式的 bugs，因為沒有壓力，不像工作上有時程限制、高品質要求，客戶要的功能要如期做完、不能一堆 bugs。而在 GitHub 上，就沒有那麼重的壓力，只要發覺某程式有 bug，也不必整個程式都看完（程式可能很大），用自己修改的程式能解決問題，我認為就可以貢獻給原作者。因為原作者通常會審合修改的程式，沒問題，才會合併至原程式。有時放膽去改別人程式，就可能有收獲。 我最近就成功在兩個開原程式專案 – electron-builder, AppImageLauncher 作出貢獻、被採納🙂： https://github.com/electron-userland/electron-builder/pull/6841 https://github.com/TheAssassin/AppImageLauncher/pull/510 其中在 electron-builder 的貢獻，就是放膽去改出新功能。另一個 AppImageLauncher 的貢獻是參考基於別人相關的問題研究、解決方案，提出相似的解決方案。其中在 electron-builder 的貢獻我比較得意一點，因為是提出新作法。提新作法能被接納比修正 bugs 有時難多了，一來”新作法”可能跟原系統不太合、或風格不合，可能就不被接納。但 bugs 往往就是比較客觀的東西，它的修正比較容易被接納。 總結我的參與開放原始碼開發的樂趣在於找到自己有興趣的主題、增強與展現自己的實力，又沒什麼壓力。