Google公布I/O 2017 for Android的源代碼
我們公布了官方 Google I/O 2017 for Android 應(yīng)用的源代碼：
https://github.com/google/iosched。
今年的應(yīng)用對現(xiàn)有功能做出了實質(zhì)性的修改，同時增加了幾項新功能。它還擴展了技術(shù)棧，以便可以利用 Firebase。在此文中，我們將重點介紹該應(yīng)用的幾個顯著改變以及它們的設(shè)計考慮。
2017 版最突出的一項新功能是會議預(yù)訂系統(tǒng)，該系統(tǒng)旨在幫助節(jié)省現(xiàn)場參會者的時間并提供簡潔順暢的會議體驗。注冊的參會者可在會前或大會期間預(yù)訂會議并加入等待列表;預(yù)訂可以快速進入會場，而不必排上漫長的隊伍。預(yù)訂數(shù)據(jù)與參會者的大會胸卡同步，這樣，會議工作人員可以使用啟用 NFC 的手機核實預(yù)訂數(shù)據(jù)。預(yù)訂功能不僅大受歡迎，預(yù)訂數(shù)據(jù)也幫助會議工作人員在 I/O 會前或大會期間改變會議室大小，以適應(yīng)實際的座位需求。
此預(yù)訂功能是使用 Firebase Realtime Database (RTDB) 和 Cloud Functions for Firebase 來實現(xiàn)的。RTDB 可在不同用戶設(shè)備之間輕松同步，我們只需要在代碼中實現(xiàn)一個偵聽器來接收數(shù)據(jù)庫更新。RTDB 還提供開箱即用的離線支持，即使是在旅行期間網(wǎng)絡(luò)連接斷斷續(xù)續(xù)時，也能獲取會議數(shù)據(jù)。一個云函數(shù)在后臺處理用戶的預(yù)訂請求，使用事務(wù)來確保狀態(tài)的正確性(防止頑皮的用戶預(yù)訂太多座位!)并與會議胸卡系統(tǒng)通信。
在往屆大會中，我們使用 ContentProvider 作為所有應(yīng)用數(shù)據(jù)之上的抽象層，這意味著，我們必須確定如何將 RTDB 數(shù)據(jù)集成到 ContentProvider。我們需要在兩個本地數(shù)據(jù)緩存方案之間權(quán)衡考慮：
1) 通過 ContentProvider 訪問的現(xiàn)存本地 SQLite 數(shù)據(jù)庫，
2) RTDB 創(chuàng)建的本地緩存，用于支持離線訪問。我們決定將所有應(yīng)用數(shù)據(jù)集成到 ContentProvider 中：一旦 RTDB 中更改了用戶的預(yù)訂數(shù)據(jù)，我們即會更新 ContentProvider，使之始終成為應(yīng)用數(shù)據(jù)的單一可信來源。這意味著，我們需要只在 Session Detail Activity 這個屏幕中保持對 RTDB 的開放連接，在這里，用戶可以主動管理他們的預(yù)訂。在應(yīng)用的其他部分顯示的預(yù)訂數(shù)據(jù)由 ContentProvider 提供支持。在離線模式下，或者如果到 RTDB 的連接斷斷續(xù)續(xù)或者延時嚴重，我們只需從 ContentProvider 獲取用戶預(yù)訂數(shù)據(jù)的最近已知狀態(tài)。
我們還必須設(shè)計出好的方案，將 RTDB 集成到整個 IOSched 同步邏輯中，尤其是由于 RTDB 提供的同步模型與我們之前在該應(yīng)用中使用的先 ping 再 fetch 的方法大不相同。我們決定繼續(xù)使用 Cloud Endpoints 在各個設(shè)備之間同步用戶數(shù)據(jù)并與網(wǎng)絡(luò)和 iOS 客戶端同步(數(shù)據(jù)本身存儲在數(shù)據(jù)存儲區(qū)中)。
盡管 RTDB 提供開箱即用的數(shù)據(jù)同步功能，我們還是希望確保用戶的預(yù)訂數(shù)據(jù)在所有設(shè)備上都是***的， 即使應(yīng)用未在前臺運行。 我們使用一個云函數(shù)將 RTDB 預(yù)訂數(shù)據(jù)集成到同步流中：一旦 RTDB 中更改了用戶的預(yù)訂數(shù)據(jù)，該函數(shù)即會更新端點，而這會觸發(fā)向所有用戶設(shè)備發(fā)送一個 Firebase 云消息傳遞下行消息，隨后即會計劃數(shù)據(jù)同步。
今年的應(yīng)用還提供了一個資訊流的功能，向用戶每小時通報 I/O 上的進展動態(tài)(該應(yīng)用的大多數(shù)用戶都在遠程，資訊流是他們了解大會的窗口)。資訊流也由 RTDB 驅(qū)動，通過簡單的 CMS 將數(shù)據(jù)推送到服務(wù)器。我們使用一個云函數(shù)來監(jiān)控 RTDB 資訊流數(shù)據(jù)，當在服務(wù)器上更新資訊流數(shù)據(jù)時，該函數(shù)將向客戶端發(fā)送一個云消息傳遞下行消息，后者會以視覺形式通知用戶存在新的資訊流項目。
在 2015 年和 2016 年，我們一直采用 MVP 架構(gòu)的 IOSched，今年，我們繼續(xù)使用該架構(gòu)。這種架構(gòu)很好地分離了關(guān)注問題，方便測試，并且總體上使我們的代碼更整齊，更易于維護。對于資訊流功能，受到 Android 架構(gòu)藍圖的啟發(fā)
(https://github.com/googlesamples/android-architecture)，我們決定試驗一種更輕量級的 MVP 實現(xiàn)方法，該方法提供必要的模塊化，同時又非常容易概念化。其目標兼具教育性和實踐性：我們希望為開發(fā)者示范一種備用的 MVP 模式;我們還希望展示一種適合我們對此功能的需求的架構(gòu)。
IOSched ***大量使用了 Firebase Remote Config。在過去，我們發(fā)現(xiàn)自己無法在大會之前或大會期間通知用戶非會議數(shù)據(jù)的更改：WiFi 信息、巴士時刻表、拼車折扣代碼等。強制應(yīng)用更新并不可行;我們只希望更新應(yīng)用內(nèi)的默認值。使用遠程配置可以輕松解決我們的這個問題。
***，我們設(shè)計出一套三層系統(tǒng)，用于通知用戶上述更改：
- 通過云消息傳遞和數(shù)據(jù)同步(先 ping 再 fetch 模型)傳達大會數(shù)據(jù)和用戶數(shù)據(jù)更改。
- 資訊流數(shù)據(jù)更改通過 RTDB 進行控制。
- 對應(yīng)用內(nèi)常量的更改通過遠程配置進行控制。
未來計劃
盡管我們公布了 2017 年代碼，未來幾個月我們?nèi)杂泄ぷ饕?。我們將要更新代碼，以遵循后臺處理的現(xiàn)代模式(并使我們的應(yīng)用兼容“O”)，未來，我們將采用 Android 的架構(gòu)組件來簡化應(yīng)用的總體設(shè)計。開發(fā)者可以在 GitHub 上跟蹤此代碼的更改情況：
https://github.com/google/iosched
【本文是51CTO專欄機構(gòu)“谷歌開發(fā)者”的原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者(微信公眾號：Google_Developers)】
