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

檢視全文及文中連結，請點選文末“閱讀原文”。