IoT與Mobile App摻在一起會變成什麼？（二）資源存取與控制-上篇
大家好，這是IoT與Mobile App 系列文章第二篇，本系列會聚焦在三件事情上：
裝置認列、控制、條件作動
這是軟領過去打造物聯網應用過程中最常見的三個應用情境。
這篇文章會從特定服務開始，搭配一些國外的IoT應用及軟領的實際經驗來看IoT Mobile App的資料存取與控制。
在存取物聯網資料之前
上一篇文章提到，裝置認列無非是在實現裝置可被管理的過程，裝置能被安全得識別是物聯網應用的第一個關卡，而後才被使用者綁定認列，使用者經過身份驗證得以存取資源。
當裝置能夠安全連線，可以開始傳送資料到雲伺服器(或其他選項)上，這些資料是未來提供服務的基礎，解決裝置的問題後，還有資料存取的安全性：
誰可以使用你的IoT服務？你需要整合會員系統，或許還要加上權限(Policy)管理的功能，像是工廠中的機台管理者與機台操作員的情境，不同的使用者有不同的資源存取權限，除了裝置安全以外，資料存取安全也需要解決。
物聯網應用中的Device Provision：AWS IoT Device Provision、Microsoft Azure IoT Device Provision、Google IoT Device provision 。物聯網提供商針對裝置的安全與識別推出的實作方案。
其實不只有AWS、Google這些常聽到的解決方案，你可以從接下來的篇幅看到其他不同IoT服務，他們甚至連介面都提供給你使用，但符合你專案的使用情境嗎？
Make IoT Mobile App in 5 minutes
Blynk 主張任何熱門的開發板如樹莓派、Arduino等型號透過簡單步驟都可完成一款IoT App。
Blynk了解當有開發版卻不會、不想寫運行在板子上面的控制程式，因此他們提供開源的函式庫給你用，搭配自家整合好的in-app control widget，像是影片中Blynk App中做好的LED按鈕，幾分鐘內讓App與板子互動。
你應該有看到影片最一開始的Dynamic provisioning，就是前述提到的Device provision。
如果你有認真看影片，你會聽到Anna說：WiFi 名稱、WiFi 密碼、Blynk Authentication Token。
- 向Blynk註冊後，將提供的Token貼到控制程式中並將此程式燒錄在板子
- 拿起手機連上板子提供的WiFi，輸入你所指定的WiFi SSID、Password，板子連上前述指定WiFi
- 板子建立網際網路連線成功，呼叫遠端Blynk Cloud，步驟1的Token被識別，於是Blynk知道屬於你的板子連上雲了。
這整個流程與我們在前一篇文章、前一段描述是一致的，只是相比Amazon IoT 、Azure IoT 等物聯網服務商更為謹慎的驗證流程，Blynk IoT 透過簡化的驗證流程與登入的使用者限制存取 IoT資源。
所以你能按下Blynk App做好的“ON” Button，向Blynk Cloud發出請求，Blynk Cloud找到你的裝置後，轉發請求資料給裝置，裝置透過板子的控制程式，便知道你需要它改變自身狀態成“ON”，完成後回報給Cloud，最終你的App按鈕從”OFF”變成“ON”。
Blynk簡化許多事情像是：
不用打造一個讓裝置能夠連上WiFi的綁定流程
不用設計按下Button時的指令格式，開/關要用字串還是布林呢；
不用實作App上的元件，以及按下開/關時，發出伺服器請求的事件處理；
不用撰寫伺服器與裝置之間的溝通，請求與轉發，還要找對裝置與使用者；
不用處理裝置離線問題，你需要在互動中將裝置離線的狀態考量進去；
（還有其他）
如果你只想要打造Protoype，那Blynk的確很合適，有所見即所得的App元件、完整的文件、開源程式碼簡化很多maker會遇到的問題。
你說只是想要打造Protoype是什麼意思？
你可以試著在App Store、Google Store 搜尋PLAATO，會發現這個App一樣由Blynk開發，只是長得有點不太一樣？
PLAATO是與Blynk合作的物聯網應用商，他們做了很酷的物聯網裝置，供釀酒容器使用，即時紀錄 CO2、Original Gravity等指標，透過該App存取裝置蒐集的資料，解決自釀者的問題。
為什麼PLAATO不用已經整合好的Blynk App 5 分鐘開發完畢？
硬體不一樣，需要的控制邏輯不一樣，且產生的資料不再是只有LED Button 開關 on/off ，資料種類、屬性、大小不一樣；
App使用的元件長得不一樣，像是PLAATO有美麗、即時繪製的圖表；
體驗不一樣，總希望產品所搭配的App擁有最獨特最棒的UI/UX設計跟不同的Navigation flow；
部署流程不一樣，產品大規模製造後，裝置認證不可能使用影片中的方式；
換句話說，不同的硬體裝置、不同使用場域、不同使用情境，會有不同的IoT Mobile App開發過程，但裝置認列、控制（資源存取）、條件作動是多數物聯網應用的共同情境，我們接續看其他案例。
連線公司、連線App、連線物聯網平台
Line推出的Line Things主張消滅以下問題：
透過大家習慣使用的Line App，裝置搜集的資料最終會送至開發者開發的聊天機器人，與前端框架LIFF呈現服務畫面（如文章中的開關按鈕）。與前述Blynk函式庫整合了裝置的WiFi功能類似，Line透過目前開放的裝置類型，還實作了行動裝置（Line App ）與 Bluetooth LE的通訊。
也就是說，打開Line Things便可以使用LIFF介面，透過藍芽通訊協定與裝置互動，製作開關門鎖、LED Button等應用；同時Line 處理了裝置蒐集資料(提供範例裝置韌體程式碼)及資料傳遞（Line Platform）的過程。
你可以在這篇介紹Line Things文章的最後看到：
以往，我們雖然也透過直接將Wi-Fi以及LTE置入IoT裝置的形式，成功提供了相同的用戶體驗。但我認為像是使用電池的攜帶型裝置，以及WiFi訊號無法觸及的室外進行使用的情境下，可以透過省電又低廉的Bluetooth LE，並且不需安裝專用的APP就可以實現，恰恰正是LINE Things的優點。
這正是Line Things所實現的好處，雖然Line Things看起來在Preview 階段，等待更多的開發者投身項目創造生態圈，但筆者認為簡易的物聯網應用，可以選擇Line Things做為應用的介面與控制選擇，且Line App擁有廣大的使用者遍佈日、韓、台灣等亞洲國家，Line App沒有重新學習的成本。
客製化的流程與服務體驗是重要考量的話，獨立的IoT Mobile App開發顯然比較合適，或搭配部分介面鑲嵌在Line App中，使用者也能在使用Line App時持續使用部分服務。
若在較為複雜的物聯網應用下，資料存取與裝置互動在Line App上一樣會有難以使用、管理的問題。
軟領專注在大型場域的物聯網應用，我們會在下一個篇幅以其他真實物聯網應用開始，再接續分享軟領在工業監控、智慧城市解決方案中打造IoT Mobile App的經驗。
