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|
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.
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
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
MutableLiveDatadirectly, but that you only expose
LiveDatato outside classes because that's just going to make your code much much safer.
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|
|Don't publicly expose
So you might have noticed that I've been using both this class called
MutableLiveData, as the name implies, is
LiveDatathat could be changed. And what that means is that it exposes the
postValueare just a little bit different.
setValueis meant for being called on the main thread and then
postValuecan be called from a background thread.
LiveDataclass is sort of read-only in that you can't call, you can't change what's it using
A general rule of thumb is that you'll only ever publicly expose
LiveDataoutside of the view model. Whereas inside of the view model you could use that
MutableLiveData. So by using this encapsulation you're kind of ensuring that the view model is always the one that's doing all the editing and processing of your
LiveData, and everything outside of there is just observing the