瘋狂詭宅第二版：戰報(4)

瘋狂詭宅第二版：戰報(4)

Date: 20220821

Version: 1

1. 一樣的劇本「永世輪迴」，這次就是正常單人2隻角色開局，選擇力量偏高，其他素質較平均的角色。
2. 這場約為80分鐘打完，只能說在某些時候運氣很好，沒有扣太多傷害，有一次是扣4點傷害，結果都是輕微，爽~~
3. 救了管家，分左右兩邊開圖，右邊找到門，左邊找到鑰匙，路途上還算順利，每隻怪物大概打2次就死了，有的1拳就死了，最後魔法陣大約2回合就解了，路途中遇到星之眷族，差點嚇死！！
4. 完全不想打，還好已經拿到劇情道具，兩隻角色都順利躲避，趕到大廳走出別墅，順利通關了，之後就可以體驗第2個劇本了，預計等3個劇本通關後，再去買擴充吧！
5. 
   
   
   
   

瘋狂詭宅第二版：戰報(3)

瘋狂詭宅第二版：戰報(3)

Date: 20220813

Version: 1

1. 周末放假來玩一局吧~劇本一樣還是「永世輪迴」，不過做了點調整只使用1個角色移動，系統預設最少是兩隻角色，所以我這隻可以做4個動作，另外，神秘階段判定若指另一支角色時，判定還是本角色。
2. 玩完才知道1隻角色太強了，有4個動作，通常怪物活不超過2個行動，也就不會被恐懼判定，另外，所有裝備都會在同一支角色上，無限疊加，整體來說真的太強了，這一局大概30-60分鐘就結束了，幾乎殺光所有怪物，安全地拿了線索走出莊園，爽啦~。
3. 另外一提，有收納真的差很多，只要把幾個收納拿出來放好，就可以開局了，節省非常多時間，遊戲結束也可以很快速收回放好，有收納真的很不錯，推薦一定要有收納。
4. 玩了那麼多同一劇本，發現一開始去就找管家得到的好處還蠻多的，建議這劇本一開始就去找管家，通常會有一隻怪，開局直接圍毆死就可以了。
5. 

瘋狂詭宅第二版：戰報(2)

瘋狂詭宅第二版：戰報(2)

Date: 20220801

Version: 2

1. 瘋狂詭宅又來啦！這周應該是第2次玩瘋狂詭宅了，周五在公司跟了1場5人團，有另一位負責教學，所以有6個人，那場只能說大家運氣非常好，沒有人受傷或瘋狂，也沒有人死亡，順順地就結束了。
2. 今天繼續來跑一下單人桌遊，一樣是「永世循環」，因為上次有許多細節玩錯了，難怪會這麼簡單就破了。
3. 因為上次玩過，所以算是了解劇情，想說是不是直接直衝目的地會比較簡單，結果不知道為什麼，BOSS召喚了一堆異教徒和深潛者，雖然都打得贏，但沒有行動可以處理傳送門，最後在神秘階段檢定失敗，有一個調查員死了，再下一個調查階段來不及完成，結果就GG了。
4. 
5. 這場玩了大約90分鐘，跟劇本預估的時間差不多，但如果我活久一點的話，說不定就超過了，但主要還是比較熟悉規則了吧。
6. BTW，這次有1個調查員恐怖超過其神智，就瘋狂了，運氣好的是其瘋狂的條件與原本勝利條件相同，所以沒差。
7. 原本想說單人遊戲，我用1隻角色就好，結果不行，APP寫死最少要2隻角色才行。
8. 跟上次玩錯的地方如下：
1. 範圍為3格，但不會穿過牆壁或門之類的。
2. 傷害或恐怖，抽完面朝上，除非有指示為面朝下，不然一律都是面朝上，所以會執行卡片效果。
9. 下次再來研究看看如果指控1隻角色，但有4個行動的話，會如何呢？

瘋狂詭宅第二版：入手與戰報(1)

瘋狂詭宅第二版：入手與戰報(1)

Date: 20220722

Version: 1

1. 從年初就在找便宜的瘋狂詭宅2，當初想在過年期間可以在家裡自己玩，可惜問了許多麥家其品項都是瘋狂詭宅2第二版初版，主要差異為模型精緻度，請參考下圖，直到最近在桌遊跳蚤市場，運氣非常好地看到，有一買家剛PO30幾分鐘左右，剛好又賣瘋狂詭宅2，而且價格非常便宜，趕緊問問賣家是哪一版的，就是瘋狂詭宅第二版再版，而且我是第1個詢問的，馬上就下訂了，很快在周就來到我家了，賣家保存得很好，有上下模，上厚套，之後我可能會再去買收納組來放，沒收納真的麻煩，一堆夾鏈袋，預計是買桌遊罐兒的，不過經詢問大概要等到8月才會上架販售，就再等等吧~
2. 
3. 到貨之後，剛好今天放假就來開一局好了，整場玩了差不多快3小時吧，畢竟很多步驟、細節不清楚，一直在查規則書和參考手冊，以下就混合著戰報和心得，讓大家看看吧！
4. 因為是第1次遊玩，依規則書建議選擇「永世循環」來開局，用APP真的不錯，各種設置、文字、旁白、背景音樂...等都非常不錯。
5. 單人玩家，選擇兩個角色，一個麗塔‧楊(9/5，543324)，另一個是潘明(7/7，344343)，分別為生命/理智，力量、敏捷、觀察、知識、影響、理智。
6. 整體來說麗塔為攻擊手，潘明為輔助角，我是這樣安排的，所以後來都是用麗塔打怪，潘明幫忙補血或解決謎題用的。
7. 整場遇到幾種怪，追獵恐魔、異教徒、達貢祭司、星之眷族，前3隻用麗塔大概都可以一回合KO掉，危險性不大，基本上怪物出現的那回合，我就可以殺死了，因為很剛好，怪物都出生在我角色附近，而我習慣兩隻一起行動不分開，所以每次都是兩隻調查員圍毆一隻怪物，可惜麗塔太強了，一個行動點就打死了。
8. 至於星之眷族，因為出生點比較遠，他還沒走到調查員的位置時，遊戲就結束了。
9. 遊戲最後目標是關閉傳送門，大概兩個調查員花費3個回合就解決掉了，可以參考下圖，差一點星之眷族就要靠近了，可怕~
10. 
11. 整場遊戲過程下來，其實我不太知道我要幹嘛，沒有目的性，我只是走來走去，遊戲目標就出現了，沒甚麼調查的感覺。
12. 整場遇到3個解謎遊戲，1個華榮道，2個1A1B的遊戲(1個3碼，1個5碼)，大概都花2輪結束，華榮道很簡單就不談了，1A1B的話，我習慣每種數字都按過，就可以確認到底有哪幾個，之後就慢慢調換位置試試看。
13. 兩隻調查員，一個瘋狂，一個受傷，都差一點死掉，主要還是前期花太多時間在調查了。
14. 整場比較困難的是，火焰，蔓延實在太快了，花了很多回合再滅火。
15. 整場可能有玩錯的大概是範圍吧，但影響不大，通常是指恐怖檢定中的範圍，但怪物都在調查員同格，所以是沒有太大的差別，我都以為範圍是指同格內，但上網查的一下，應該是3格內，所以整場唯一有差的是星之眷族的恐怖檢定，但不會差太多，因為只會影響1次，下一回合我就結束遊戲了，整體來說還行吧。
16. 開場有拿到1張法術，但從來沒用過，代價有點大就算了，而瘋狂的影響下，其獲勝條件沒有太大的差異，一樣要調查完成，但有1位以上瘋狂或受傷，兩隻調查員都有達到，所以還是獲勝了。
17. 最後總結，瘋狂詭宅真的好玩，有玩桌遊的務必要玩過1次才行，等之後收納組買到後再來寫一篇，另外，等所有劇本玩過後，再來考慮是不是要買擴充來玩。

