LiveData was something we needed back in 2017. The observer pattern made our lives easier, but options such as RxJava were too complex for beginners at the time. The Architecture Components team created LiveData: a very opinionated observable data holder class, designed for Android. It was kept simple to make it easy to get started and the recommendation was to use RxJava for more complex reactive streams cases, taking advantage of the integration between the two.
LiveData is still our solution for Java developers, beginners, and simple situations. For the rest, a good option is moving to Kotlin Flows. Flows…
Hey Michael, I'm temporarily routing people from the SingleLiveEvent post to this one!
Have you considered having a buffered channel for snackbars and a conflated one for navigation events?
Hilt is the new library built on top of Dagger that simplifies Dependency Injection (DI) in Android apps. But, how much does it simplify it? We migrated the Google I/O app (iosched) to find out, which already used Dagger with dagger.android.
In this article I’ll go through our experience migrating this particular app. For proper and comprehensive instructions, check out the Hilt Migration Guide.
We replaced 2000 lines of DI code with just 500. This is not the only success metric, but it’s promising!
How is this reduction possible? We were using dagger.android which also promised some boilerplate reduction in…
This article is part III of a summary of the talk I gave with Yigit Boyar at the Android Dev Summit 2019.
Part III: LiveData and Coroutines patterns (this post)
Let’s look at some patterns that can be used in ViewModels, comparing LiveData and Flow usages:
If we don’t do any transformations, we can simply assign one to the other.
We could use a combination of the
liveData coroutine builder and collect on the Flow (which is a terminal operator that…
This article is part II of a summary of the talk I gave with Yigit Boyar at the Android Dev Summit 2019.
Part II: Launching coroutines with Architecture Components (this post)
Jetpack’s Architecture Components provide a bunch of shortcuts so you don’t have to worry about Jobs and cancellation. You simply have to choose the scope of your opeations:
This is one of the most common ways to launch a coroutine because most data operations begin in the ViewModel. With the viewModelScope extension…
This article is a summary of the talk I gave with Yigit Boyar at the Android Dev Summit 2019.
Part I: Reactive UIs (this post)
Since the early days of Android, we’ve learned very quickly that Android lifecycles were hard to understand, full of edge cases, and that the best way to stay sane was to avoid them as much as possible.
For this, we recommend a layered architecture, so we can write UI-independent code without thinking too much about…
Next time you’re scratching your head wondering why an innocent looking unit test with LiveDatas is failing, or staring at an empty screen that should show… something, you should remember that a LiveData that is not observed won’t emit updates. In this post you’ll learn some good practices to avoid this problem.
This is especially important when dealing with Transformations. If a LiveData is transformed, the result of the transformation must be observed. Otherwise the transformation will never be evaluated.
If a LiveData falls in a forest and no one is observing it… was it ever updated?
In this example…
If you know why you need Idling Resources, you can jump to the next section
Espresso’s main advantage over other UI testing frameworks is that it synchronizes with your app. This means that it will only make assertions and perform actions when your app is idle (waiting for user input). Other testing frameworks wait until a certain condition is met (a view is displayed for example) but this has proved problematic in a lot of situations and led to flaky tests. Other frameworks rely on you guessing the time a certain operation will take. This makes tests slow and doesn’t…
TL;DR: Expose resource IDs from ViewModels to avoid showing obsolete data.
In a ViewModel, if you’re exposing data coming from resources (strings, drawables, colors…), you have to take into account that ViewModel objects ignore configuration changes such as locale changes. When the user changes their locale, activities are recreated but the ViewModel objects are not.
AndroidViewModel is a subclass of
ViewModel that is aware of the Application context. However, having access to a context can be dangerous if you’re not observing or reacting to the lifecycle of that context. …
One of the most important features of Data Binding is observability. It allows you to bind data and UI elements so that when the data changes, the pertinent elements are updated on screen.
Plain primitives and Strings are not observable by default so if you use them in your Data Binding layouts, their values will be used when the binding is created but subsequent changes to them will be ignored.
To make objects observable, we included in the Data Binding Library a series of observable classes:
ObservableDouble… and the generic ,
Developer Relations Engineer @ Google, working on Android