DG
Но планируем перейти на гугловскую ViewModel в качестве холдера для PresentationModel. Насколько я знаю, это единственный стандартный механизм для обработки смены конфигурации.
Size: a a a
2018 June 18
RC
Но планируем перейти на гугловскую ViewModel в качестве холдера для PresentationModel. Насколько я знаю, это единственный стандартный механизм для обработки смены конфигурации.
есть еще лоадеры =)))
AC
есть еще лоадеры =)))
... в пороховницах
RC
Привет, используется Васина либа Outlast, механизм аналогичный что и в мокси
тут Tag это имя класса?
DG
есть еще лоадеры =)))
Да, я и забыл о их существовании )
RC
гайз, раскажите плз из своего опыта почему и когда для вас RxPM лучше чем MVP+Moxy?
VC
гайз, раскажите плз из своего опыта почему и когда для вас RxPM лучше чем MVP+Moxy?
Рома, привет! Было бы хорошо, чтобы тебе кто-то из группы кроме нас с Димой ответил. 😉 Мы то ясно чего и почему.
RC
ну я на это и рассчитываю =)
KK
ну я на это и рассчитываю =)
Биндинг через Rx. Нам не надо императивно прокидывать данные через вью-интерфейс, и мы проводим реактивную цепочку от самого получения данных до их представления. Это удобно и безопасно
KK
Т.е. можно построить цепочку от retrofit'а до RecyclerView Adapter
RC
Биндинг через Rx. Нам не надо императивно прокидывать данные через вью-интерфейс, и мы проводим реактивную цепочку от самого получения данных до их представления. Это удобно и безопасно
спасибо за ответ. =) но хочется больше деталей. почему удобней и почему безопасней
RC
чисто теоретически понятно, что единообразие и вот это все и не надо выходить из rx прямо до самого потребителя данных по вью
RC
но так или иначе сам андроид фреймворк императивный - выход все равно происходит и мы дергаем adapter.setItems() вне rx среды
KK
спасибо за ответ. =) но хочется больше деталей. почему удобней и почему безопасней
В мокси мы, как правило, сначала строим цепочку до презентера, а сам презентационный слой у нас императивный, что вносит в архитектуру неоднородность. Получаются презентеры содержат много логики и интегрируются и интеракторами через Rx. А так мы строим цепочку данных напрямую до вьюхи
RC
в данном конкретном случае я не вижу выигрышь, какая собственно разница где выйти из rx во вью или в презентере и дернуть метод на вью
KK
но так или иначе сам андроид фреймворк императивный - выход все равно происходит и мы дергаем adapter.setItems() вне rx среды
pm.dataList.observable bindTo { adapter.setData(it) }
KK
Совсем немного кода
RC
В мокси мы, как правило, сначала строим цепочку до презентера, а сам презентационный слой у нас императивный, что вносит в архитектуру неоднородность. Получаются презентеры содержат много логики и интегрируются и интеракторами через Rx. А так мы строим цепочку данных напрямую до вьюхи
в общем эта идея понятна и мне тоже нравится. но хочется услышать конкретные примеры когда это реально выгодно. я слышу что идет экономия например на том, что в презентере мы явно не сабскрайбимся и соответственно не пишем этот код. но ведь обработку ошибок все равно делать..
KK
в общем эта идея понятна и мне тоже нравится. но хочется услышать конкретные примеры когда это реально выгодно. я слышу что идет экономия например на том, что в презентере мы явно не сабскрайбимся и соответственно не пишем этот код. но ведь обработку ошибок все равно делать..
Угу. Выгода, собственно, в смене парадигмы. Если нравится реактив, то это более удобно
RC
мне нравится реактив, безусловно. но проблемы обычно возникают на стыке. а он все равно есть. поэтому и непонятна до конца выгода