CritDice

CritDice

Date: 20210711

Version: 1

1. 這是一個代替骰塔和骰子的工具，主要還是在研究元素棋單人規則時，需要D6、D10及D12骰子，雖然家裡有，但會被自製骰塔卡住，另外就是，花費在骰的時間上，從拿取、放入、滾動到產出結果，雖然時間不多，但隨著步驟次數一多，整體也是會花上不少時間在上面。
2. 這時就想起了APP，是否有APP可以代替這個過程呢？來到Google Play商店裡花了點時間尋找及使用，最後決定使用這一個APP，有以下幾點考慮：
1. 畫面簡單明瞭，不拖泥帶水，有的APP還給你來個職骰的動畫。
2. 預設有D2、D3、D4、D6、D8、D10、D12、D20、D100，基本有這些就很夠用了。
3. 有提供額外條件的設定，例如骰5次取最高、骰5次取最低...之類的。
4. 最重要的是，有我的最愛功能，可以自訂分類，建立各種擲骰的組合出來，而這個功能是我最需要的，尤其是在元素棋中，分類為元素棋，有移動、擺放和瞬間移動...等擲骰組合，還可以命名方便管理，整個就是非常適合我。
5. 還有歷史紀錄的功能，方便查詢之前到底骰了什麼？
6. 除此之外，他還有念出結果的功能。
7. 最後，APP下方有橫幅小廣告，當然一樣的有付費版，可以無廣告，自訂骰子，更多條件設定...功能。
3. 就目前而言，基礎版就已經很夠用了，以上就是小小心得，推薦給大家，下方為APP網站和Google商店，有興趣的可以去下載用用看。
4. CritDice - Best Dice Roller App for Android (Website)
5. CritDice - Dice Roller (Google Play)

文字接龍

Date: 20191216
Version: 1

