AB
на мобиусе 2017 буду тоже рассказывать про архитектуру. Расскажу как это решается в Redmadrobot
Size: a a a
2017 January 25
S
будем ждать )
EM
@xanderblinov кстати напиши, про что будешь рассказывать =)
AB
@xanderblinov кстати напиши, про что будешь рассказывать =)
у меня будет доклад по мотивам последнего Google I/O. Android application architecture: Get ready for the next billion!
я повторю про теорию и как это делается на практике
я повторю про теорию и как это делается на практике
AG
Логично ли то, что в презентере не должно быть работы с шедулерами?
AG
А только лишь в интеракторе
EM
Да по идее наоборот
Как раз Презентер и указывает, на каком потоке выполнять, и на каком выдавать
Интерактор предоставляет лишь юз-кейсы. Все.
Но могут быть ситуации, когда в Интеркторе приходится задавать потоки. Но стоит это сводить к минимуму
Как раз Презентер и указывает, на каком потоке выполнять, и на каком выдавать
Интерактор предоставляет лишь юз-кейсы. Все.
Но могут быть ситуации, когда в Интеркторе приходится задавать потоки. Но стоит это сводить к минимуму
B
Да по идее наоборот
Как раз Презентер и указывает, на каком потоке выполнять, и на каком выдавать
Интерактор предоставляет лишь юз-кейсы. Все.
Но могут быть ситуации, когда в Интеркторе приходится задавать потоки. Но стоит это сводить к минимуму
Как раз Презентер и указывает, на каком потоке выполнять, и на каком выдавать
Интерактор предоставляет лишь юз-кейсы. Все.
Но могут быть ситуации, когда в Интеркторе приходится задавать потоки. Но стоит это сводить к минимуму
Согласен. Юз кейс не определяет на каком потоке выполнять И так далее. Оно определяет "Как решить определенную задачу".
B
а манипулировать потоками лучше в презентере. Это common case. могут быть и корнер кейсы.
KM
Что об этом решении думаете? https://github.com/android10/Android-CleanArchitecture/blob/aaa21c1b7cb4dc7b80a4da7f0552036bcb7ff40e/domain/src/main/java/com/fernandocejas/android10/sample/domain/interactor/GetUserDetails.java Тут поток определяется в интеракторах.
AP
Наверное, все таки от задачи зависит.
У меня вот каждый интерактор в своем потоке выполняется, так что они сами решают, где, а не презентеры.
У меня вот каждый интерактор в своем потоке выполняется, так что они сами решают, где, а не презентеры.
EM
Фернандо как раз будет на мобиусе =)
Но я его сегодня спрошу, почему он так делает.
Но я его сегодня спрошу, почему он так делает.
B
Наверное, все таки от задачи зависит.
У меня вот каждый интерактор в своем потоке выполняется, так что они сами решают, где, а не презентеры.
У меня вот каждый интерактор в своем потоке выполняется, так что они сами решают, где, а не презентеры.
Все так смотри.
B
Юз кейс это и есть основа твоего проекта.
B
Если я получаю проект после тебс сразу подумаю. Хм это юз кейс и вызываю 2-3 юз кейса одновременно. Думая что они делают что то.
B
А на самом они начинают конкурироватся. Это плохо.
B
Юз кейс и канканренси это разные слои в архитектуре по идею.
B
Ты уже делаешь свой код трудно поддерживаемым.
B
И после тебя трудно поддерживать. Так как не ясно как они будут работать в многопоточном мире.
AP
Соглашусь.
А как тогда мне решить проблему, если у меня есть данные, которые грузятся быстро и я их показываю и есть данные, которые грузятся минуту.
Вторые могут блокировать первые.
Учитывая, что мне каждые n секунд нужно обновить первые данные.
А как тогда мне решить проблему, если у меня есть данные, которые грузятся быстро и я их показываю и есть данные, которые грузятся минуту.
Вторые могут блокировать первые.
Учитывая, что мне каждые n секунд нужно обновить первые данные.