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

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

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

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

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

2 новых слова для меня открыл

спасибо за то что разжевал

Не за что. :)

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

ок))

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

Именно. :)

Спасибо))

Вкину немножечко фп: можно в самих интеракторах сделать чистые функции, которые будут принимать на вход данные из репозиториев и производить с ними бизнес логику, тогда у тебя будет и клин, и dependency rejection.🙂🙂

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

а в чем профит? 🤔 тестить проще будет?

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

Имхо, вся суть фп в том, чтобы было проще тестировать. :D

а как же make impossible state impossible?)

почему там лямбды, если можно  Single<ValueClass> отдать?