1. 可參考上篇「文字戰爭」，這算是重啟之作，在上次實作之後，給了身邊的朋友測試，但效果不盡理想，最主要的原因是，一般人常用或口語用的詞彙，常常會與資料記載不符，也就導致詞彙無法送出，無法進到下一步，造成遊戲體感不佳。
1. 假設有N個字，有M個有意義的詞彙，M<<N
2. 2個字: M2 / N^2，M2<<N^2
3. 3個字: M3 / N^3，M3<<N^3
4. 以此類推，當隨著單字長度不斷增加，有意義的詞彙比例就會不斷下降，換句話書，越不容易送出非常態用的詞彙，也就是說會越接近資料庫所擁有的詞彙。
5. 因此，在這階段，會將長度小於2的詞彙移除，僅保留長度大於2的部分，也就是相關詞彙會從長度3開始，後續再依照實際使用狀況進行修正，看是否要將長度3也拿掉。
6. 雖然一開始想說把詞彙規範在成語當中，但成語的長度並非一致不變的，有長有短，最後就只保留長度3以上的詞彙。
7. 資料來源主要是《成語典》、《國語辭典簡編本》、《唐詩三百首》及《宋詞三百首》。
8. 《成語典》、《國語辭典簡編本》包含大部分的成語，而其中有一些具有逗號的成語，會相對應新增沒有逗號的版本，畢竟有的人會用逗號，也有的人不會用，所以沒有使用標點符號來進行分割。
9. 但在《唐詩三百首》、《宋詞三百首》，逗號是作為分隔線的存在，會依照標點符號進行分割，故不會保留。
2. 再來就是，因將相關詞彙資料放到Firebase上，在初始連線上所需要花費的時間過長，也會造成遊戲體感不佳。
1. 將改由SQLite資料庫進行支援，變成local版本，在資料的處理上都會比之前方便快速許多，唯一需要注意的是需使用SQL句，但對我來說還算熟悉，因工作需求，要使用到MySQL、MSSQL、Oracle，所以SQLite對我來說，算是非常簡單的，優點就是輕巧，適合可攜式裝備也就是APP使用。
2. APP Inventor 2本身並沒有SQLite的元件可使用，原生的只有TinyDB，所以需要另外裝SQLite套件才能使用，相關連結附於下方參考文獻。
3. 除此之外，你要建立SQLite資料庫出來，可使用下方DB Browser for SQLite的程式進行建置SQLite資料庫。
4. 而相關詞彙的資料可先用Excel建立好後，另存CSV檔，之後使用Notepad++轉編碼為UTF-8格式，這樣SQLite才能正常匯入CSV檔，因為平常Excel是以BIG5為主，所以會因為編碼不一樣導致亂碼，所以要先轉成UTF-8格式編碼。
5. 資料庫結構如下：
1. dict: 
1. id: INT, PK, NOT NULL(NN)
2. vocab: TEXT, UNIQUE, NN, 詞彙
3. first_word: TEXT, NN, 首字
4. last_word: TEXT, NN, 尾字
5. source: TEXT, NN, 來源
6. len: INT, NN, 長度
2. source_code: 
1. source: TEXT, NN, 來源
2. code: INT, NN, 來源編號
3. SQL句如下:
1. 電腦，開始，可接龍
• SELECT vocab FROM dict 
• WHERE source IN (SELECT source FROM source_code WHERE code = ?) 
• AND len <= ? 
• AND last_word IN (SELECT DISTINCT(first_word) FROM dict) 
• ORDER BY random() 
• LIMIT 1;
2. 電腦，接續，可接龍
• SELECT vocab FROM dict 
• WHERE first_word = ? 
• AND source IN (SELECT source FROM source_code WHERE code = ?) 
• AND len <= ? 
• AND last_word IN (SELECT DISTINCT(first_word) FROM dict) 
• ORDER BY random() 
• LIMIT 1;
3. 電腦，接續，不可接龍
• SELECT vocab FROM dict 
• WHERE first_word = ? 
• AND source IN (SELECT source FROM source_code WHERE code = ?) 
• AND len <= ? 
• ORDER BY random() 
• LIMIT 1;
4. 玩家，確認
• SELECT vocab FROM dict 
• WHERE vocab = ?;
3. 而這次除了改進上述問題外，還打算加入多人連線模式，而這個就會使用Firebase來做為線上資料庫來使用，而建置方式很類似於線上聊天室的模式。
4. 雖然源自於BattleText，但我還是想稍微做一下改變：
1. 對戰背景色修改，原為紅黑，後續改為紅(#d75b66ff)藍(#4e7ba7ff)配色。
2. 單人遊戲又分為積分戰和生存戰兩種
1. 積分戰：跟原本機制一樣，比分數，4.3/6.9 = X/50，X=31.2，分數比照字串長度等比例提高至30分。
2. 生存戰：無法接龍者扣血，血量預設3滴血 or 5滴血，無法接龍1次，扣1滴血。
3. 但因取消長度為2的字詞，可能導致難度提高，不確定積分戰是否可行，後續還要測試評估。
3. 跟上一版相比，使用多個Activity來進行畫面的切換，而這次想改使用多個TabView的模式來使用，降低使用Activity，統一在一個Activity中加入相關元件，降低不同Activity之間呼叫的複雜度。
4. 單人遊戲設定：
1. 辭庫：預設《成語典》、《國語辭典簡編本》，選用《唐詩三百首》、《宋詞三百首》
2. 長度：電腦可使用的詞彙長度上限，3~4字、3~7字、3字以上
3. 難度：電腦有機率會忘詞，簡單(40%)、普通(20%)、困難(10%)
5. 多人遊戲設定：
1. 個人ID是使用GUID作為辨識，故第一次開啟APP後就會獲得一組GUID。
5. 待處理問題：
1. 雙方出一個無法接龍的辭時該如何處理。
1. 當雙方都無法接龍時，不論出題者是哪一方，由電腦自動產生新辭
2. 所以會多一個參數來記錄雙方無法出題數
3. 無法出題者系指真的沒有可以接龍的辭，而非困難度所導致
2. 電腦不能出一個不能接龍的辭，但若因人出了而電腦無法出一個可接龍的辭呢？
1. 原則上電腦盡量要出一個可以接龍的辭。
2. 若電腦無法出一個可接龍的辭，同理，玩家也無法出一個可接龍的辭，就會回到5.1。
3. 所以當電腦無法出一個可接龍的辭時，就會跳脫5.2.1，而出一個無法接龍的辭。
4. 這時玩家無法接龍，換到電腦也同樣無法接龍，就會回到5.1。
5. 為解決上述問題(5.1&5.2)，資料庫需進行修改，程式需再調整。
3. 當無法接龍時，字樣上的呈現上應該要為3個全形空白，會比較清楚。(已解決)
6. 單人遊戲製作過程還算順利，因為已經有過類似的經驗，所以製作上還算快，經測試有出現一些問題，列在上方第5點，後續要持續改善，而多人遊戲的話會先從Firebase聊天室開始下手，目前會先把單人遊戲部分完善，再繼續執行多人遊戲的製作。

參考文獻：

1. 古典中文語料庫
2. 教育部國語辭典公眾授權網
3. APP Inventor 2 SQLite
4. DB Browser for SQLite

文字戰爭

Date: 20190620
Version: 5

主要是我在Google play上看到一個遊戲，叫做「BattleText」，其實就是英文版的文字接龍，連結放在下面，大家有興趣的可以下載來玩玩看，還不錯玩。

玩著玩著，就想到是不是也可以做一個中文版的呢？而且上Google play查了一下，好像也沒有類似的遊戲產出，所以就想是不是可以自己做一個呢？

使用的工具還是App Inventor 2，大部分設定還是參考「BattleText」這個遊戲，之後在依照中英文的差異進行調整，製作步驟如下：

1. 首先要有中文的字詞資料，後來就找到教育部國語辭典公眾授權網，有公開的資料可以使用，所以我就載了檔案下來。
2. 接下來要處理這些文字資料，這些檔案都是EXCEL，我使用PERL，將EXCEL轉成JSON格式的字串，格式內容為：{第一個字:{字詞長度:[符合長度的字詞組]}}，另外，為了增加字詞量，我又把唐詩三百首加進去，來進行擴充，接下來我就直接把整個字串貼進AI2中。
3. 接著開始設計APP的介面，第一頁是參數設定頁，控制字詞量及電腦難易度，沒錯，這第一版我還是設計成單機版，後續若成功才會繼續規劃連線版，提供雙人對戰；而這些參數會使用TinyDB儲存。
4. 第二頁則是對戰畫面，主要是復刻「BattleText」的畫面出來，包含色系，比較不一樣的是「BattleText」有自刻鍵盤出來，當然注音也是可以刻出來的，但這只是初期版本，其實不太需要，而且注音還會有注音比對的問題，所以這一版就沒有刻出注音鍵盤出來，再來是原作中有時間限制，目前這版本也沒有。
5. 再來是中英文差異的部分，首先遊戲裡面的分數，是按照字詞長度來計算的，所以就要比較中英文字詞的長度差異，首先，英文部分，是拿網路上隨便幾則TOEIC必考幾千字的那種字串來計算，而中文則是拿教育部的資料來計算，目前計算結果是中文長度:英文長度=2.8:6.9；而分數又跟獲勝分數有關係，遊戲中獲勝是50分，依照比例計算，中文獲勝分數應該是20.3，四捨五入為20分。
6. 結果還不錯，程式邏輯都不算難寫，使用MIT AI2 Companion，測試結果都可以正常運行，當然還有很多BUG出現，但那都是邏輯可以處理的問題，但最有問題的是，無法產出APK檔，但我的檔案也沒有很大，AIA檔沒有超過1MB，所以就開始試錯了。
1. 刪除兩頁，正常。
2. 刪除第一頁，有問題。
3. 刪除第二頁，正常，合理懷疑應該是辭典出了問題。
4. 刪除辭典部分，正常，那就是辭典有問題，但程式測試正常，可以正常運作。
5. 所以我猜測是因為在一個TEXT的元件中，無法放太多或太長的字串在其中，因為基本上我把一個字典的字詞都放進去了。
7. 所以綜上述所說的，大概有幾種解法，第一，改成網路連線抓取資料，使用Firebase，第二，就是分解我的JSON格式字串，降低單一元件的負載量，第三，改存成txt檔後上傳當附件，直接讀取附件；目前我嘗試過第三點，但是失敗了，不知道為什麼，總會有錯誤訊息產生，但明明內容就跟原本一樣，所以目前傾向第二點進行解決，後續持續更新進度。
8. 有關此APP的相關截圖，請參考下方圖片1-5。
9. 依照第7點進行改進，結果第二步驟還是太長了，無法轉成APK檔，所以只能朝第一點進行改進，目前測試如果將整個JSON格式字串上傳的話，下載下來的資料會有問題，所以還是會將資料分解後上傳，本來打算上傳後，下載存成內部資料，但不知道為啥，都無法順利下載，所以之後作法就是，將整體的資料流透過Firebase進行，而不進行存取在本機當中，後續持續更新進度。
10. 為利於本案之進行，重新定義字詞存在的意義：
1. 為了遊戲可以進行，而不是講一個無法接下去的字，而是在可以接下去的前提下，盡可能的提高字詞長度來達到高分，故進行以下調整，將字首和字尾沒有交集的去除掉，也就是說若字首無法是別的字尾，字尾無法是別的字首的話就去除。
2. 循環字的去除，也就是指長度為2，且字首=字尾的去除，避免一直重複皆同一單詞。
11. 後來在建置/使用Firebase上遇到一些問題，解決如下：
1. perl重組後另存成utf-8格式之檔案。
2. 修改副檔名為json。
3. 用notepad++開啟後，可以看到編碼為utf-8<BOM>，請轉譯成utf-8即可。
4. 上傳Firebase就完成了。
5. APP Inventor 2上，單一頁面只允許存在一個Firebase的元件，超過1個以上的話，就會發生錯誤。
6. 故在使用Firebase的元件時，需加入各狀態之標籤，確認要進行是哪一個Firebase的讀取。
12. 終於完成了初版，可以真正打包成APK檔，並可安裝在手機裡了，可以正常遊玩，後來在玩的過程中，發現即使是長度(2~3)的難度，都是有難度的，因為電腦永遠先起手，永遠比玩家多2~3個字，如果是其他難度的話，就可能一開始玩家就輸不只2個字以上，這其實是蠻困難的，這也是因為中文與英文的差異，這部分之後再用統計的方式說明，所以在電腦起始時，不論難度為何，都是設定成長度2的字詞。
13. 再來是遊玩時，當開始戰鬥時，第一個字詞的出現都需要等上一段時間，這很可能是與Firebase進行連線所消耗的時間吧？所以之後打算再加一個進度條的元件，讓玩家知道遊戲是正常運作中的。
14. 再來是為了降低難度，將原有的3個難度，調整為6個難度，這也是依照中文字詞的特性進行重新分組，例如：長度4是因為成語，長度5是因為五言絕句/律詩，長度7則是因為七言絕句/律詩。
15. 基本上已經完成了，接下來就是提供給其他人進行測試，點擊下載APK(連結)，遊玩時，若有任何BUG或優化事項，都歡迎在文章下方留言，感謝協助。
16. 目前一些改動如下：
1. 已經加入進度條，避免以為APP當掉了。
2. 電腦起始字，刪除一些沒有2個字的首字。
3. 字典統一成一個，就如同英文就是一本字典，這也是中英文比較不一樣的地方，中文可以有很多類似：詩經、花間集、宋詞、元曲...等。
17. 再來說說中英文統計上的差異：
1. 英文平均長度為6.69，標準誤差是3.48，所以正負1.5SD的話，長度大概是3~10。
2. 中文平均長度為2.5，標準誤差是1.38，所以正負1.5SD的話，長度大概是1~4。
3. 所以從上面可以看出來，英文對於先手優勢沒有那麼大，因為標準誤差很大，很容易就在後面的單字上追上去，反過來，中文誤差較低，就顯得先手優勢很難追上。
4. 英文因為長度，所以分數是50，依照比例原則，中文大約是18.65分，進位到十位數，變成20分會比較好看。
18. 目前大概就是這樣了，如果沒有其他因素的話，更新大概就先這樣了，等以後有動力再來改。

圖片：
1. 第一頁，設定相關參數，包含辭庫量、電腦難易度，其實我也有想到還可以加入許多設定，包含時間限制、字串長度限制、獲勝分數限制...等。


2. 一樣要放的版權聲明，包含教育部的資料，及ICON的資料，我這次的ICON設計是無限之蛇，也就是銜尾蛇的概念，也就是接龍啦~~XD


3. 遊戲開始畫面，會先從電腦開始隨機出題。


4. 字詞輸入畫面。

5. 獲勝畫面。 

6. 中英文比較

參考文獻：

1. BattleText
2. 教育部國語辭典公眾授權網
3. 漢語大詞典
4. ICON

易經占筮APP

Date: 20190502
Version: 1

最近又重新開始研究《易經》了，在大學和研究所時期，也有研究過易經，那時因為生活迷惘不知方向，所以開始研究包含易經、塔羅、京房、佛經...等，但後來隨者一個坎的邁過，我也放下了這些研究，生活重新步上軌道。

到了現在已經工作兩年多了，生活也十分穩定，想到是否可以發展第二專長，後來想想在研究的過程中，還是《易經》最讓人無法忘懷，大概是因為我花最多的時間在上頭吧！也因此決定要讓易經成為我的第二專長，透過它來幫助其他需要幫助的人，於是我又開始看起相關易經的書籍，並利用自己的專長，來寫一支易經占卜的APP，正所謂算卦容易，解卦難，使用APP可以輕鬆地算出一卦，但這一卦的背後故事就要看解卦人的功力了。

另外之所以會寫這支APP，是希望可以透過這支APP來增加我的樣本數，所謂的解卦，就是參考了卦爻辭以及解卦人的經歷來產生的，卦爻辭都在那裡，所以真正的重點就在解卦人的經歷上，而這就是需要增加樣本數的原因，樣本數愈多，我就愈了解卦應該如何解，才是最適合我的，解卦方式百百種，最重要的還是要找出自己一套的標準，這就需要樣本數及後續的追蹤，來不斷地修正自己的經歷。

以下就會說明我設計此APP的相關規劃：

1. 會有一些用來占筮的功能，換句話說，會有不一樣算法的占筮，所以我設想要使用tablayout的方式來呈現，後來在app inventor 2的套件中，實在是找不到，最後我就自己刻出畫面來呈現tablayout的感覺。[圖1-5]
2. 目前規劃會有5種tab，包含數字卦、時空卦、籌策、查詢、說明，共五種。[圖1-5]
3. 在APP中使用資料庫來紀錄是否為第一次使用該tab，若是則會跳出說明視窗。[圖5]
4. 數字卦，使用三位數數字來決定下卦、上卦和變爻，取餘數。[圖1]
5. 時空卦，利用時間和經緯度來推算，取餘數。[圖2]
6. 籌策，這就是繫辭中提到的算法，只是用程式寫出來，還蠻好玩的，中間的邏輯思考。[圖3]
7. 查詢，簡單使用下拉式選單，讓使用者自行選擇要看哪一卦的資料。[圖4]
8. 說明，第三點的說明，怕使用者忘記，還是可以在說明中查詢到，並加上聲明及電子郵件。[圖5]
9. 目前APP大致上已經完工了，預計會上架到Google Play上，但會先再測試一段時間，來看看有甚麼需要優化的地方。

圖：
1. 數字卦

2. 時空卦




















3. 籌策




















4. 查詢




















5. 說明，原本是其他

參考來源：

1. 易雜談

路線規劃APP

Date: 20181107
Version: 1

主要發想是來自於業務中，廠商使用Google Map來進行製作路線規劃，但其中有許多不太完善的地方，例如路線很奇怪，票價有問題...等，於是我就想說為什麼會這樣呢？難道很難嗎？於是上網查了Google Map API，詳細閱讀了文件後，覺得並沒有那麼困難，只是有很多參數需要加入，另外，在PTX中，也發現了正確的票價，使用以上工具可以解決我遇到的問題。

於是我就想做一個路線規劃的APP，但目前Android Studio還在學習當中，因此還是使用App Inventor 2來製作此APP。

1. Google Map API，有12個月試用期，共300美元的額度可使用。
• 會得到一組API KEY，呼叫API時使用。
• 有JSON和XML兩種格式。
• 有諸多參數可以設定，請查說明文件。
2. PTX，有分會員等級，但不成為會員還是可以用，只是額度更少。
• 會員有三種等級+未註冊，共4種等級，每一等級之權利義務不同。
• 可提供預覽介面，可直接製作需要的API。
• API中可輸入的功能很多，請查說明文件。
• 後來進行製作時發現，不成為會員的話，只能透過Swagger使用，無法在APP上使用，有權限管理，所以後來還是申請了會員。

製作過程：

1. 需要先產生各路線對照表，包含place_id、代號、關鍵字、車站...等，並產生相對應的json object or array。
2. 使用Google Map API及PTX API確認相關參數的使用狀況，決定後續要使用那些參數。
3. 使用下拉式選單建立出路線和車站，提供路網圖給旅客查詢路線。
4. Google Map API程式：
1. 將車站轉出對應的place_id，並進行搜尋。
2. 抓出連結資料。
3. 將頭尾的步行刪除，因從車站出發。
4. 抓出節點資料，利用關鍵字及路線校正，獲得正式名稱。
5. 路線顯示。
5. PTX程式：
1. 找出同一家捷運公司的起迄站，並對應出各車站代碼。
2. 利用代碼搜尋。
3. 跟Google不太一樣，須建立header才行，請查說明文件。
4. 找出單程票票價。
5. 將桃捷與北捷的票價加總，並顯示。
6. 一開始使用圖片，但發現無法放大縮小，因此改為使用網頁瀏覽器，可以放大縮小，寫了個Html來展示台北捷運路網圖。
7. 介面優化/程式優化，進行中。
1. 介面優化：
1. 步行圖示：🏃。
2. 連接圖示：⬇。
3. 端點站圖示：🌑。
4. 轉乘節點圖示：🔘。
5. 起訖站互換圖示：⇅。
6. 路網圖圖示：🚇。
7. 增加所有權聲明。
8. 時間與票價介面優化。
9. 時間與票價介面間距增加。
10. 新增等待畫面。
11. 新增第二頁面，顯示相關聲明、部落格及電子郵件。
12. 修正A12、A13、A14a區間之文字訊息。
2. 程式優化：
1. 新增起訖站互換功能。
2. 新增切換路網圖功能，及第一次無法切換設定。
3. 新增端點站/轉乘站判斷功能。
4. 新增焦點功能，每次查詢時，查詢結果可以置頂。
5. 步行的顏色修正。
6. 永春站的place_id修正。
7. A18 高鐵桃園站的關鍵字修正。
8. A13 機場第二航廈站的搜尋改善，使用fewer_transfers。
9. 發現A12-A13之區間會有error，經查結果為google無論如何搜尋，都會跑出機場電車，該區間改成跳出文字訊息。
10. BL 22 南港的關鍵字修正。
11. 新增語音辨識功能，點選"起"或"迄"後，會出現google語音辨識起迄站，提高方便性。
8. 製作APP的Icon [6]。
9. 給公司的同事看過後，有人問到怎麼沒有台鐵和高鐵呢？若要達成台鐵及高鐵需要進行以下規劃及確認：
1. 站點確認，台鐵太多站了，考量到此APP主要為桃捷及北捷，故預計規劃為北北桃生活區之區域，包含：
1. 台鐵：五堵、汐止、汐科、南港、松山、台北、萬華、板橋、浮洲、樹林、南樹林、山佳、鶯歌、桃園、內壢、中壢、埔心、楊梅、富岡、新富，共19站。
2. 高鐵：南港、台北、板橋、桃園，共4站。
3. 已確認上述24站的place_id。
4. 三鐵共構: 南港、台北、板橋，先使用同一組place_id。
2. Google，確定參數"transit_mode=subway|train"適用於台鐵及高鐵。
3. PTX，確認有台鐵及高鐵的票價資訊，已查車站代碼。
4. 台鐵使用黑灰相間之格式，而高鐵則使用其網站主體配色(橘色)。
10. 經過一個禮拜的努力，終於完成台鐵及高鐵的轉乘資料，由於不再是只有捷運，因此APP改名為「大眾轉乘」。
11. 這幾天開始準備APP上架的相關事宜，開發APP到現在終於有第一個要上架的APP啊，超快，申請差不多一小時就過了，大家可以在Google Play上找到我的APP。
12. 成本估算如下，只要每日不超過1000人使用，應該就不需多付，當然我沒有開通付費功能，所以如果額度用完就沒了。
1. PTX：
1. 免費。
2. 呼叫次數：每日20,000次(一般會員)，若每人一天兩次(上下班兩次)，每次最多四種(北捷、機捷、台鐵、高鐵)，20000/2/4，每日大約可供2500人使用。
3. 參考資料：會員分級。
2. Google Map API：
1. 每月有200美元的抵免額。
2. 呼叫次數：每月40,000次(抵免額)，若每人一天兩次(上下班兩次)，每月22工作天，40000/22/2，每日大約可供909人使用。
3. 參考資料：價目表。
13. 發佈後，有個朋友問是不是可以提供時刻表，回去查了一下PTX，桃捷、台鐵和高鐵可以提供時刻表，但北捷則因為班次較密集，使用時刻表意義不大，改成提供班次間距會比較好，只是這又是一個大工程了，而且是否要抓取整日的時刻表呢？還是提供查詢當下時間點之後的時刻表呢？有待商榷。
14. 使用後第一個受惠的就是我，要去南京復興上課，平常都是做紅線轉綠線，使用了APP後發現，Google提供了一條，坐到松山火車站後，步行到松山捷運站，這樣的規劃非常不錯，去回程人少，而且都有位置坐，真的不錯，沒使用這個APP還不知道還可以這樣坐。
15. 花了一兩個禮拜在這個APP上頭，是時候休息一下，看看書，等充完電後再來把時刻表補齊吧。
16. 時刻表規劃：
1. 北捷：提供班距說明。
2. 桃捷：提供班距說明。
3. 台鐵：提供起迄站時刻表。
4. 高鐵：提供起迄站時刻表。

注意事項：

1. header的使用須注意加密方式，時間格式為GMT，須扣除8小時，"x-date: "後面有空格，網址有時候用https會失敗，有時候會成功，目前使用http。
2. 產生的json，可先用JSON Editor Online進行轉譯，比較容易了解。
3. 如果不使用PTX，可使用Swagger將所有資料抓下來後，寫進資料庫也是可以，之前作法是將上傳到Firebase。
4. 桃捷台北車站與北捷台北車站需步行，需多加留意程式撰寫。
5. 上方的圖示是從Blogger中的"插入特殊字元"功能用出來的，可以搜尋關鍵字，找出你想要的特殊字元，就是上方的那些圖示，在網頁上呈現的結果，會與APP上呈現的結果不太一樣。
6. 北捷的路網圖要跟北捷申請授權，也就是填一份授權申請書，回寄給北捷即可。
7. 憑證keystore，自己包的APK使用的憑證，和從Google Play下載的APK憑證會不一樣，所以在Google Cloud Platform限制使用時，要特別注意其使用的SHA1會不一樣。
8. 在Directions API中有一個參數為alternatives，若設定為true，則會像google map一樣顯示出多條替代路徑，而我沒有採用的原因有1)太多條，不知道哪一條才是我要的，還是用預設最符合我需求的那條即可，2)太多條，計算的量不一樣，API的價格也不一樣。
9. 發現使用的憑證錯誤，會導致API設定後無法使用，將進行釐清到底要使用哪個憑證?
1. 無：沒有限制，可使用，看來只能使用這個了，多加了API限制。
2. 應用程式簽署憑證(google核發)：經修改五分鐘後測試，無法使用。
3. 上傳憑證(原app)：經修改五分鐘後測試，無法使用。
10. 
    

