En muchas muestras veo que:
class DataViewModel{ val data:LivaData<Int> get() = _data private val _data = MutableLiveData<Int>() }Pero más simplemente se ve así:
class DataViewModel{ val data = MutableLiveData<Int>() }Entonces, ¿por qué necesita esta construcción de código más complicada con 2 campos?
Es una práctica diseñada para restringir la modificación del valor desde fuera de la clase.
LiveData es de solo lectura. MutableLiveData , como su nombre lo indica, permite cambiar el valor que contiene.
Si expone un MutableLiveData directamente, como en su segundo ejemplo, cualquier código que pueda acceder a ese campo data también podría modificar el valor que contiene.
Exponer la capacidad de cambiar el contenido de los data desde fuera de la clase DataViewModel podría dificultar la depuración y el razonamiento acerca de dónde proviene el contenido de los data en un momento dado.
MutableLiveData es esencialmente un LiveData con acceso público a dos métodos setValue() y postValue() para modificar esos datos.
Por lo tanto, se necesita MutableLiveData si planea modificar los valores de LiveData.
Sin embargo, en programación, es un concepto común hacer que tus variables sean inmutables o restringir el acceso de aquellos que pueden modificar los datos de un objeto. No querría exponer la capacidad de modificar el contenido de las variables dentro de un objeto si no hay necesidad de hacerlo.
Por lo tanto, para MutableLiveData , normalmente usamos un captador para obtener su forma principal, que es LiveData .
Al obtener solo LiveData , podemos asegurarnos de que aquellos que accedan al objeto LiveData solo puedan leer los valores almacenados dentro sin la posibilidad de cambiarlos.
En cierto sentido, es solo el concepto de por qué debería usar variables privadas con captadores.