Size: a a a

Android Architecture

2017 January 25

B

Beka in Android Architecture
Alexander Popsuenko
Соглашусь.
А как тогда мне решить проблему, если у меня есть данные, которые грузятся быстро и я их показываю и есть данные, которые грузятся минуту.
Вторые могут блокировать первые.
Учитывая, что мне каждые n секунд нужно обновить первые данные.
То есть у тебя 2 сорца.
1. ЛОкальный
2. Клауд.
источник

B

Beka in Android Architecture
Так?
источник

B

Beka in Android Architecture
Используя RX все это облегчается.
источник

AP

Alexander Popsuenko in Android Architecture
Нет.
Есть список комнат.
Есть список юзеров.
А можем еще в комнате находиться и грузить сообщения, не блокируя при этом список комнат.
источник

AG

Artem Gilmudinov in Android Architecture
Eugene Matsyuk
Да по идее наоборот
Как раз Презентер и указывает, на каком потоке выполнять, и на каком выдавать
Интерактор предоставляет лишь юз-кейсы. Все.
Но могут быть ситуации, когда в Интеркторе приходится задавать потоки. Но стоит это сводить к минимуму
Но тогда мы в презентере раскроем детали реализации бизнес логики.
источник

B

Beka in Android Architecture
Если нету ЭрИкса то реализуй свои колбеки которые кидаются как у ЭрИкса.
источник

AP

Alexander Popsuenko in Android Architecture
Использую Rx и радуюсь.
источник

AG

Artem Gilmudinov in Android Architecture
Типо если передаем io() то значит бд, если передаем computation() то почти наверняка какой-нибудь ram сторэдж
источник

AP

Alexander Popsuenko in Android Architecture
Beka
Если нету ЭрИкса то реализуй свои колбеки которые кидаются как у ЭрИкса.
Вопрос то был в том, где определяется поток.
+ Вы сказали, что многопоточность для логики - не гуд.
Видимо мы не так друг друга поняли. Вы подумали, что я для одной логики применяю разные потоки - нет конечно)
источник

EM

Eugene Matsyuk in Android Architecture
Artem Gilmudinov
Но тогда мы в презентере раскроем детали реализации бизнес логики.
да как там раскрываем то детали реализации?
мы просто указываем потоки, на которых выполняется.
но с презентеров то дергаем интерфейс интерактора, а о реализации мы ничего не знаем
источник

AG

Artem Gilmudinov in Android Architecture
тогда следующий вопрос. если мы не знаем какая реализация, то какой шедулер выбрать?
источник

EM

Eugene Matsyuk in Android Architecture
можно в комментах отобразить, что делает данный метод - вычисляет или ходит в сеть, например
из этого и исходим
источник

AG

Artem Gilmudinov in Android Architecture
мне кажется, что таким образом логика переносится в презентер.
источник

AG

Artem Gilmudinov in Android Architecture
источник

AG

Artem Gilmudinov in Android Architecture
тут тоже вроде явная передача
источник

EM

Eugene Matsyuk in Android Architecture
что понимать под логикой?
бизнес-логика остается в интеркторе
в презентере будет ui логика и управление многопоточностью
источник

AG

Artem Gilmudinov in Android Architecture
принятие решения на каком потоке выполнять методы интерактора.
источник

YS

Yuri Shmakov in Android Architecture
А может это тоже зависвит от того, зачем нужно делать задачу многопоточно? если это нужно для красивого UI — то в презентере. А если тербуется для бизнес-задачи(нужно запараллелить, и дождаться пока все отработают), то не в презентере. Мож так?)
источник

YS

Yuri Shmakov in Android Architecture
Причём презентер может сделать запрос в интерактор на одном шедулере, а интерактор может в себе оперировать другими шедулерами =)
источник

AG

Artem Gilmudinov in Android Architecture
тогда может появится оверхед с лишними subscribeOn
источник