改進事項：

1. 抵達A13時，有時候會出現Error，因會出現到A12轉乘機場內的接駁車造成程式錯誤，轉乘錯誤: A13(fewer_transfers)、確認json資料(For input string: "ot")。
2. A1-A5區間至A7的票價錯誤，因PTX未更正正確資料，已請同仁處理。
3. 板南線任意站到南港展覽館站會出現錯誤。
4. 起訖站互換功能錯誤。
5. 目前使用上，若起訖站含有轉乘站(台北、桃園、板橋、南港、A1、A18)，或地理位置鄰近(北門)，會出現顯示不易理解之情況。
6. ...

參考文獻：

1. Developer Guide | Directions API | Google Developer
2. Place ID Finder | Maps JavaScript API | Google Developer
3. 入門指南‧PTX API Documentation
4. MOTC Helper
5. JSON Editor Online
6. 台北捷運路網圖
7. 3418 free SVG and PNG icons for your games and apps | Game-icons.net

短網址QR Code APP

Date: 20180923
Version: 1

會想要做這個原因在於，現在公司的短網址和QR Code都是使用goo.gl的服務產生，但該服務於明年就會結束了，所以才在想要如何繼續下去。

會分成兩塊，一個短網址，一個QR Code，有的單位需要短網址，但另一個單位需要QR Code，而需要QR Code的那個單位會需要先行產生後，等相關內容確定後才會放上去正稿，因此會使用官網伺服器進行跳轉的方式，來達成動態連結的效果。

