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