# Don't expose `MutableLiveData`

## Example from [Android Jetpack: LiveData](https://youtu.be/OMcDk2_4LSk?t=65)

| MutableLiveData Example |
|--|
| ![MutableLiveData Example](https://user-images.githubusercontent.com/117582/50354468-815ceb00-0500-11e9-82ae-571e17ce7ebe.png) |

## [Fun with LiveData (Android Dev Summit '18)](https://youtu.be/2rO4r-JOQtA?t=855)

### Transformation Setup

The third item is about where and when to create your transformations and this is all about wiring.  It's similar to when you create a circuit.  You lay down your components and you wire everything up. And for a known set of inputs you're going to have a known set of outputs. You don't unplug a wire while it's in operation and plug it somewhere else, right?

This is exactly what this view model is doing.  Lots of horrible things happening in this view model, by the way.  For starters ...

| Don't do this |
|--|
| ![screen shot 2018-12-21 at 9 31 03 am](https://user-images.githubusercontent.com/117582/50355359-46a88200-0503-11e9-95f6-bee1f32a923e.png) |

B: You should [show] "don't do this" on this slide

A: It says "don't do this", literally.

B: I'm sure someone will copy/paste it and blame us for recommending it.

A: That's the standard way of doing it.

A: So first, it's exposing `itemData`, which is a variable. It's a [var] not a [val].  And also, it's exposing a `MutableLiveData`. Almost ... You should almost never do this. Two-way DataBinding is an exception to this, maybe.  You should always expose something that is immutable so your observers can't change it.

...

## [Example of two-way DataBinding](https://youtu.be/T-nQP9fidKU?t=1324)

And because we are using this property for two-way DataBinding, we need to expose it as `MutableLiveData`, because otherwise the layout won't be able to access the `value` property of `MutableLiveData`. Which is sad that we really need to expose `MutableLiveData`, but hey, if it's gonna save us some time and effort, why not?  However, if you're aren't using two-way DataBinding, I would _always_ suggest that you don't expose `MutableLiveData` directly, but that you only expose `LiveData` to outside classes because that's just going to make your code much much safer.

## [Lifecycle, LiveData, ViewModels - The inner wiring by Florina Muntenescu, Google EN](https://youtu.be/U6Lgym1XEBI?t=788)

So, the class that would help you set these values to the LiveData is the MutableLiveData.  You would use the postValue method to set the values on a background thread and setValue when you're setting the values from the main thread. 

So, especially if you're using Kotlin, something that I don't like its to expose this Mutable object to the outside of the class.  So what I prefer to do is to expose the LiveData object and use a backing field that is a MutableLiveData.  So like this, I ensure that only the class that I'm working in can change the LiveData, so I'm still keeping this immutability principle.

| Don't do this | Do this |
|--|--|
| ![screen shot 2018-12-21 at 9 56 21 am](https://user-images.githubusercontent.com/117582/50356462-dac81880-0506-11e9-939a-eeec04cdf8b2.png) | ![screen shot 2018-12-21 at 9 56 41 am](https://user-images.githubusercontent.com/117582/50356465-de5b9f80-0506-11e9-9e0b-1ade72164825.png) |