Как стать автором
Обновить

Комментарии 8

А что с передачей parcelable аргументов?

Тут я бы уточнил: "а действительно ли есть необходимость проталкивать объект или можно обойтись более легковесным вариантом"?

На самом деле, под большинство задач (если не под все) достаточно бросить пару id's, несколько примитивов, а остальное дополучить в условной ViewModel на уровне бизнес логики фичи через кейсы/репозитории/кеш/т.д..

P.S.: Но если есть необходимость передавать объекты, то можно протащить их преобразовав в строку Json (КРАЙНЕ не рекомендую так делать) и положив ее по аналогии с примитивами в route в качестве параметра.

Ну эти костыли уже попробовал)))

На самом деле когда работаешь с кривыми апи, то проще передать объект через экран, а не делать еще один запрос. Вот у нас сейчас запрос один отрабатывает 3-5 секунд, на беке это пофиксить не могут, а мне приходится его делать на одном экране, потом переходить на другой экран и еще раз это делать. Кешировать особо смысла нету, потому что при каждом входе данные меняются. Та и БД в проект не завозили, то из-за одного объекта это делать нету смысла. Получается надо хранить данные где-то в репозитории и получать их с разных экранов, что кажется еще одним костылем. Странно получить id через аргументы в навигации, а остаток полей получить из вьюмодели. В общем крайне удивлен я решением гугла сделать такое в навигации. После многих лет использования Cicerone навигация гугла выглядит очень костыльной.

Кэширование данных в репо - как раз таки, не является костылем по причине того, что одна из ключевых задач репозитория - работа с данными, в том числе с их переиспользованием. Это вполне себе реальная практика. При этом если данные меняются после ухода с цепочки экранов, то ничто не мешает реализовать кэширование в скоупе (например, сброс кэша при очередном попадании на экран А в цепочке А->Б), что тоже является корректным поведением.

Но на самом деле, я бы смотрел по конкретной задаче. Очень может быть, что в вашем случае тащить кэширование действительно будет избыточным и проще передать объект. В таком случае возникает вопрос, а зачем было затаскивать навигацию, которая заведомо не может в объекты? Если ответ - исторически так сложилось, то можно воспользоваться временной панацеей в виде упаковки в JSON строку и распаковку на принимающей стороне через маппер - тут, повторюсь, нужно взвешивать все плюсы и минусы конкретного случая и размера передаваемого объекта.

Что касается решения Гугла, то тут сложно сказать почему они так сделали. Решение действительно еще довольно сырое и в перспективе, скорее всего сильно изменится. Но важно также понимать, что и существующие решения по типу Cicerone тоже когда-то были сырыми =) Compose Navigation, лишь проба пера для нового подхода Compose. Все с чего-то начинается, а дальше посмотрим к чему придут.

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

А как с диплинками объстоят дела? Как из пуша попасть на детализацию токена?)

На текущий момент никак, т.к. флоу не подразумевает инициализацию по диплинке) Но в перспективе, планирую завязаться на стандартный механизм работы с диплинками в Compose Navigation. Как реализую, обязательно добавлю в статью описание.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории