Udpates the README

Change-Id: Ica416e35f5394eec64e346b34db63335ce2db267

Author: JoseAlcerreca

README.md

@@ -2,19 +2,33 @@ Google I/O Android App
 ======================
 [![Build Status](https://travis-ci.org/google/iosched.svg?branch=master)](https://travis-ci.org/google/iosched)
 
-**Due to global events, Google I/O 2020 was canceled and thus an Android app
-update was not released to Google Play. However, prior to the cancellation, the
-team implemented several architecture improvements, reflected in the code
-published in June, 2020. The general look and feel of the app is unchanged, and
-the app still uses the data from Google I/O 2019.**
-
+# 2021 Update
+
+**Due to global events, Google I/O 2020 was canceled and Google I/O 2021 is an online-only event, so
+the companion app hasn't been updated since 2019. However, the `iosched` team has continued
+adding several architecture improvements to its codebase.
+The general look and feel of the app is unchanged, and the app
+still uses the data from Google I/O 2019.**
+
+Major improvements implemented in 2021:
+* Migration from LiveData to Kotlin Flows to observe data.
+* Support for large screens and other form factors.
+* Migration from SharedPreferences to [Jetpack DataStore](https://developer.android.com/topic/libraries/architecture/datastore).
+* (Experimental) Partial migration to Jetpack Compose
+(in the [`compose`](https://github.com/google/iosched/tree/compose) branch)
+
+# Description
 Google I/O is a developer conference with several days of deep
 technical content featuring technical sessions and hundreds of demonstrations
 from developers showcasing their technologies.
 
 This project is the Android app for the conference.
 
-For a simpler fork of the app, check out the [Android Dev Summit App in the adssched branch](https://github.com/google/iosched/tree/adssched). In this variant some features are removed, such as reservations and the map screen, and Instant App support is added.
+# Running the app
+
+The project contains a `staging` variant that replaces some modules at compile time so they
+don't depend on remote services such as Firebase. This allows you to try out and test the app
+without the API keys.
 
 # Features
 
@@ -37,58 +51,51 @@ during the conference in Home.
 The app is written entirely in Kotlin and uses the Gradle build system.
 
 To build the app, use the `gradlew build` command or use "Import Project" in
-Android Studio. A canary or stable version of Android Studio 4.0 or newer is
-required and may be downloaded
-[here](https://developer.android.com/studio/).
+Android Studio. Android Studio Arctic Fox or newer is required and may be downloaded
+[here](https://developer.android.com/studio/preview).
 
 # Architecture
 
 The architecture is built around
-[Android Architecture Components](https://developer.android.com/topic/libraries/architecture/).
-
-We followed the recommendations laid out in the
-[Guide to App Architecture](https://developer.android.com/jetpack/docs/guide)
-when deciding on the architecture for the app. We kept logic away from
-Activities and Fragments and moved it to
+[Android Architecture Components](https://developer.android.com/topic/libraries/architecture/)
+and follows the recommendations laid out in the
+[Guide to App Architecture](https://developer.android.com/jetpack/docs/guide). Logic is kept away
+from Activities and Fragments and moved to
 [ViewModel](https://developer.android.com/topic/libraries/architecture/viewmodel)s.
-We observed data using
-[LiveData](https://developer.android.com/topic/libraries/architecture/livedata)
-and used the [Data Binding Library](https://developer.android.com/topic/libraries/data-binding/)
-to bind UI components in layouts to the app's data sources.
+Data is observed using
+[Kotlin Flows](https://developer.android.com/kotlin/flow/stateflow-and-sharedflow)
+and the [Data Binding Library](https://developer.android.com/topic/libraries/data-binding/)
+binds UI components in layouts to the app's data sources.
 
-We used a Repository layer for handling data operations. IOSched's data comes
+The Repository layer handles data operations. IOSched's data comes
 from a few different sources -  user data is stored in
 [Cloud Firestore](https://firebase.google.com/docs/firestore/)
 (either remotely or in
 a local cache for offline use), user preferences and settings are stored in
-SharedPreferences, conference data is stored remotely and is fetched and stored
+DataStore, conference data is stored remotely and is fetched and stored
 in memory for the app to use, etc. - and the repository modules
 are responsible for handling all data operations and abstracting the data sources
-from the rest of the app (we liked using Firestore, but if we wanted to swap it
-out for a different data source in the future, our architecture allows us to do
-so in a clean way).
+from the rest of the app.
 
-We implemented a lightweight domain layer, which sits between the data layer
+A lightweight domain layer sits between the data layer
 and the presentation layer, and handles discrete pieces of business logic off
 the UI thread. See the `.\*UseCase.kt` files under `shared/domain` for
 [examples](https://github.com/google/iosched/search?q=UseCase&unscoped_q=UseCase).
 
-We used [Navigation component](https://developer.android.com/guide/navigation)
-to simplify into a single Activity app.
+The [Navigation component](https://developer.android.com/guide/navigation) is used
+to implement navigation in the app, handling Fragment transactions and providing a consistent
+user experience.
 
-We used [Room](https://developer.android.com/jetpack/androidx/releases/room)
+[Room](https://developer.android.com/jetpack/androidx/releases/room) is used
 for Full Text Search using [Fts4](https://developer.android.com/reference/androidx/room/Fts4)
 to search for a session, speaker, or codelab.
 
-We used [Espresso](https://developer.android.com/training/testing/espresso/)
-for basic instrumentation tests and JUnit and
-[Mockito](https://github.com/mockito/mockito) for unit testing.
+UI tests are written with [Espresso](https://developer.android.com/training/testing/espresso/)
+and unit tests use Junit4 with
+[Mockito](https://github.com/mockito/mockito) when necessary.
 
-For 2020, we added several Jetpack libraries:
-
-- We added the
-[Jetpack Benchmark library](https://developer.android.com/studio/profile/benchmark).
-The Benchmark library makes it easy to benchmark your code from within Android Studio.
+The [Jetpack Benchmark library](https://developer.android.com/studio/profile/benchmark)
+makes it easy to benchmark your code from within Android Studio.
 The library handles warmup, measures your code performance, and outputs benchmarking
 results to the Android Studio console. We added a few benchmark tests around
 critical paths during app startup - in particular, the parsing of the bootstrap
@@ -104,14 +111,12 @@ benchmark:    76,076,101 ns BootstrapConferenceDataSourceBenchmark.benchmark_jso
 Tests ran to completion.
 ```
 
-- We migrated from [dagger-android](https://google.github.io/dagger/android.html) to
-[Hilt](https://developer.android.com/training/dependency-injection/hilt-android)
-for dependency injection. This allowed us to remove 75% of the dependency
-injection code, and also resulted in a 13% build time improvement.
+Dependency Injection is implemented with
+[Hilt](https://developer.android.com/training/dependency-injection/hilt-android). For more details
+on migrating from *dagger-android* to Hilt, read the
+([migration article](https://medium.com/androiddevelopers/migrating-the-google-i-o-app-to-hilt-f3edf03affe5).
 
-- We migrated to
-[ViewPager2](https://developer.android.com/training/animation/screen-slide-2)
-for our view paging needs. ViewPager2 offers enhanced functionality over the
+[ViewPager2](https://developer.android.com/training/animation/screen-slide-2) offers enhanced functionality over the
 original ViewPager library, such as right-to-left and vertical orientation support.
 For more details on migrating from ViewPager to ViewPager2, please see this
 [migration guide](https://developer.android.com/training/animation/vp2-migration).
@@ -120,7 +125,7 @@ For more details on migrating from ViewPager to ViewPager2, please see this
 
 The app makes considerable use of the following Firebase components:
 
--  [Cloud Firestore](https://firebase.google.com/docs/firestore/) is our source
+- [Cloud Firestore](https://firebase.google.com/docs/firestore/) is our source
 for all user data (events starred or reserved by a user). Firestore gave us
 automatic sync  and also seamlessly managed offline functionality
 for us.
@@ -132,26 +137,23 @@ let us inform the app about changes to conference data on our server.
 - [Remote Config](https://firebase.google.com/docs/remote-config/) helped us
 manage in-app constants.
 
-For 2020, we migrated to the Firebase Kotlin extension (KTX) libraries to
+For 2020, the implementation was migrated to the Firebase Kotlin extension (KTX) libraries to
 write more idiomatic Kotlin code when calling Firebase APIs. To learn more,
 read this
 [Firebase blog article](https://firebase.googleblog.com/2020/03/firebase-kotlin-ga.html)
 on the Firebase KTX libraries.
 
 ## Kotlin
 
-We made an early decision to rewrite the app from scratch to bring it in line
-with our thinking about modern Android architecture. Using Kotlin for the
-rewrite was an easy choice: we liked Kotlin's expressive, concise, and
-powerful syntax; we found that Kotlin's support for safety features for
-nullability and immutability made our code more resilient; and we leveraged the
-enhanced functionality provided by
+The app is entirely written in Kotlin and uses Jetpack's
 [Android Ktx extensions](https://developer.android.com/kotlin/ktx).
 
-For 2020, we migrated to
-[coroutines](https://developer.android.com/kotlin/coroutines)
-for asynchronous tasks. Coroutines is the recommended way to do asynchronous
-programming in Kotlin. We also migrated our build scripts to
+Asynchronous tasks are handled with
+[coroutines](https://developer.android.com/kotlin/coroutines). Coroutines allow for simple
+and safe management of one-shot operations as well as building and consuming streams of data using
+[Kotlin Flows](https://developer.android.com/kotlin/flow).
+
+All build scripts are written with the
 [Kotlin DSL](https://docs.gradle.org/current/userguide/kotlin_dsl.html).
 
 # Copyright