# I still see LiveData - where are the Flows?

DevFeed: [I still see LiveData - where are the Flows?](<https://devfeed.tech/articles/i-still-see-livedata-where-are-the-flows-32059.md>)

Original publisher: [Read original article](<https://www.maiatoday.net/p/i-still-see-livedata-where-are-the-flows/>)

Published: 2023-07-30T19:38:36Z

Content type: opinion

Language: en

Sources: [maiatoday](<https://devfeed.tech/sources/maiatoday.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [kotlin-coroutines](<https://devfeed.tech/topics/kotlin-coroutines.md>), [multiplatform](<https://devfeed.tech/topics/multiplatform.md>), [Dependency injection](<https://devfeed.tech/topics/dependency-injection.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [coroutines](<https://devfeed.tech/tags/coroutines.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [flow](<https://devfeed.tech/tags/flow.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-coroutines](<https://devfeed.tech/tags/kotlin-coroutines.md>), [live-data](<https://devfeed.tech/tags/live-data.md>), [main-thread](<https://devfeed.tech/tags/main-thread.md>), [multiplatform](<https://devfeed.tech/tags/multiplatform.md>), [network](<https://devfeed.tech/tags/network.md>), [refactor](<https://devfeed.tech/tags/refactor.md>), [thread](<https://devfeed.tech/tags/thread.md>)

## AI overview

The article argues that LiveData is appropriate for observing UI state but is a poor fit for repositories because it is tied to the Android lifecycle and always runs on the main thread. It recommends using Kotlin Flows, particularly in repositories, because they support configurable dispatchers, richer operators, and multiplatform projects.

## Source excerpt

Hammer and nail There is no doubt LiveData is an easy, lifecycle safe way to observe some state which needs to be displayed on the UI. It is just so easy to create and easy to update. It is easy to observe. I think that may be why people use it everywhere where they need a simple observation. This ok, no guilt, no harm .... for the UI layers .... but there are better solutions for domain and data layers. This is not the first time this topic has come up yet I still see Live Data in a repository offered as a good solution from time to time, in blog posts, samples and in books. I think it is a case of people think they only have a LiveData hammer. There are infact pitfalls if you use LiveData in a repository. I think it's an anti-pattern. But why not LiveData is lifecycle aware - do we need this in our repository? Repostitories are typically provided by dependency injection, they could be singletons and they don't need to know about the Android lifecycle. LiveData always runs on the main thread, you can't change this. This is not what we want in a repository. Repositories often work with different data sources which could involve network or disk access tasks. I would argue that you need to be able to run these kinds of tasks on the correct dispatcher if your libraries do not already do this. This is the deal breaker for me because you can cause jank in the UI if you do this incorrectly. LiveData does have some capabilities to combine and convert LiveData variables with MediatorLiveData but flows provide a wide variety of elegant operators to choose from. This is probably not a solid argument more a case of convenience. Lastly, one of the biggest reasons after the main thread argument, why I would advocate for converting all of the LiveData use to flows: flows are part of the Kotlin coroutines library. This means they run on any platform where Kotlin coroutines run. You can use them in a multiplatform project. Or to put it differently, if you use flows in your repository i