Телеграмм чат группы Android_Architecture страница 90

12:52пожаловаться #1

Eugene Matsyuk in Android Architecture

@Andre1024 все зависит от сроков, ибо изучение Rx дело далеко не быстрое
как вариант, он вам пригодится, когда вам нужно объединять данные, полученные от разных источников

12:54пожаловаться #2

Andre in Android Architecture

Eugene Matsyuk

ты, наверное, про вездесущие Subjects ?)

да про эти сущности) Да работал однажды с таким кейсом где данные обьеденяем с помощью Rx, мне понравилось как удобно это он делает.

12:57пожаловаться #3

Eugene Matsyuk

ты, наверное, про вездесущие Subjects ?)

скорее про то что обсерверы начинают пихать везде. любой отклик от пользователя заварачивается в обсервер

12:57пожаловаться #4

сабджект это хак для тех кто не хочет делать все на потоках. Это отхождение от парадигмы, но имеет место быть

RxJava types that are both an Observable and a Consumer. - JakeWharton/RxRelay

13:00пожаловаться #5

Anatolii K in Android Architecture

вместо сабжектов рекомендую использовать RxRelay, тут Джейк аргументирует почему https://github.com/JakeWharton/RxRelay

GitHub

JakeWharton/RxRelay

13:12пожаловаться #6

Eugene Matsyuk

юзали? как инструмент по ощущениям?

К сожалению нет, но наслышан

14:24пожаловаться #7

Alexander Blinov

главное не схватить Rx головного мозга, где все в потоках

А чем плохо все в потоках?

14:26пожаловаться #8

код становится непонятным и нечитаемым. у любой технологии должны быть границы

14:28пожаловаться #9

Да и без потоков можно так же сделать. Есть пример?

14:35пожаловаться #10

Stepan Goncharov

Да и без потоков можно так же сделать. Есть пример?

не хочу холиварить, это мое мнение. если у вас есть пример читаемого кода полностью на потоках с удовольствием на него гляну

14:39пожаловаться #11

TestableCodeMobius - Demo project for Testable code in Mobius conference

посмотрел код Жени с потоками событий из view и обратно:

https://github.com/matzuk/TestableCodeMobius/blob/master/app/src/main/java/com/matsyuk/testablecodemobius/business/transfer/TransferInteractor.java

выглядит норм

GitHub

matzuk/TestableCodeMobius

14:44пожаловаться #12

под рукой только такой пример есть
https://gist.github.com/stepango/992df45505d4ebb5cab55ed1c74bee25

Gist

RegistrationViewModel.kt

14:57пожаловаться #13

Михаил in Android Architecture

вопрос по мвп. должна ли вью все ивенты в ui решать через презентер? будь то показ диалога подтверждения и подобного, что в принципе будет выглядет, как: кнопка удаления нажата -> вью дергает у презентера метод showDialog -> презентер говорит вьюшке покажи диалог

16:13пожаловаться #14

Михаил in Android Architecture

имеет ли смысл таким оверинженерингом заниматься?

16:14пожаловаться #15

Artur in Android Architecture

Скорее, вьюха должна вызывать mPresenter.onDeleteViewClick()

16:14пожаловаться #16

Artur in Android Architecture

Мало ли что ты туда ещё прикрутить захочешь.
Идея та же - два перехода, просто название метода чётче охарактеризовывает тип отношений.
+ ты потом можешь убедиться, что презентер дёрнул этот метод с помощью jUnit + Mockito

16:14пожаловаться #17

Yuri Shmakov in Android Architecture

почему нужно прогонять через презентер? дело в том, что если не прогнать через презентер, то если активити пересоздастся, тот же самый AlertDialog пропадёт и не будет показан пользователю. Поэтому нужно прогнать, имхо

16:17пожаловаться #18

Yuri Shmakov in Android Architecture

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

16:17пожаловаться #19

Sergey D in Android Architecture

скажите а если идет запуск активити или смена фрагмента по нажатию на что нить это тоже через презентер лучше прогонять?