Я сейчас задам наверное глупый вопрос, сорян, в нативе недавно,

почему все композовские библиотеки навигации предполагают аргументы в виде строк или того, что можно перевести в строку? Ну, что нам мешает допустим сначала создать ViewModel для очередного экрана со всеми параметрами любых форматов, а потом просто передать его как полностью готовый аргумент при навигации? Ну или на крайний случай, в момент перехода к очередной странице засунуть аргументы для неё в какой-нибудь статический объект, а на самой странице сразу его считать после перехода?

Compose destinations позволяет работать с parcerable

вы описали Decompose

Через репозиторий можно что угодно передавать Репозиторий в памяти. Тоже самое будет Но вот вопрос зачем передавать объекты?

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

> почему именно есть такое странное ограничение В официальной navigation-compose это было сделано, чтобы уменьшить размер сохраняемых аргументов (чтобы они укладывались в лимит), и чтобы побудить разработчиков использовать персистентные источники данных. Возможно, так ещё было просто и быстрее, когда Композ уже был, а официальной навигации ещё не было. Но это вызвало много отрицательной обратной связи, и в Google её слышат. > не совсем понятна взаимосвязь между смертью процесса и передачей аргументов в другой экран Кода система обивает фоновое приложение из-за нехватки памяти другим приложениям, то потом когда то приложение снова открывается, navigation-compose (и любая другая библиотека навигации) восстанавливает старое состояние навигации. Для этого нужно сохранять все аргументы всех экранов в Bundle. Это рекомендованный UX. > если я не хочу допустим восстанавливать стек навигации Не уверен что это можно сделать со стандартной навигацией, но могу ошибаться. Можно попробовать вручную осуществлять навигацию на нужный экран со сбросом стека. Некоторые библиотеки позволяют выключать сохранение навигации, например Decompose.

Чтобы не делать эти репозитории...