# Avoid backing properties for LiveData and StateFlow

DevFeed: [Avoid backing properties for LiveData and StateFlow](<https://devfeed.tech/articles/avoid-backing-properties-for-livedata-and-stateflow-25886.md>)

Original publisher: [Read original article](<https://medium.com/google-developer-experts/avoid-backing-properties-for-livedata-and-stateflow-706006c9867e?source=rss-1331e67af4e1------2>)

Author: Danny Preussler

Published: 2021-01-12T14:03:52Z

Content type: tutorial

Language: en

Sources: [Stories by Danny Preussler on Medium](<https://devfeed.tech/sources/stories-by-danny-preussler-on-medium.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [coding](<https://devfeed.tech/topics/coding.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [abstract-class](<https://devfeed.tech/tags/abstract-class.md>), [android](<https://devfeed.tech/tags/android.md>), [class](<https://devfeed.tech/tags/class.md>), [clean-code](<https://devfeed.tech/tags/clean-code.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [interface](<https://devfeed.tech/tags/interface.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-flow](<https://devfeed.tech/tags/kotlin-flow.md>), [livedata](<https://devfeed.tech/tags/livedata.md>), [stateflow](<https://devfeed.tech/tags/stateflow.md>), [val](<https://devfeed.tech/tags/val.md>), [var](<https://devfeed.tech/tags/var.md>), [viewmodel](<https://devfeed.tech/tags/viewmodel.md>)

## AI overview

This Kotlin article argues that developers can avoid duplicated backing properties when exposing LiveData and StateFlow. It proposes separating the public API from the implementation with interfaces or an abstract class, including in ViewModels.

## Source excerpt

https://unsplash.com/photos/OopPIi_A428 If you have ever worked with LiveData you probably have written code similar to this: class MyViewModel: ViewModel() { val loading: LiveData<Boolean> get() = _loading private val _loading = MutableLiveData<Boolean>()} This seems nowadays the typical way developers would expose some immutable LiveData, while being able to have a mutable version inside the implementation we would write data into. Every time I saw, or even had to write, this kind of code something cringed inside me. As I quoted in one of my talks this feeling in our brain is for real: social missteps activate regions in the brain, [..] that have been previously associated with physical pain. As developers, we know something is wrong with this code, right? It also feels like we are writing manual getters and setters here. What's wrong? We could start with the prefix we use for the backing field, although we fought hard for a long time to get rid of prefixes, we accept it here! It is even made it into the official coding conventions. But even if we rename it, it still cringes: class MyViewModel: ViewModel() { val loading: LiveData<Boolean> get() = mutableLoading private val mutableLoading = MutableLiveData<Boolean>()} This duplication feels unneeded! Especially if you write something like a ViewModel that exposed many of these, you get lost in reading the code just by all these duplications. But it's just LiveData? You might think it's just a specialty of LiveData and the future of that construct might be a more limited one. And you would not have this issue with primitives. The language supports this out of the box with a private setter: var secret: String = "Secret" private set But there is a new kid in town: StateFlow needs the same thing! Look at this snippet from the official Jetbrains blog: class DownloadingModel { private val _state = MutableStateFlow<DownloadStatus>(DownloadStatus.NOT_REQUESTED) val state: StateFlow<DownloadStatus> get() = _state This probl