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 往往就是比較客觀的東西，它的修正比較容易被接納。 總結我的參與開放原始碼開發的樂趣在於找到自己有興趣的主題、增強與展現自己的實力，又沒什麼壓力。

最近工作上接手別人寫的程式。我發現這份程式用了一個我之前不太懂的設計模式 (design pattern)，叫作相依注入 (dependency injection, DI)。由於這份程式多處使用 DI，讓我不得不先了解它，才知道這份程式要怎麼改會比較順利。 我之前就曾接觸、學習過 DI design pattern，但沒抓到其精髓（也就是不知道它的好處），所以後來也不知道怎麼用，也就忘了它。今天在 YouTube 找到一部 DI 的入門教學，那位講者舉了一個好懂的例子讓我了解 DI 的優點。 他舉的例子是汽車製造。一輛汽車由車輪、引擎、…等組成。若一家汽車組裝廠什麼都自己來、包山包海，不止組裝汽車，還製造車輪、引擎、…，這樣是有些缺點的。以組裝的彈性度來看，他們只有自家製造的東西可以選。 但如果這家汽車組裝廠改走另一種策略 – 自己不製造零件，只負責買進零件、組裝。那麼這家汽車廠就能生產更多樣的汽車。汽車的組成依賴於 (depends on) 零件，而這家工廠改變自行製造零件的策略就是解耦相依 (decouple dependencies)，而買進零件來組裝就是注入相依 (dependency injection)。 用一些程式設計的術語來說，DI 這種設計模式讓零件更抽象，零件不再是自家生產的特定型號，可以是任何一家生產的。又由於工廠不再負責零件生產，所以要新型號零件不須更動工廠，只要從外面買進來即可。 回到程式設計， DI 設計模式帶來的優點是：一支經過解耦相依的程式碼不再綁定特定相依，可以透過注入相依的方式輕易替換不同相依的實作。這對單元測試 (unit test) 很有利，我們可以把一些實際運作上很複雜的相依，在測試階段用簡單的模擬相依替代。例如要測試一支圖片讀取程式，實際運作要完整的資料庫與後端程式環境，但有了 DI，可在不更動主程式的情況下，可以寫一支簡單的模擬資料庫與後端程式作相依注入。 解耦相依帶來的另一好處就是不須更動主程式下，支援新的相依，減少主程式因為要作修改出現 bugs 的機會。這實際上的確容易遇到，比如不用 DI 寫的程式，要加入一組新功能，一種作法就是多一個 conditional block，但如果沒注意整支程式怎麼寫，舊有的 conditional blocks 可能就會對其造成不良的影響產生 bugs，也就是 – 你想加新功能的程式碼，還要看舊有功能會不會對其造成不良影響！程式碼少可能還好，程式碼一多就麻煩了！

我最近在研究網路上有哪些免費雲端資源可以學習、使用。意外發現 Oracle Cloud 有提供永久免費的虛擬主機！😄之前一直不太願意開虛擬主機，就是擔心會造成每月一筆不小的金額負擔。現在有免費的，真是讓我手癢想來架什麼 servers。 所謂永久免費是指每個月會有一定的免費雲端資源使用額度，如果超過額度還是要被收費。所以思考後，我認為能架的 server 首先不能”太吸引人”😆，再來還要對自己頗具意義。很反直覺，為什麼不能”太吸引人”？因為要吸引人其實很容易達成，例如我只要架一台 VPN server 免費給大家作跳板，就能吸引一堆人來使用，但接著而來的問題是我的虛擬主機可能資源過載或被別人拿來作非法用途，這我就麻煩了。後來我想到可以架設部落格，這對我很有意義，也滿多人這麼作的。一方面也是展現自己架站的技術能力，另一方面可以用來記錄自己的學習歷程、以後還能回來查詢。 要架站除了虛擬主機，再來就是最好有一個好記的網址/網域。我查到 eu.org 可以免費申請網域！像我申請了 mrmyh.eu.org。但後來覺得不夠滿意，想要一更短又有代表性的網域，所以我在 http://tw 找到申請網域的方法，透過域名註冊商 (domain name registrar) – 中華電信取得 myh.tw 的付費網域。我目前只租了一年台幣800元，因為抱持著試著營運這個站的心態。如果一年下來覺得還不錯，就再續約。 取得網域後，再來就要設定 DNS servers 來管理它。幸好也有免費的 DNS servers – cloudflare.com 或 dnspod.com. 設定方法先是在 DNS server provider 的管理網頁登錄網域 (domain, 如 myh.tw)，會顯示應設定的 DNS servers，把它們記下，並且新增一組 A record 將 hostname (如 www.myh.tw 或 myh.tw) 指向虛擬主機的 public IP。再到…