很快的,30天的研究分享就到尾聲了,盤點之前29天提到的內容如下:
基本介紹:
Day1: ODK 是什麼? 可以吃嗎?
Day2: ODK 的架構
實作:
Day3: 安裝 ODK Collect與測試
Day4: ODK Central 的安裝
Day5: ODK Central 的基本配置
Day6. 建立 XLSForm 問卷
Day7: 上傳問卷至 ODK Central
Day8: 由ODK Collect測試問卷草稿
Day9: ODK Central 的下載問卷
Day10: 設置問卷使用權限與
問題類型介紹:
Day11: XLSForm設計教學:問題類型/資料類型(Question Types) Part 1
Day12: XLSForm設計教學:問題類型/資料類型(Question Types) Part 2
Day13: XLSForm設計教學:問題類型/資料類型(Question Types) Part 3
Day14: XLSForm設計教學:問題類型/資料類型(Question Types) Part 4
Day15: XLSForm設計教學:問題類型/資料類型(Question Types) Part 5
表單邏輯:
Day16:表單邏輯(Form Logic) Part 1
Day17:表單邏輯(Form Logic) Part 2
Day18:表單邏輯(Form Logic) Part 3
Day19:表單邏輯(Form Logic) Part 4
運算子與函數:
Day20: 表單運算子(Operators)
Day21: 表單函數(Functions) Part 1
Day22: 表單函數(Functions) Part 2
Day23: 表單函數(Functions) Part 3
其他項目:
Day24: 表單資料集(Form Datasets)
Day25: 表格語言(Form Language)
ODK Central API與Access VBA的應用:
Day26: ODK Central API與Access VBA – Login與Logout
Day27: ODK Central API與Access VBA – 專案管理
Day28: ODK Central API與Access VBA – 提交資料管理
Day29: ODK Central API與Access VBA – 提交資料下載
結尾:
Day30: 結尾彙總與使用經驗
由於ODK的一些特性,自己也還在摸索,所以也沒辦法給予太多的資訊,不過可以分享一些使用經驗。
由與ODK Collect是用XML文字格式來存放資料,包含了選擇項目(choices工作表),因此當項目一多的時候,執行效率會變差,進行資料驗證時,也會因此受到影響,由於我嘗試將它導入倉庫盤點作業,而且不是點數量,而是每個物品都有自己的身分,要去檢查每個儲區內,每個物品是否都在該儲區內。
物品有快2萬筆,儲區有140筆,再加上每筆物品資料有兩欄Key值,其中一欄Key值有資料有可能重複,因為僅用於繳庫用途,為繳庫條碼,因此設計條碼序號是循環使用的,所以有這樣的問題,另外一個Key值是盤點用的,但由於貼標並不是每個都有盤點條碼,所以還是需要分辨是哪種條碼,然後依照條碼類型來檢查。
這導致calculation欄位我還寫了複雜的語句來檢測掃入的資料,先確認掃進去的是哪一種key值,如果是會重複的Key值的繳庫條碼,就先檢查該key值於該儲區有幾筆資料,超過一筆資料的,就不去帶入預設值,列出清單讓user手動確認是哪個項目,只有一筆的,就放到default中(這樣可以省去人員點選項目,直接按下一步即可),如果連一筆都沒找到,就報錯,有可能存到其他儲區。而如果掃描的是步而如果掃描的是不會重複的key值,則找到另外一個欄位資料,有找到就自動放入default,沒有找到就報錯。
由於資料筆數太多,因此進行資料核對與驗證時,速度異常的慢,除非一次僅轉入部分儲區,要去盤點的區域載入就好,其他的就先不要放到choices,這樣似乎就還可以使用,不過結束前的驗證,速度還是偏慢。
後來,嘗試於表單結束前,增加一個「完成」選項,預設為「否」,當使用者完成盤點後,選擇「是」的時候,就把循環問題內有用到calculation的公式都加上once(),讓資料驗證時,省略掉驗證該項目的計算,因為只計算一次,這讓驗證速度加快了很多。
但我還是想一次把全部資料塞到手機帶著走,這該怎麼做?山不轉人轉,想說造成慢的原因,是儲存方式非資料庫,導致統計資料時偏慢,那如果我把儲區的Key值都存到單一的欄位內,以空格當做區隔,當使用者選擇要盤點的儲區時,就把這欄位變成一個變數,再用selected()函數,檢查掃入的Key值是否有在這變數中,由於這個例子是有兩個Key群,所以會有兩組變數,依照掃到的條碼類型,來選擇是檢查哪組變數。
經過改寫後,操作速度飛奔,一次也可以把全部資料給擠進去,但是重複key值的部份怎麼處理呢?也是一樣,把該儲區有重複Key值的,另外收集起來,放到另外一個欄位,變成另外一個變數,只要掃到盤點條碼類型,先檢查是否有包含再這組變數內,有的話,就改由舊的方式帶入資料,由清單內篩選後讓user選擇,雖然這樣速度還是很慢,但重複Key值的數量不會太多,所以使用上倒是還好。
這些欄位的資料,必須要由電腦產生,這部份就得自己寫程式彙整,不過會看這篇的人,應該不是什麼大問題。
經過這參賽,強迫自己閱讀、翻譯、測試與研究,我嘗試把choice內的資料轉存成.csv檔案,由select_one改成select_one_from_file的方式,把資料拆分到文字檔上,這個之前我沒有特別思考,想說速度應該一樣,但是當我把資料以.csv方式存放後,發現處理速度似乎加快了,所以XLSForm內容轉成XML格式,但.csv的內容存入時可能還是.csv的文字格式而非XML,這讓讀取文字內容的速度增快許多,這也算是寫文章後重新審視自己所帶來的助益。
其實以上速度的部份,只要用較好的手機,處理速度一定會加快,但我還是希望以最平價的設備來進行作業,這樣即使工作時手機摔機、故障、遺失等情形發生,損失也不會太嚴重,而且如果平價手機都跑的起來,那高檔一些的應該就是用飛的了。
ODK的生態系,其實已經很久了,只是發展速度較為緩慢,但個人覺得還是有很大的發展潛力,尤其是從伺服器到手機平板端的程式碼是全開放的,其實是可以進行高度客製化。
目前自己則是還在改寫程式,讓盤點系統能更精進,未來還想導入到其他部門使用。
以上就是這30天的分享,感謝各位的閱讀。