хранить в presentation модуле, так ведь? В data модуле же не правильно хранить такие вещи?
Это слово в данном случаи не особо имеет значение
и тогда в домейн будет зависеть от androidx либы, кажется это совсем не очень
и тогда домейн будет зависеть от androidx либы, кажется это совсем не очень
Если архитектура разбита на модули а data модуль это модуль который провайдит контент к другим модулям, думаю это не столь страшно если Paging реализацию вынести в отдельный модуль
А что в этом плохого?
Не работал с Paging, но если он тянет за собой необходимость делать модуль android-library, то теряется возможность сделать kotlin only domain модуль
Тогда это просто не скомпилируется. А так есть мультиплаформенные AndroidX библиотеки. AndroidX - это ведь просто бренд.
Если Paging мультиплатформенный, тогда не вижу проблем
А мне интересно раскрутить это далее. Зачем вам kotlin-only доменный модуль? 🙂
Ну если мультиплатформенная разработка, например. Или, чтобы было меньше этапов компиляции при сборке модуля
чтобы был максимально переиспользуемый домейн слой, который можно использовать на любой платформе (непонятно зачем, ведь использоваться все равно будет онли на андроид)
Это может быть просто JVM библиотека. Не вижу пока проблем использовать. Особенно если доменный модуль - сам только для андроид используется. Похоже на преждевременные ограничения.
Если это надо, тогда и не получится добавить библиотеку, которая не поддерживает все платформы.
Domain модуль выполняет цепочку вызовов обращений к модулю data, data модуль провайдит к модулям там где API,DAO, итд. В самом модуле domain заложена бизнес логика
Спасибо, я в курсе зачем нужен доменный модуль. Вопрос был зачем он обязательно должен быть kotlin-only.
видимо, чтобы не нарваться на Android-классы, которые можно тестить только с роболектриком
Paging к ним не относится
Я писал выше как можно это избежать)
ну если это android.library (a.k.a. aar), то там легко могут использоваться какие-нибудь SparseArray
Обсуждают сегодня