# live data

Published articles for live data.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## The 3 (+2) ways to Get Data in Power BI, simply explained

DevFeed: [The 3 (+2) ways to Get Data in Power BI, simply explained](<https://devfeed.tech/articles/the-3-2-ways-to-get-data-in-power-bi-simply-explained-40843.md>)

Original publisher: [Read original article](<https://mutto.fyi/posts/2024/04/types-powerbi-connection/>)

Published: 2024-04-01T00:00:00Z

Content type: tutorial

Language: en

Sources: [Mutt0-ds Notes](<https://devfeed.tech/sources/mutt0-ds-notes.md>)

Topics: [data](<https://devfeed.tech/topics/data.md>), [datasets](<https://devfeed.tech/topics/datasets.md>), [Database](<https://devfeed.tech/topics/database.md>)

Tags: [data](<https://devfeed.tech/tags/data.md>), [database](<https://devfeed.tech/tags/database.md>), [dataset](<https://devfeed.tech/tags/dataset.md>), [excel](<https://devfeed.tech/tags/excel.md>), [live-data](<https://devfeed.tech/tags/live-data.md>), [performance](<https://devfeed.tech/tags/performance.md>), [query](<https://devfeed.tech/tags/query.md>), [semantic](<https://devfeed.tech/tags/semantic.md>), [tutorials](<https://devfeed.tech/tags/tutorials.md>)

### AI overview

This tutorial explains how Power BI Desktop stores and retrieves report data through Import Mode, DirectQuery, Live Connection, and Composite Models. It describes the trade-offs between local copied data and live queries, including refresh needs, scalability, and performance.

### Source excerpt

There's quite a bit of confusion swirling around about how Power BI reports gather data. Where is the data actually stored? How frequently...

## 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