雖然如此，後來想想雖然有的單位需要短網址，但如果是用我的方法話，不就每次都要在官網建立跳轉嗎？很明顯是個浪費人力的方法，但既然都做了，還是紀錄一下好了。

QR Code
比較簡單，因為先前那一個加密的APP已經做過了，這次只是再把方法寫出來一次。

短網址
使用的方法是方法一[1]，因為方法二我看不懂，所以採用方法一，十進位轉為XX進位法，所以你需要兩個東西，十進位，XX進位，XX進位目前選用的是58進位法，格式為大寫小寫數字[2]，刪除容易讓人搞混的大寫O和零0，以及大寫I和小寫l，這四個在APP上的呈現容易令人疑惑，故刪除。

而十進位的來源，需為主鍵[1]，也就是不會重複的一串數字，而有甚麼數字是不會重複的呢？我選擇的是時間，年月日時分秒，六個節段，時間是唯一的，不會有時間重複到，因此進行的第一次轉換，轉換過程主要是將十進位/58得商和餘[3]，保留餘數，繼續將商/58德商'和餘'，直到最後商<58，無法再進行除法，將最後商及過程得到的餘數，由後往前進行轉換為58進位法，就會得到一串簡碼，也就是短網址。

但在進行的過程中，發現年月日時分不太會變化，導致最後出現的簡碼，前幾個字串都幾乎一樣，後來我將得到的時間字串反轉，由後往前排，這樣的話，整個時間就會很常變動，因為秒數常變，導致除法得到的結果都不盡相同，例如: 20180923173717-->71737132908102，這個技巧還可以用在製作隨機種子時可以使用。

