фич во многомодульном проекте, разделение на модули по фичам согласно подходу из статьи: habr.com/ru/company/kaspersky/blog/520766/ (для каждой фичи есть модули api и impl)
Раскрою свой вопрос на примере абстрактного приложения для просмотра статей. Существуют следующие фичи: поиск статей, избранные статьи, просмотр конкретной статьи. Поиск и "Избранное" используют фичу просмотра, когда пользователь выбирает статью.
Какое api должно предоставлять фича просмотра статей и где должна происходить навигация на экран просмотра?
Навскидку я вижу два варианта:
1. Метод api принимает Router/FragmentManager, навигация выполняется в имплементации фичи просмотра
2. Метод api возвращает Screen или Fragment, навигация выполняется внутри фичи, инициирующей просмотр статьи
Какой вариант предпочтительнее? Есть ли ещё варианты?
Навскидку второй вариант выглядит логичнее, но подозреваю, что у него есть менее очевидные подводные камни)
у нас фичи-экраны в api возвращают свой фрагмент, и при необходимости что-нибудь ещё, что нужно вызвать или наоборот послушать снаружи.
Прям как у чуваков из hh
потому что я тоже чувак из hh 🙂
Понял, спасибо) То есть в целом такой подход устроил и причин его перепилить пока встретили?
Да, вполне. Вот когда начнём на 100% композе писать, что-то придется менять)
я выношу всю навигацию в отдельный модуль и при переходах испольюзую sealed'ы
у меня эти реализации в коммерческих проектах
Обсуждают сегодня