архитектуру и миграцию.
Кто-нибудь может поделиться опытом миграции на компоуз в реальном проекте?
Ситуация: обычный крупный проект
- десятки активити, 200+ фрагментов, одним шагом это все на компоуз не перепилить.
- Есть дизайн-система, компоуз-реализация готова где-то на 90%
- Гугловской навигации в проекте нет, рассматривает вариант втащить ее или какую-нибудь альтернативу
В целом, проект нормально попилен на фича-модули, есть немного легаси в главном модуле, но не так много.
Высокоуровнево идея следующая:
0. Каждая команда будет мигрировать сама по мере своих возможностей (ну и помогать друг другу тоже по мере возможностей)
1. Мигрировать экраны оставаясь внутри фрагментов (onCreateView -> ComposeView -> setContent, туда же передать viewModel и вперед)
2. Когда в модуле набирается несколько compose-экранов, понемногу выкидывать фрагменты и делать навигацию compose -> compose.
В этом месте как раз можно потестить разные варианты навигации и DI, но много вопросов, как оно будет работать.
- Много ли боли будет со стеком навигации?
- DI нормально будет работать?
- А может лучше все экраны в модуле, потом разом выкинуть фрагменты и перенести все в фиче-активити (А что делать, если у фичи нет своей активити? А что если фрагменты используются другими фичами?)
3. Когда пункт 2 готов, сделать то же самое, но уже на уровень выше — выкидывать активити и интегрировать имеющееся в основной модуль.
Так вот, у кого какой опыт есть? Если не хотите писать тут, буду рад обсудить в личке.
Ну проект у нас не такой большой, но ситуация похожая. Первый и второй пункт правильные. Насчёт навигации я вопрос двоякий, кто то вообще избавляется от вьюмоделей, тогда навигация напрямую внутри компоуз через гугловскиц навигатор. Он конечно имеет свои изъяны в виде использования бандл и строк для навигации , но справляется со своей задачей , плюс диплинки из коробки. Если же оставить вьюмодели , то я думаю не избежать кейсов когда нужно навигироваться из вьюмодели, тут понадобится мост между двумя навигаторами, мы сделали так и пока работает, но мы не выходили за пределы переписывания одного основного фрагмента в котором вьюшки сменяли друг друга и это основная часть приложения. У коллеги есть опасения, скоро можно столкнёмся когда заходим с одного графа переключаться на другой. Сам пока ещё не осознал проблему, не думал. DI коин использовали, кодеин тоже подтянул поддержку компоуз. С шарингом проблем нет, немного повозиться пришлось с шарингом внутри одной активности двум фрагментам одного экземпляра и одной вложенной компоуз функции, но и это получилось благодаря помощи с чата. Насчёт последнего вопроса не знаю
Спасибо! Да, у меня гуглонавигация есть в пет-проекте, так что я более-менее в курсе как оно работает + сразу поддержка даггера есть. Кстати, Jim Sproch, топит за выпиливание VM.
Да, за выпил vm потом вникну, далеко еще мне. А Даггер долго настраивать и поддерживать, как кодеин использовал , забыл про него.
Обсуждают сегодня