最後就是將得到的短網址做成QR Code而已，但對於實際進行似乎沒甚麼幫助。

參考來源
1. 短網址(short URL)系統的原理及其實現
2. The Base16, Base32, and Base64 Data Encodings
3. 二、八、十與十六進位 (數字系統) 轉換教學

小說背景設定-16

Date: 20180809
Version: 1

本篇為前篇「小說背景設定-12」之延伸。

但參考資料做了一些改變，採用教育部國語辭典公眾授權網中的《成語典》，跟上次資料不同的是，該網站提供了成語相關資料的下載，幫助我們更容易了解成語的來源與用法，降低了查找資料的時間。

首先介紹資料格式，相關欄位有編號、成語、注音、漢語拼音、釋義、典源、典故說明、書證、用法說明、近義、反義、辨識、參考語詞，共13項，針對主題進行篩選，不需要注音和漢語注音，典源與典故說明衝突，僅保留典故說明，書證內容不太需要，用法說明與釋義衝突，僅保留釋義，辨識為其他html檔案，不考慮，參考語詞為其他組成之成語，大多數皆不常使用，故最後僅保留6項，另外，為了加入成語能力的解析，故再加上兩個欄位「形」和「義」(文後再解釋)，所以結果一共為8項。

該資料表共有5106筆，刪除大多數可義參的成語後，最後成語總數為1568筆，以上這些列述和欄位就是之後成語資料庫的組成。

