Можете объяснить в двух словах почему всем так не нравится

гугловая навигация? Сам на композе приложения ещё не делал, изучаю стек

Композовскую навигацию большинство просто не умеют готовить и ругаются на неё. Мне она как ни странно, понравилась, после того как добавил немного своих абстракций. Из минусов композовской навигации от гугл: - Нельзя передавать тяжёлые объекты между экранами Остальные минусы либо решаемы, либо и вовсе ими не являются: - Плохо подходит для многомодульности (не все умеют его готовить, на самом деле отлично ложится на многомодульность) - Очищается UI прошлого экрана при навигации. Мне кажется, что с этим нужно просто научиться работать, так как в Compose любая навигационная библиотека будет очищать прошлый экран - Навигация происходит только из UI слоя (эта проблема решаема абстракциями)

По поводу передачи объектов, я же правильно понимаю что там лимиты такие же как и у xml? Типа не передавай объекты превышающие лимит бандла и все будет хорошо, а для всего остального есть вьюмодель

Не совсем. Чтобы передать объект в Compose его сначала нужно сериализовать в строку. При этом лимиты на размер передаваемых данных сохраняются. С учетом того, что эта строка скорее верно будет в формате json, и экран в приложении скорее всего не один. Размер объектов, которые можно передавать в гугловской навигации крайне маленький

При каких сценариях очищается?

При переходе на следующий экран Composable функция предыдущего экрана всегда очищается из дерева (не видна на экране и вызывается onDispose)

Ну это если из стека выкидывать

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

В Decompose можно сделать так, чтобы предыдущий экран не очищался

вертикальные навхосты, горизонтальные навхосты NavController NavType BackStackEntry NavigationUI…(…) хочешь анимации - бери аккомпанист еще впридачу