口罩地圖開發思路

前言

2/6 要實施購買口罩實名制的政策，前一天我對同事發表了「明天晚點到公司宣言」，口罩即將用盡的我，勢必得在政策實施的第一天補充庫存，雖然每個人只能選購兩片，但大家都有把髒內褲翻過來當作新的來穿的經驗，兩片口罩撐一週當然沒問題，翻過來又是一條好漢。（開玩笑的，正確配戴方式請查閱衛福部：口罩應反過來配戴？）

當我要查詢附近特約藥局時，發現民間做的口罩地圖服務被大流量灌爆，甚至有人吃了一張 Google 的 60 萬元帳單。這件事應該是要被解決的，於是興起動手做一個的想法。

需求分析

1. 容易上手
2. 資料齊全
3. 美觀
4. 效能好
5. 穩定
6. 夠即時
7. 降低困擾

容易上手

身為 Android 手機的使用者，我希望體驗最好能像 Google Map，避免額外的學習成本。剛好我有 Google Map Mobile SDK 的使用經驗，接下來只要模仿 Google Map 的介面即可達到目的。

資料齊全

衛福部有提供特約藥局清單，以及藥局口罩庫存開放資料，有這兩份資料就可以顯示藥局及口罩資訊，剛好零時政府有善心人士將藥局清單補充了經緯度，地圖應用的先決條件便滿足了。

美觀

一開始只想到模仿 Google Map，但資料內容還是有所差異。此時發現前端社群發起了口罩地圖的 Side Project，廣邀大眾投稿，只要標示設計師的姓名就可以使用對方的設計。因為設計有針對性，外觀及體驗都比自己想的要來得好；順帶一提，我最後是參考 Penny Yang 的設計，我很喜歡此設計中口罩數量的呈現方式。

效能好

其實可以預期在地圖上放一堆藥局會造成畫面卡頓，但經歷過停車大聲公與車麻吉的地獄磨練，地圖相關應用的奇技淫巧是我的專業之一，不成問題。

穩定

這裡並非指造成閃退的程式錯誤（當然這也很重要），而是資料來源的穩定性與內容變動。大流量的關係，會擔心源頭被打趴，沒有資料的 App 毫無用武之地，之前蔬果行情站就遇過源頭的伺服器掛掉，導致顯示錯誤，當時被使用者罵翻；而內容變動是預想到政策改變（或其他因素）後，資料可能改格式導致解析錯誤，這也會造成 App 無法使用。資料來源的穩定性是透過熱心人士寫程式定時異地備份，有效為政府提供的開放資料做了分流，若分流掛掉，到時也無所謂了（？）。至於資料改動，解決方法還是得另外做資料中介，統一生成 App 可以解析的格式，但這次應該沒時間做，只能期待熱心民眾提供了。

夠即時

目前分流是每分鐘抓取一次最新的政府開放資料，App 則是設定 120 秒後自動重抓資料，盡可能降低分流的負擔，也確保顯示內容的新鮮度，但這兩件事本來就是互斥的，其實也滿難取捨。

降低困擾

這是上線數天後所發現到的狀況；遭遇困擾的人分為兩類：購買民眾以及藥局工作者。開放購買後幾天有民眾高頻撥打藥局電話；我不希望藥局的人因此而遭受額外的壓力，這部分的處理是：我將電話號碼藏在最深的介面裡頭，使用撥打功能也會出現警語。接著是庫存與實際狀況不符的問題，最常出現的是：發放號碼牌機制導致顯示還有存量，但實際上的庫存已經被持號碼牌者預定，在過卡完成前，使用者可能被顯示的庫存數吸引，但實際上藥局已無法再銷售，這也造成藥局被民眾質疑屯口罩。這問題沒有程式最佳解，只有補救方法：我打算加強文案宣導，並提供資訊回報功能以降低誤解狀況，這是我覺得最無力的部分，因為自己的專業無法從癥結點解決。

成果

下載連結

防疫資訊站 - 實聯制掃描、確診資訊、全國快篩站、口罩資訊地 - Apps on Google Play

Provide relevant information and tools during the epidemic

play.google.com

開放原始碼

GitHub - jarvislin/drugstores: Provide Covid-19 information in Taiwan.

Provide Covid-19 information in Taiwan. Contribute to jarvislin/drugstores development by creating an account on GitHub.

github.com

後記之一

口罩地圖上架了，但口罩還是沒買到。

後記之二

這次約花了三十小時上架最小可行性版本，其實想做的功能還很多，像是：加上藥局營業時間、政府文宣或是收藏功能等。

後記之三

應用程式上架隔天，政府的資料內容就變了，真是一語成讖。因為「成人口罩總剩餘數」被改為「成人口罩剩餘數」，導致資料解析失敗；應用程式於版本 1.1.1 緊急修改，解析為新的格式，但問題本身還是沒有解決，比較像頭痛醫頭，腳痛醫腳。幸好中介資料已經有人提供，可以從問題根源解決，於 1.1.2 修正。

後記之四

延續後記之三，中介資料提供者手動修改資料時，將其中幾筆資料放上了錯誤內容（經緯度變成營業時間，即 Double 變 String），造成 App 解析錯誤；在第一時間回報了中介資料提供者後，對方緊急做了資料還原，為了避免再次發生，決定在 App 加入防禦性程式設計（Defensive Programming）；將所有資料轉成字串型態（String），待確定內容可以轉換成預期的型態後，我再使用這筆資料，不符合的就捨棄掉；這會漏掉幾筆內容，但至少 App 還是可以檢視其他正確格式的資料，不會其中一筆錯誤就導致全部都不能瀏覽，修改於 1.1.4。