原標題:Google公布I/O 2017 for Android的源程式碼

Google公布I/O 2017 for Android的源程式碼

我們公布了官方 Google I/O 2017 for Android 應用的源程式碼:

https://github.com/google/iosched

今年的應用對現有功能做出了實質性的修改,同時增加了幾項新功能。它還擴展了技術棧,以便可以利用 Firebase。在此文中,我們將重點介紹該應用的幾個顯著改變以及它們的設計考慮。

2017 版最突出的一項新功能是會議預訂系統,該系統旨在幫助節省現場參會者的時間並提供簡潔順暢的會議體驗。註冊的參會者可在會前或大會期間預訂會議並加入等待列表;預訂可以快速進入會場,而不必排上漫長的隊伍。預訂數據與參會者的大會胸卡同步,這樣,會議工作人員可以使用啟用 NFC 的手機核實預訂數據。預訂功能不僅大受歡迎,預訂數據也幫助會議工作人員在 I/O 會前或大會期間改變會議室大小,以適應實際的座位需求。

Google公布I/O 2017 for Android的源程式碼

此預訂功能是使用 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 客戶端同步(數據本身存儲在數據存儲區中)。

Google公布I/O 2017 for Android的源程式碼

儘管 RTDB 提供開箱即用的數據同步功能,我們還是希望確保使用者的預訂數據在所有設備上都是最新的, 即使應用未在前台運行。 我們使用一個雲函數將 RTDB 預訂數據集成到同步流中:一旦 RTDB 中更改了使用者的預訂數據,該函數即會更新端點,而這會觸發向所有使用者設備發送一個 Firebase 雲消息傳遞下行消息,隨後即會計劃數據同步。

Google公布I/O 2017 for Android的源程式碼

今年的應用還提供了一個資訊流的功能,向使用者每小時通報 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