# Smarter Shared Kotlin Flows

DevFeed: [Smarter Shared Kotlin Flows](<https://devfeed.tech/articles/smarter-shared-kotlin-flows-25883.md>)

Original publisher: [Read original article](<https://bladecoder.medium.com/smarter-shared-kotlin-flows-d6b75fc66754?source=rss-54910f05af37------2>)

Author: Christophe Beyls

Published: 2022-06-06T16:44:02Z

Content type: tutorial

Language: en

Sources: [Stories by Christophe Beyls on Medium](<https://devfeed.tech/sources/stories-by-christophe-beyls-on-medium.md>)

Topics: [kotlin-flow](<https://devfeed.tech/topics/kotlin-flow.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Android](<https://devfeed.tech/topics/android.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [database](<https://devfeed.tech/tags/database.md>), [efficiency](<https://devfeed.tech/tags/efficiency.md>), [flow](<https://devfeed.tech/tags/flow.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-flow](<https://devfeed.tech/tags/kotlin-flow.md>), [livedata](<https://devfeed.tech/tags/livedata.md>), [sharedflow](<https://devfeed.tech/tags/sharedflow.md>)

## AI overview

This second article in a Kotlin Flow on Android series explains how SharedFlow and StateFlow using SharingStarted.WhileSubscribed() can restart upstream work when a lifecycle becomes active again. It compares this behavior with lifecycle-aware LiveData and proposes designing a Flow operator that propagates lifecycle state upstream to avoid unnecessary network requests or database queries.

## Source excerpt

Make the lifecycle available to the upstream Flow to skip unnecessary work This is the second part of a series of articles about using Kotlin Flow on Android. In the first part, we described the main limitation of Kotlin Flow when used inside ViewModel classes: When a SharedFlow or StateFlow using the SharingStarted.WhileSubscribed() strategy is collected again after the user navigates back to an Activity or Fragment, its source upstream Flow will always restart from scratch, sometimes resulting in unnecessary work being performed when the previously cached data was still valid. val results: StateFlow<SearchResult> = queryFlow.mapLatest { query -> repository.search(query) }.stateIn( scope = viewModelScope, started = SharingStarted.WhileSubscribed(5000L), initialValue = SearchResult.EMPTY ) In the above example, repository.search() will be executed again even if the latest value of queryFlow didn't change in the meantime. This means a potential unnecessary network request or database query. LiveData doesn't suffer from this issue because its observers don't need to unsubscribe when they become inactive: LiveData is lifecycle-aware and will postpone the delivery of new results until it becomes active, while also ensuring that the same result will never be delivered to the same observer twice (even when it becomes active again). For more details I invite you to read the full article. At the end of this first part, we concluded that there was no simple and correct way to avoid performing this unnecessary work when relying only on the standard shareIn() or stateIn() operators. In this second part, we are going to solve that efficiency problem by designing a new Flow operator that will allow SharedFlows to integrate better with the lifecycle. Synchronizing with the LifecycleLiveData The core reason why LiveData deals with lifecycles better than Flow is because the lifecycle state is automatically propagated upstream through all the LiveData instances so they can all pause