А
Тоже по причине Dagger-а разбил проект на модули ещё в году 2018. Потом просто заменил на Toothpick и многомодульность стала не нужна
Size: a a a
2020 October 04
ЕК
> Потом просто заменил на Toothpick
А
Все остальные проекты делал в одном модуле
A
> Потом просто заменил на Toothpick
Переход сложный?
АЕ
Стоит заменить на Toothpick. Начнёт собираться намного быстрее
Он, конечно, быстрее, но тоже с каптом. Возможно начинает тормозить при большем размере проекта, но таки начинает
ЕК
Переход сложный?
Про миграцию не скажу. Я научился в даггер просто чтобы знать его, но не стал использовать в своих проектах, only Toothpick. Уже не один десяток приложений на нём. Сейчас разрабатываем довольно крупное и быстро растущее приложение, крайне много всего. С нуля проект компилится 3-4 минуты. За всё время потеряли только одну зависимость, прошло мимо QA, катнули хотфикс тем же вечером. Для меня выбор между возможными рисками и удобством разработки очевиден.
ЕК
Приведу пару примером, как мы работаем с Toothpick
ЕК
локальные модули для фрагментов
ЕК
inject в поле + extension для инжекта презентера, написан поверх стандартного moxyPresenter
ЕК
Иерархия скоупов привязана к иерархии фрагментов (понравился подход GitFox), автоматически создаются и очищаются.
АЕ
Иерархия скоупов привязана к иерархии фрагментов (понравился подход GitFox), автоматически создаются и очищаются.
Закрываете там же где мокси презентер дестроится?
А
Тоже так делаю)
ЕК
Закрываете там же где мокси презентер дестроится?
Да, там похожая проверка на то, что фрагмент именно закрывается. В принципе, почти вся основа из GitFox перекочевала. Довольно гибко, покрывает большинство кейсов, остальное допиливается под нужды.
AI
Вопрос, связанный подходом, когда есть feature-модули с внутренним разбиением на слои (data, domain, presentation): вроде бы ок, но напрягает один недостаток - как шарить юзкейсы и модели между фичами? Выносить их в отдельный модуль? И как-то не очень, имхо, что юзкейсы из разных фич разместятся в каком-нибудь shared-domain модуле. Как вы у себя решаете это?
У нас один модуль на фичу. А если надо что-то пошарить, то это "что-то" надо выносить в отдельный модуль в виде отдельной фичи.
AA
У нас один модуль на фичу. А если надо что-то пошарить, то это "что-то" надо выносить в отдельный модуль в виде отдельной фичи.
Ок, допустим, есть 2 фичи "продукт" и "корзина" со своими юзкейсами (т.е. с логикой). В первой фиче нужна возможность добавления в корзину (т.е. нужен юзкейс корзины): выносить юзкейс корзины в отдельный модуль-фичу и шарить между фичами продукта и корзины? И тем самым получаем уже 3 фичи, в котором корзина разбивается на 2 фичи
AI
Ок, допустим, есть 2 фичи "продукт" и "корзина" со своими юзкейсами (т.е. с логикой). В первой фиче нужна возможность добавления в корзину (т.е. нужен юзкейс корзины): выносить юзкейс корзины в отдельный модуль-фичу и шарить между фичами продукта и корзины? И тем самым получаем уже 3 фичи, в котором корзина разбивается на 2 фичи
Фича "продукт" должна принимать коллбек "onAddToBasket" и в точке интеграции надо вызвать фичу "корзина". Стандартный IoC.
V
А можно немного разжевать последнее сообщение?
Корзина имплиментит onaddtobasket, а продукт его просто вызывает?
Корзина имплиментит onaddtobasket, а продукт его просто вызывает?
DS
А можно немного разжевать последнее сообщение?
Корзина имплиментит onaddtobasket, а продукт его просто вызывает?
Корзина имплиментит onaddtobasket, а продукт его просто вызывает?
Корзина не обязана имплементить. Например АппМодуль может передать в ПродуктФичу скромную реализацию этого интерфейса, который в свою очередь дернет КорзинаФичу за нужный метод