接下來就是介紹如何使用這個成語資料庫，為了可以隨時隨地查看/更新成語資料，故作成一個APP是一個不錯的點子，而我使用的還是App Inventor 2，而之前常使用的資料庫，google的spreadsheet，只能讀取無法寫入，故這次選用了其他線上資料庫來儲存資料，有tinywebdb和Firebase兩種，上網查了一下，就決定使用Firebase，主要是因為操作簡單，不需要太多額外設定就可以達成，建立好Firebase相關資料後，就要開始匯入，Firebase使用的是json格式資料匯入，故需要將上述成語資料庫轉換成json格式後再上傳，請注意json格式編碼請使用utf-8，否則資料無法上傳。

Firebase json 格式如下：

有興趣的可以上網查一下，Firebase 的資料庫格視為NoSQL，主要是透過Key-Value進行配對，主要是使用物件來進行建置，當然用陣列也是可以。

前置作業完成後，接下來就是使用App Inventor 2 來製作成語APP了，中間過程就不贅述，直接放結果圖如下：

左1是點擊"GO!!"後，會隨機選去一組成語秀出，點擊"釋義、典故、近義、反義"後，會出現左2，會顯示其內容，如果長按"GO!!"的話，會出現左3，可輸入成語的編號，目前有填入相關資訊的是左4，分別在"形"和"義"鍵入相關資訊後，按下"儲存"，即可將內容上傳到Firebase。

開發的過程中，花最久的時間反而是在版型的建置上，一開始是用下拉式選單，但發現效果不太好，形和義，本來是當選擇某一個另一個textbox會隱藏，但發現不太好用，最後就改成兩欄式，兩邊可以一起對照的打，再來說明一下的是，在讀取資料的時候，一開始設計是將該組成語所有資訊讀取下來後，在程式內進行檢索，但發現在某些編號的成語，會出現讀取錯誤，我也找不出原因來，最後，就改為每一個按鈕的是去跟Firebase進行讀取，這樣處理後，就沒有再發生讀取錯誤的問題了，再來就是Firebase(免費)有限制每月10GB的下載量，目前看起來很夠用了。

以上就是成語APP的製作過程，接下來就開始進入到正題，也就是本次小說背景設定的設定了。

這篇主要的就是形和義兩種，所謂的義，就是成語的真正意涵，而形則是就字面解釋成語，例如：「三人成虎」，並不是只有三個人變成虎，而是指...等，所以三個人變成虎就是形，而...則是義，也就是說在APP中，要將成語以這兩種角度來詮釋成語能力，希望有一天我可以完成全部1568筆成語的能力詮釋。

另外，該成語的能力也可修成反義，只不過就像法師一樣使用超魔技巧，需要多耗費一樣，使用者也需要提供更多能量。

20180902更新：

在後來使用上發現一點不太好用，就是如果對某個成語有靈感時，但以目前設計是無法找出那個成語的，因為是用隨機取號的方式，所以這次對程式進行了修正，增加了ListPicker的功能，可以在輸入編號的地方，也可以輸入關鍵字，之後程式會用關鍵字搜尋並用ListPicker將搜尋結果顯示出來，讓使用者進行挑選。

只增加了對輸入進行檢核，若是數字，則將該編號相對應的成語拉出，若不是數字，則比對所有成語，將含到該關鍵字的成語列出在ListPicker中，讓使用者挑選，完成後使用起來感覺還不錯。

參考文獻：
1. 教育部國語辭典公眾授權網

桃捷時刻表(簡易版)

Date: 20180318
Version: 1

因為負責公司官網的時刻表功能，而接觸到了時刻表，剛好司機員APP也剛好告一段落，就想說是不是可以利用一下手邊的資源來做個桃捷時刻表APP呢？

這就分成兩部份了，後台資料處理，需要將OCC提供的時刻表轉成我之後APP方便處理的格式，這部分是用Perl完成的，並不難，難的地方是在邏輯思考的部分，這部分就想了快一天左右，想出來後之後都很簡單做。

資料處理好後，接下來是就是APP的設計了，既然要做時刻表APP，當然要參考一下業界的形式，而個人最常接觸的就是台鐵的時刻表如下：

http://twtraffic.tra.gov.tw/twrail/TW_Quicksearch.aspx

因此，我的APP設計版面都是參考台鐵而來的，畢竟台鐵的時刻表查詢理論上也是國人最常用的，因此，若介面相似的話，理論上旅客都會比較容易使用。

接下來就是選擇日期的部分，發現AI2的日期選擇不太好用，所以上網找了資料後，將資料改成中文後，以及國人常使用的日期顯示格式後，並參考家人的意見進行修改，好不容易日期選擇的部分終於完成了。

選項設定好後，接下來就是時刻表資料匯入，這部分也是搞了好幾天，推倒了好幾次，終於把資料匯入了，並且使用Scroll和html格式，讓時刻表可以滾動，並上網查資料如何讓新的資料輸出時可以回到最上頭，也參考別人的方法後，終於讓APP符合自身的預期。

