Комментарии 8
А что с передачей parcelable аргументов?
Тут я бы уточнил: "а действительно ли есть необходимость проталкивать объект или можно обойтись более легковесным вариантом"?
На самом деле, под большинство задач (если не под все) достаточно бросить пару id's, несколько примитивов, а остальное дополучить в условной ViewModel на уровне бизнес логики фичи через кейсы/репозитории/кеш/т.д..
P.S.: Но если есть необходимость передавать объекты, то можно протащить их преобразовав в строку Json (КРАЙНЕ не рекомендую так делать) и положив ее по аналогии с примитивами в route в качестве параметра.
Ну эти костыли уже попробовал)))
На самом деле когда работаешь с кривыми апи, то проще передать объект через экран, а не делать еще один запрос. Вот у нас сейчас запрос один отрабатывает 3-5 секунд, на беке это пофиксить не могут, а мне приходится его делать на одном экране, потом переходить на другой экран и еще раз это делать. Кешировать особо смысла нету, потому что при каждом входе данные меняются. Та и БД в проект не завозили, то из-за одного объекта это делать нету смысла. Получается надо хранить данные где-то в репозитории и получать их с разных экранов, что кажется еще одним костылем. Странно получить id через аргументы в навигации, а остаток полей получить из вьюмодели. В общем крайне удивлен я решением гугла сделать такое в навигации. После многих лет использования Cicerone навигация гугла выглядит очень костыльной.
Кэширование данных в репо - как раз таки, не является костылем по причине того, что одна из ключевых задач репозитория - работа с данными, в том числе с их переиспользованием. Это вполне себе реальная практика. При этом если данные меняются после ухода с цепочки экранов, то ничто не мешает реализовать кэширование в скоупе (например, сброс кэша при очередном попадании на экран А в цепочке А->Б), что тоже является корректным поведением.
Но на самом деле, я бы смотрел по конкретной задаче. Очень может быть, что в вашем случае тащить кэширование действительно будет избыточным и проще передать объект. В таком случае возникает вопрос, а зачем было затаскивать навигацию, которая заведомо не может в объекты? Если ответ - исторически так сложилось, то можно воспользоваться временной панацеей в виде упаковки в JSON строку и распаковку на принимающей стороне через маппер - тут, повторюсь, нужно взвешивать все плюсы и минусы конкретного случая и размера передаваемого объекта.
Что касается решения Гугла, то тут сложно сказать почему они так сделали. Решение действительно еще довольно сырое и в перспективе, скорее всего сильно изменится. Но важно также понимать, что и существующие решения по типу Cicerone тоже когда-то были сырыми =) Compose Navigation, лишь проба пера для нового подхода Compose. Все с чего-то начинается, а дальше посмотрим к чему придут.
https://github.com/olshevski/compose-navigation-reimagined
Просто и минималистично, работает с любыми типами которые можно всунуть в Bundle.
А как с диплинками объстоят дела? Как из пуша попасть на детализацию токена?)
Делаю навигацию в приложении на Compose