Здравствуйте, в принципе не в тему беседки, но вдруг может кто-нибудь подсказать как решить проблему обрезания  экрана клавиатурой?
Кейс: На экране B открываю клавиатуру, возвращаюсь назад, экран А и уже все приложение становится обрезанным. Использую Cicerone если что. Надеюсь, что какие-нибудь профессионаlle подскажут как жить

И вам тоже в @android_ru 🙂

Ну лан, лан, прогнали)

Зачем нужен Repository если можно из Interactor/UseCase сразу дергать api/dao?

в подавляющем большинстве случаев и не нужен 🤷‍♂️

api/dao сами по себе и есть репозитории

(хороший вопрос для наброса)

с точки зрения чистой архитектуры твой iteractor ничего не должен знать об api/dao

Единственное, что мне приходит на ум: нам нужна одна и та же сущность скажем UserEntity с 5 полями, на 2 экранах. Только на одном нужно 4 поля от нее, а на другом 3 поля, и в Interactor делаем маппинг

Тогда логичнее вызов dao перенести в repository и сделать 2 usecase

и то частично можно решить через два запроса в dao, например
через TypeAdapter в GSON и т.д.

Тогда лучше вообще маппиг делать в presenter/vm, что думаете?

Кэширование как будете делать?

Ну а если тебе например надо достать данные из бд, посмотреть их актуальность, в случае чего запросить с сервера новые и заперсистить их? Это выглядит как логика о которой интерактор не должен знать

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

По реализации взаимосвязей в room здесь можно спросить, или не по теме?

лучше в https://t.me/android_aac

О спасибо

ну, зависит от уровня моделей)

а я поймал себя на том, что умный репозиторий (который что-то кеширует по ходу дела) только добавляет неточностей и вольностей

особенно, если в проекте нет каких-то строгих стайлгайдов и каждый дро… пишет как он хочет

потом появляются такие кейсы:
- что, если мне вот тут эти данные нормально из кеша взять, а в случае их отсутствия загрузить
- что, если вот здесь нужны только свежие данные
- вот здесь мне нужно либо кеш, либо ошибку получить

и тут несколько вариантов:
а) простые методы репозитория + логика, которая сама их как нужно скомбинирует
б) по методу на каждый случай в репозиторий
в) несколько разных репозиториев на сущность (самый плохой вариант)
г) передавать флаги в метод, а-ля «isCacheAllowed»

Я для этого использую абстракцию в виде стратегии кеширования.

а кто ее впихивает в репозиторий? (или куда там)