Путаница с LiveData в приложении [Android] Plaid - PullRequest
Новая
       79

Путаница с LiveData в приложении [Android] Plaid

0 голосов
/ 25 марта 2020

Я имею в виду проект с открытым исходным кодом Plaid на github Ссылка на Plaid

Это отличный источник для изучения новых техник на Android.

Когда я просматривал код, я наткнулся на определенный стиль кодирования около LiveData, который я действительно не понимал. Если кто-нибудь может помочь мне получить это. Вот так:

Есть ViewModel(vm) с этим фрагментом кода: 

private val _openLink = MutableLiveData<Event<String>>()
val openLink: LiveData<Event<String>>
    get() = _openLink

Довольно просто? Обратите внимание, что здесь есть 2 переменных: openLink и _openLink. Получатель для openLink возвращает _openLink LiveData.

В действии они наблюдают за openLink LiveData следующим образом: 

viewModel.also { vm ->

       vm.openLink.observe(this, EventObserver { openLink(it) })

        ..... // Other stuff
}

Теперь, другие жилаты _openLink вызывается пользовательским интерфейсом, предположительно, по нажатию кнопки, и определяется следующим образом: 

fun viewShotRequested() {
    _shotUiModel.value?.let { model -> // ignore this part
        _openLink.value = Event(model.url) // setValue on _openLink
    }
}

Итак, мое понимание состоит в том, что на setValue() на _openLink будет вызван EventObserver{openLink(it)}. Мой вопрос: почему они сделали это так?

Вопросы:

  1. Почему бы не наблюдать непосредственно на _openLink?

  2. Не будет ли это иметь тот же эффект? Что мне здесь не хватает?

Ответы [ 3 ]

1 голос
/ 25 марта 2020

Свойство MutableLiveData не должно быть открыто: оно изменчиво и может быть изменено в любом месте вашей программы. Вот почему вместо этого выставляется LiveData: он отвечает за обновление вашего свойства и использует MutableLiveData в качестве вспомогательного поля. Исключением является двухсторонняя привязка данных, где потребуется прямой доступ к значению.

1 голос
/ 30 марта 2020

Мой вопрос: почему они сделали это так?

Поскольку Google, очевидно, нравится писать больше кода ради написания большего количества кода.

Предполагаемое ответьте, если вы склонны верить им, что LiveData<Event<T>> предпочтительнее, чем SingleLiveData, потому что они придумали его позже, чем LiveData<Event<T>> и, следовательно, предположительно лучше .

Они намереваются использовать «очередь событийной шины, которая забывает элементы после того, как она была отправлена ​​хотя бы одному наблюдателю», но Jetpack не предлагает такой концепции «из коробки», лично Мне пришлось написать одну из своих,

Несмотря на это, существует различие между тем, можете ли вы писать во что-то, и можете ли вы только читать из чего-то, но не писать в это самостоятельно. В этом случае только ViewModel хочет иметь возможность отправлять события, поэтому именно ViewModel содержит ссылку Mutable__, но предоставляет обычный LiveData для внешнего мира (в моем случае, EventEmitter против EventSource).

Что касается _, то это стиль Kotlin, который, мы надеемся, однажды изменится, как вы могли бы сделать: 

private val _openLink = MutableLiveData<Event<String>>()
val openLink: LiveData<Event<String>>
    get() = _openLink

Но вы также можете do 

private val openLink = MutableLiveData<Event<String>>()
fun openLink(): LiveData<Event<String>> = openLink

И таким образом мы могли бы отказаться от префикса _ в нашем собственном коде, но по какой-то причине авторы Kotlin не придумали это соглашение вовремя.

1 голос
/ 25 марта 2020

_openLink изменчиво. Вы должны всегда выставлять что-то, что является неизменным и не может быть изменено вашим наблюдателем, потому что это должно быть сделано только вашей ViewModel, даже если показ _openLink не будет иметь никакого эффекта.

Вот почему вам нужно выставить openLink который является неизменным. 

private val _openLink = MutableLiveData<Event<String>>()
val openLink: LiveData<Event<String>> = _openLink
...