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