Size: a a a

Android Architecture

2020 June 13

КР

Кирилл Романенко... in Android Architecture
Denis Koval
ок. выброшу я разные типы.. в блоке catch в интеракторе они словятся, а дальше что с ними делать?
А что тебе надо сделать? Ещё раз: по клину, интерактор это бизнес логика, которая ничего не знает о представлении. Это чистый домен. По сути, если я правильно тебя понял, ты нарушил клин в 2 пунктах: 1. Интерактор знает о платформе (R из андроида). 2. Интерактор обрабатывает то, как пользователь увидит ошибку.
источник

DK

Denis Koval in Android Architecture
есть презентер, который запускает интерактор и ждет от него результата в виде стринги

интерактор отправляет запрос на сервер и во время отправки запроса - соединение рвется - ловится exception. В блоке catch в интеракторе словился данный тип исколючения. что отвечать презентеру(колбеку)?
источник

DK

Denis Koval in Android Architecture
интерактор про презентер ничего не знает. он на вход принимает только интерфейс
источник

КР

Кирилл Романенко... in Android Architecture
Denis Koval
есть презентер, который запускает интерактор и ждет от него результата в виде стринги

интерактор отправляет запрос на сервер и во время отправки запроса - соединение рвется - ловится exception. В блоке catch в интеракторе словился данный тип исколючения. что отвечать презентеру(колбеку)?
Интерактор не должен знать, что произошло исключение при запросе на сервер. Это ответственность репозитория. Репозиторий скрывает в себе, куда прошёл запрос - в бд, в сеть, в префы. Соответственно, он должен отловить этот экзепшен (а ещё лучше, этот экзепшен должен отловить Network Manager), и отдать какой-то результат интерактору. Интерактор на основе этого результата совершит какую-то бизнес логику и отдаст результат презентеру. Ты можешь сделать это каким угодно способом, я предпочитаю kotlin.Result, если экзепшены, и Either, если типы ошибок находятся в конечном множестве.
источник

DK

Denis Koval in Android Architecture
2 новых слова для меня открыл
источник

DK

Denis Koval in Android Architecture
Кирилл Романенко
Интерактор не должен знать, что произошло исключение при запросе на сервер. Это ответственность репозитория. Репозиторий скрывает в себе, куда прошёл запрос - в бд, в сеть, в префы. Соответственно, он должен отловить этот экзепшен (а ещё лучше, этот экзепшен должен отловить Network Manager), и отдать какой-то результат интерактору. Интерактор на основе этого результата совершит какую-то бизнес логику и отдаст результат презентеру. Ты можешь сделать это каким угодно способом, я предпочитаю kotlin.Result, если экзепшены, и Either, если типы ошибок находятся в конечном множестве.
спасибо за то что разжевал
источник

КР

Кирилл Романенко... in Android Architecture
Не за что. :)
источник

DK

Denis Koval in Android Architecture
источник

КР

Кирилл Романенко... in Android Architecture
Можешь не углубляться в arrow, это достаточно массивная и сложная либа для неподготовленного человека. Просто посмотри примеры с Either , этого будет достаточно. :)
источник

DK

Denis Koval in Android Architecture
ок))
источник

AL

Alexander Lex in Android Architecture
Кирилл Романенко
Смысл интерактора в том, чтобы он был независим от платформы и содержал чистую логику. Даже в presenter/viewmodel/updater не желательно их держать, в идеале об R должен знать только фрагмент/активити.
То есть там и контекста быть не должно? Зря я видимо создаю в интеракторе SharedPrefRepo)) Наверное создавать его нужно в Application, а в интеракторе это будет просто интерфейс типа PersistentRepository... У меня ещё общение с AccountManager в интеракторе происходит, видимо тоже надо как-то абстрагировать
источник

КР

Кирилл Романенко... in Android Architecture
Alexander Lex
То есть там и контекста быть не должно? Зря я видимо создаю в интеракторе SharedPrefRepo)) Наверное создавать его нужно в Application, а в интеракторе это будет просто интерфейс типа PersistentRepository... У меня ещё общение с AccountManager в интеракторе происходит, видимо тоже надо как-то абстрагировать
Именно. :)
источник

AL

Alexander Lex in Android Architecture
Спасибо))
источник

КР

Кирилл Романенко... in Android Architecture
Alexander Lex
Спасибо))
Вкину немножечко фп: можно в самих интеракторах сделать чистые функции, которые будут принимать на вход данные из репозиториев и производить с ними бизнес логику, тогда у тебя будет и клин, и dependency rejection.🙂🙂
источник
2020 June 14

JF

Jorik Fat in Android Architecture
Доброй ночи. Подскажите, пожалуйста, на каком слое следует располагать InternetConnectionListener (реализован через BroadcastReceiver), и ClipboardManager? Я понимаю, что это в любом случае платформенный код, но до конца не уверен это data/ui.
Сейчас они лежат на data-слое, объединенные в deviceRepository.
Мне нужно реагировать в ui на сообщения, приходящие от каждого из них (обрыв соединения/появление данных в буфере)
источник

AD

Aleksey D. in Android Architecture
Кирилл Романенко
Вкину немножечко фп: можно в самих интеракторах сделать чистые функции, которые будут принимать на вход данные из репозиториев и производить с ними бизнес логику, тогда у тебя будет и клин, и dependency rejection.🙂🙂
а в чем профит? 🤔 тестить проще будет?
источник

КР

Кирилл Романенко... in Android Architecture
Aleksey D.
а в чем профит? 🤔 тестить проще будет?
Ну да. Смысл мокать репозиторий и т.д., если можно всю логику вытащить в отдельную функцию, а данные отдать как параметры в функцию? Ну и лямбды появятся, конечно, в большинстве случаев.
источник

КР

Кирилл Романенко... in Android Architecture
Имхо, вся суть фп в том, чтобы было проще тестировать. :D
источник

AD

Aleksey D. in Android Architecture
Кирилл Романенко
Имхо, вся суть фп в том, чтобы было проще тестировать. :D
а как же make impossible state impossible?)
источник

AD

Aleksey D. in Android Architecture
Кирилл Романенко
Ну да. Смысл мокать репозиторий и т.д., если можно всю логику вытащить в отдельную функцию, а данные отдать как параметры в функцию? Ну и лямбды появятся, конечно, в большинстве случаев.
почему там лямбды, если можно  Single<ValueClass> отдать?
источник