看起來非常像有這麼一回事一樣，不過如果這個要推出的話，就要放到google play上了，不過這就是公司的問題了，因為google play是要收錢的，我個人是不會這樣做的，所以只能用公司的名義去做，另外就是，目前公司的APP招標開始了，我的想法是雖然開始招標，等到決標也是4月的事了，再等到功能要上架後，也差不多要4-6個月，這一段空窗期，是否可以提供一個簡易版的時刻表APP呢？當初的想法是這樣的，剩下就要看長官是否覺得可行？

不過這個版面大概就是這樣了，主要是提供旅客簡易的查詢時刻表APP，所以應該不會放太多精力在上面，主要就是簡易，這個只要2.7MB就可以了，非常快速，而且跟火車查詢很像啊。


























後來在測試的時候，發現datepicker在第一次使用會有bug出現，後來發現是因為第一次loading的時候，會比較久，所以造成timer讀取產生錯誤，解決方法就是在開起應用程式時，就進行載入，這樣後面使用datepicker時就不會造成讀取錯誤。

桃捷司機員APP

Date: 20180127
Version: 1

繼之前寫過一次APP後，最近又開始新的專題，目標是多人使用，之前有做過一次，可惜失敗了，直到現在公司長官覺得可以推推看後，就打算再試一次看看，如果我做不出來，那推也沒必要了，這一次就快了許多，畢竟有個人版可以參考修改，我只花了兩天就做出來了，後面三天主要還是在做優化的部分，整體來說，比上次進步許多，尤其是Perl的hash觀念幫忙我許多，不過因為資料庫處理的關係，顯示速度稍微比個人版的慢了一點，可以看下方關於顯示速度的優化，基本上功能都用好了，接下來就看看長官們到底買不買帳，畢竟APP的使用目的是有限的，例如：「看一個月內的班表、想看其他人的換班」，這些都只能回去看LINE上的圖片，再來是副段們修改是在電腦excel上，之後再轉成圖片放在LINE上，之後就看他們有甚麼要求吧，畢竟他們慣用的excel格式跟我使用的還是有所差距，另外總班表更換時，他們也要跟著更動，除非這些都是由我來負責的話就沒差了，單純就我這邊操作也是可以的，不過一旦我離職，這APP就會跟著GG了。

之後就會更新一些公司的狀況，看看這個APP之後的方向會是如何的呢？

小寫開頭為number or string
大寫開頭為array
中間有底線為hash
中間有@為database，為從google試算表中拉出的原始資料

today: 今天日期
year: 今天年份, from today
month: 今天月份, from today
day: 今天日期, from today
driver: 使用者工號

Type: 班型
Time:  當月日期
Start: 上班時間
End: 下班時間
Extra: 加班時間
Detail: 任務內容
AllDetail: 所有資訊

Type@Database: 所有班型資料，含班型、上班時間、下班時間、加班時間、任務內容。
Driver@Database: 司機員資料，含工號、當月班型。

Driver_Schedule: 司機員相對應之當月班型
Time_Type: 當月日期對應之班型
Weekday_Name: 星期幾的中文名稱
Month_DayNumber: 當月份之天數
Type_Start: 班型相對應之上班時間
Type_End: 班型相對應之下班時間
Type_Extra: 班型相對應之加班時間
Type_Detail: 班型相對應之任務內容
Type_AllDetail: 班型相對應之所有資訊

完成部分：(*未完成)
今日顯示
工號清單
日期清單
任務清單功能
資訊顯示
班型按鈕顯示
今日按鈕顯示
工號清單功能
日期清單功能
使用者系統(第1頁輸入-->第2頁呈現)*
使用者鎖定(第一次輸入使用者後，再開啟會鎖定使用者，故不需上方的使用者系統)
返回按鈕顯示
月曆模式

顯示速度優化測試：
個人版：舊版，0.567秒
多人版：初版，各資料顯示放於各資料庫讀取階段，故2階段需1.101秒
多人版-2：統一資料顯示時機後，0.868秒，加快20%顯示速度
多人版-3：司機員匯入數量增加(3->57)，0.901秒，約慢了3%

自動化系統：(未完成，失敗，Net::Google::Spreadsheets安裝失敗，QQ)
修改完資料後，運用perl後會進行上傳至google試算表

Perl轉檔
perl會使用perl2exe轉成exe檔後，提供使用

特地去做了一個返回鍵的圖示，是用PowerPoint做的，效果還不錯，還蠻符合APP的色調。
以下為APP目前形式：

























後來，與中油的朋友討論時，發現中油也有輪班表APP，但他們只有4種班型，不會有個資的問題，所以他們的APP可以在Google Play上找到的，另外我也找到中鋼的APP，兩者的共通點都是只有4個班型，而且都是用月曆的模式來呈現，因此我也在思考是否可以做出動態的月曆出來，畢竟之前我是使用圖片的方式呈現。

經過一翻思考與設計後，月曆模式終於完成了，可以呈現出該月的班型狀況，使用三種顏色，藍色是當日，紅色是放假，灰色是上班，另本來打算是要在班型的地方改用按鈕方式呈現，但按鈕的效果不如預期，所以最後使用的是在月曆下方使用下拉是選單，來讀取班型內容，當然也有選擇使用者的功能。

目前，大致上會有三種版本，1)日曆模式、2)月曆模式、3)日曆+月曆模式，中油和中鋼是2，之前個人版算是1+2的圖片，理論上應該會是使用3的版本提供大家使用，當然最後還是要看使用者的意見決定之。

後來也仿照其他APP的功能，多做了一個關於的功能，放一些資訊，可供長官們發揮的區塊，另外還學習如何使用Email的功能，App Inventor 2的功能真是越來越厲害了，不過還是有許多地方還可以再改進。

經過一段時間後，Mail的功能已經做好了，並且也與車務中心開了兩次會議，中心主任甚至認為這個APP推出後，其他場域的人都會想用，不過最重要的是希望可以與公司的ERP系統介接，這樣資訊都會是最新最完整的，關於這部分，我剛好在看一些APP的作品有用到json的格式來達到類似的目標，所以如果可以將ERP的資料用json的格式丟出的話，理論上我這邊的APP應該是可以做到的，再來就是json資料的資安規範，要如何規劃，畢竟要接到我的APP一定是要透過外網來使用，所以外網的資訊安全就格外重要，目前公司這邊還在處理ERP資料拋出的部分，所以這部分就要等ERP部分處理好後，才會接下去，到時候可能就會再開一個新的文章了。