Google 发布了 I/O 大会 App 的最新源代码

近日 Google 放出了 Google I / O 2017的官方 Android 应用的源代码

今年这个应用对现有功能做了很大的修改,并且也添加了几个新功能。它也探索了使用 Firebase 的技术栈。在这篇文章中,我们将突出展示应用的几个显著变化及其设计注意事项。

2017 年最突出的新功能是活动预订系统,其旨在帮助去现场参加活动者节省时间,并提供流畅的的参会体验。活动注册者可以在活动开始之前和活动期间保留活动并加入候补名单;另外预订系统也提供了快速进入会议而无需长时间等待。预约数据与参加者的会议参会证同步,允许参会人员使用支持 NFC 的手机验证预约。不仅预订功能非常受欢迎,而且预订数据帮助活动组织人员在 I / O 之前预估会议室的大小,以适应实际的座位需求。

预约功能使用 Firebase 实时数据库(RTDB)和 Cloud Functions 实现。 RTDB 在用户设备之间提供了非常方便的同步功能 – 只需要在代码中实现一个监听器来接收数据库更新就可以了。 RTDB 还提供开箱即用的离线支持,即使在旅行期间间歇性网络连接时也允许会议数据可用。云功能在后台处理用户的预约请求,使用事务来确保状态的正确性(防止恶意用户抢占太多的座位!)并与活动证件系统进行通信。

像往年一样,这个应用使用 ContentProvider 作为所有应用数据的抽象层,这意味着必须弄清楚如何将 RTDB 数据与 ContentProvider 整合在一起。因此需要在两个本地数据缓存之间进行协商:1.通过 ContentProvider 访问的本地 SQLite 数据库;2.由 RTDB 创建的本地缓存以便于无网络时的访问。所以决定将 ContentProvider 中的所有应用数据整合在一起:每当用户在 RTDB 中更改预约数据时,可以通过 ContentProvider 来更新数据,确保应用只有唯一一个数据来源。这意味着只需要在单个屏幕上持有与 RTDB 的开放连接即可,即活动详细信息 Activity,用户可能会在这里管理他们的预约。应用其他部分显示的预约数据由 ContentProvider 提供。在离线模式下或者在与 RTDB 连接不稳定或延迟的情况下,我们可以从 ContentProvider 获取到用户保留的最后一个已知状态。

另外还必须找出将 RTDB 整合到 IOSched 的整体同步逻辑中的良好模式,特别是由于RTDB 具有与我们在应用中使用的 ping-and-fetch 方法使用的同步模型有很大的不同。我们决定继续使用云端点(Cloud Endpoints)的方式来实现跨设备和网络和 iOS 客户端同步用户数据(数据本身存储在数据存储区 (Datastore)中)。虽然 RTDB 提供实时的数据同步,但我们希望确保用户的预约数据在所有设备上都是最新数据,即使应用不在前台。我们使用 Cloud Function 功能将 RTDB 预约数据集成到同步流中:一旦在 RTDB 中更改了用户的预约数据,也会同步更新到云端点,从而触发 Firebase Cloud Messaging 给下游所有用户的设备发送消息,然后调度数据同步。

今年的应用程序还提供了一个 Feed 来向用户介绍 I/O 的活动动态(大多数应用的用户偏远,Feed 是他们获取的活动信息的一个窗口)。 Feed 也由 RTDB 提供支持,数据使用简单的 CMS 推送到服务器。我们使用云函数 (Cloud Function) 功能来监听 RTDB 的 Feed 数据;当在服务器上的 Feed 数据更新时,云函数会向客户端发送一个 Cloud Messaging 消息,从而在用户的 Feed 上展示最新的 Feed 数据。

在 2015 年和 2016 年, IOSched 采用了 MVP 的架构,今年还是这个架构模式,这种架构提供了很好的隔离,便于测试,并且使我们的代码更简介和更易于维护。对于 Feed 功能,受 Android Architecture Blueprints 启发我们决定尝试使用更轻量级的 MVP 实现,它提供必要的模块化,同时也非常容易理解。这样做的目的是教学和实践:我们想为开发者展示一个可替换的 MVP 模式;我们还想展示一种适合我们功能需求的架构。

IOSched 首次大量的使用了 Firebase 远程配置 (Firebase Remote Config) 功能。在过去,在会议之前或会议期间,我们发现当没有会议数据的时候无法通知用户,以及无线上网信息,班车时间表,优惠代码等信息。强制应用更新是不可行的;我们只想让应用内默认值可更新。使用远程配置可以很容易的解决我们遇到的这个问题。

最后,我们以这个三层系统的主要变更信息来结束这篇文章:

  1. 会议数据和用户数据的更新通过云消息传递和数据同步(ping和fetch模型)进行通信。
  2. Feed 数据变化通过 RTDB 进行控制。
  3. 通过远程配置控制对应用程序内常量的更改。

未来的计划

即使我们发布了 2017 年的代码,我们仍然在未来几个月内提前完成工作。我们将更新代码以遵循现代模式进行后台处理(并使我们的应用兼容 Android O),并且将来我们将采用Android 的架构组件 (Architecture Components) 来简化应用的整体设计。开发者可以按照GitHub 上的代码进行更改。

编译:谷饭  原文:Android Developers Blog 配图:Android Developers Blog

分享到
label, , , , , , , , ,

About the author

Add a Comment

电子邮件地址不会被公开。 必填项已用*标注