На текущий момент никак, т.к. флоу не подразумевает инициализацию по диплинке) Но в перспективе, планирую завязаться на стандартный механизм работы с диплинками в Compose Navigation. Как реализую, обязательно добавлю в статью описание.
Отличное решение для того, чтобы на уровне Compose Navigation работать с объектами. Если для проекта не критично затаскивать библиотеку, то вариант подходящий (главное держать в уме, что любая библиотека - это всегда потенциальные риски и нужно исходить из всех плюсов минусов в конкретном случае).
Кэширование данных в репо - как раз таки, не является костылем по причине того, что одна из ключевых задач репозитория - работа с данными, в том числе с их переиспользованием. Это вполне себе реальная практика. При этом если данные меняются после ухода с цепочки экранов, то ничто не мешает реализовать кэширование в скоупе (например, сброс кэша при очередном попадании на экран А в цепочке А->Б), что тоже является корректным поведением.
Но на самом деле, я бы смотрел по конкретной задаче. Очень может быть, что в вашем случае тащить кэширование действительно будет избыточным и проще передать объект. В таком случае возникает вопрос, а зачем было затаскивать навигацию, которая заведомо не может в объекты? Если ответ - исторически так сложилось, то можно воспользоваться временной панацеей в виде упаковки в JSON строку и распаковку на принимающей стороне через маппер - тут, повторюсь, нужно взвешивать все плюсы и минусы конкретного случая и размера передаваемого объекта.
Что касается решения Гугла, то тут сложно сказать почему они так сделали. Решение действительно еще довольно сырое и в перспективе, скорее всего сильно изменится. Но важно также понимать, что и существующие решения по типу Cicerone тоже когда-то были сырыми =) Compose Navigation, лишь проба пера для нового подхода Compose. Все с чего-то начинается, а дальше посмотрим к чему придут.
Тут я бы уточнил: "а действительно ли есть необходимость проталкивать объект или можно обойтись более легковесным вариантом"?
На самом деле, под большинство задач (если не под все) достаточно бросить пару id's, несколько примитивов, а остальное дополучить в условной ViewModel на уровне бизнес логики фичи через кейсы/репозитории/кеш/т.д..
P.S.: Но если есть необходимость передавать объекты, то можно протащить их преобразовав в строку Json (КРАЙНЕ не рекомендую так делать) и положив ее по аналогии с примитивами в route в качестве параметра.
Задача данной статьи была скорее обзорной, в дальнейшем планирую выпустить серию статей относительно отдельных направлений применения, в том числе, будет статья про то, как Clean (и разделение на слои) дружится с Compose.
Про accomponist вы верно заметили, позволяет избавиться от реализации большинства велосипедов.
Про навигацию вас услышал, обязательно на данную тему подготовлю статью. В планах рассказать как я подружил Compose Navigation и собственную реализацию роутера для межмодульного взаимодействия.
Если речь идет про перерисовку на превьюшке в студии, то там есть еще некоторые проблемы с тулзами для разработки, но это дело поправляемое. Например, если дебажить на физическом устройстве, то все довольно шустро отрабатывает (тут просто нужно капать в причину, почему вы столкнулись с такой проблемой).
Если речь про перформанс в сборке, то тут, на самом деле, многое зависит от того, как использовать рекомпозицию. В Compose есть свои особенности связанные с условиями при которых происходит перерисовка. И если пользоваться этим инструментом неправильно, то вместо, скажем, рекомпозиции отдельной кнопки, будет происходить перестроение всей иерархии. Тогда да, тогда перформанс просядет ощутимо (особенно заметно будет на списках или вложенных компонентах интерфейса).
Но тут на самом деле даже причина не в инструменте, а в том как его используешь. Просадить перфоманс можно и наверстав LinearLayout'ов вложенных, условно)
Хранение на устройстве - не самая идеальная история, согласен, но она определенно проще контролируется с точки зрения безопасности, нежели хранение личных данных на стороннем сервере. Если мы гоняем данные, пусть и по защищенному каналу в облако, то проблема здесь в том, что данные хранятся в облаке и агрегрируются данные там не только мои, но и миллионов других пользователей. С точки зрения банального экономического "интереса взломщика" такой узел, на котором много данных (которые потом отлично продаются), становится куда более интересным для атаки, нежели мой личный телефон.
Да и безопасность телефона определенно будет выше, со стороны внешнего взлома при условии: приложения с непроверенных источников не ставить, по не нужным сайтам не ходить, файлы непонятные не качать и т.д. и т.п.. Шифрование в моем случае, это своего рода второй фактор безопасности к первому естественному (этим устройством пользуюсь только я и пользуюсь с соблюдением банальных правиль личной безопасности).
На самом деле, из абсолютно надежных средств хранения можно выделить, разве что: "блокнот и ручка в сейфе". Здесь даже личная голова будет далеко не идеальным средством, т.к. она имеет свойство "забывать".
Я не пытаюсь сказать, в однозначном порядке, что мол "нет, не пользуйтесь облачниками, это ужасно и плохо". Нет, они хороши по своему. Просто, когда ты параноишь, но при этом бесишься от того, что постоянно нужно вводить ручками пароль с бумаги или пользоваться существующими решениями с интерфейсом времен 2000х, то со временем появляется устойчивое желание найти что-то удовлетворяющее всем твоим требованиям. А когда не находишь, то берешь и делаешь что-то подобное сам =)
P.S.: В моем случае главным мотиватором, чтобы отказаться от внешнего хранилища было как раз таки то, что мои данные с этого облачного менеджера слизали.
Дело в том, что когда я выбирал тему приложения, то я руководствовался несколькими параметрами:
Жизненная ситуация: мои пасы были слиты одной компанией N (я пользовался их сервисом безопасного облачного хранения - имен называть не буду по известным причинам)
Хотел максимально маленькое приложение (в минимальном приближении, но не бесполезное с точки зрения функционала), чтобы сильно не зарываться на первых парах (т.к. все таки "обкатываю" Compose)
Я люблю интуитивные, понятные, эстетически приятные интерфейсы (коим KeePassXC в моем представлении не удовлетворяет - опять же это только мое субъективное восприятие)
А еще я в перспективе, хочу добавить возможность напрямую подрубать, условно, флешку в девайс. чтобы хранилищем выступало не устройство, а внешний носитель. Тогда безопасность будет уровня "тетрадка в сейфе", т.к. приложение будет выступать лишь удобным интерфейсом взаимодействия с хранилищем. Как-то так. Надеюсь ответил на ваши вопросы о причинах выбора данной темы приложения)
Information
Rating
Does not participate
Registered
Activity
Specialization
Mobile Application Developer, Chief Executive Officer (CEO)
На текущий момент никак, т.к. флоу не подразумевает инициализацию по диплинке) Но в перспективе, планирую завязаться на стандартный механизм работы с диплинками в Compose Navigation. Как реализую, обязательно добавлю в статью описание.
Отличное решение для того, чтобы на уровне Compose Navigation работать с объектами. Если для проекта не критично затаскивать библиотеку, то вариант подходящий (главное держать в уме, что любая библиотека - это всегда потенциальные риски и нужно исходить из всех плюсов минусов в конкретном случае).
Кэширование данных в репо - как раз таки, не является костылем по причине того, что одна из ключевых задач репозитория - работа с данными, в том числе с их переиспользованием. Это вполне себе реальная практика. При этом если данные меняются после ухода с цепочки экранов, то ничто не мешает реализовать кэширование в скоупе (например, сброс кэша при очередном попадании на экран А в цепочке А->Б), что тоже является корректным поведением.
Но на самом деле, я бы смотрел по конкретной задаче. Очень может быть, что в вашем случае тащить кэширование действительно будет избыточным и проще передать объект. В таком случае возникает вопрос, а зачем было затаскивать навигацию, которая заведомо не может в объекты? Если ответ - исторически так сложилось, то можно воспользоваться временной панацеей в виде упаковки в JSON строку и распаковку на принимающей стороне через маппер - тут, повторюсь, нужно взвешивать все плюсы и минусы конкретного случая и размера передаваемого объекта.
Что касается решения Гугла, то тут сложно сказать почему они так сделали. Решение действительно еще довольно сырое и в перспективе, скорее всего сильно изменится. Но важно также понимать, что и существующие решения по типу Cicerone тоже когда-то были сырыми =) Compose Navigation, лишь проба пера для нового подхода Compose. Все с чего-то начинается, а дальше посмотрим к чему придут.
Тут я бы уточнил: "а действительно ли есть необходимость проталкивать объект или можно обойтись более легковесным вариантом"?
На самом деле, под большинство задач (если не под все) достаточно бросить пару id's, несколько примитивов, а остальное дополучить в условной ViewModel на уровне бизнес логики фичи через кейсы/репозитории/кеш/т.д..
P.S.: Но если есть необходимость передавать объекты, то можно протащить их преобразовав в строку Json (КРАЙНЕ не рекомендую так делать) и положив ее по аналогии с примитивами в route в качестве параметра.
Обязательно освечу оба момента. Спасибо за ваш комментарий)
Задача данной статьи была скорее обзорной, в дальнейшем планирую выпустить серию статей относительно отдельных направлений применения, в том числе, будет статья про то, как Clean (и разделение на слои) дружится с Compose.
Про accomponist вы верно заметили, позволяет избавиться от реализации большинства велосипедов.
Про навигацию вас услышал, обязательно на данную тему подготовлю статью. В планах рассказать как я подружил Compose Navigation и собственную реализацию роутера для межмодульного взаимодействия.
Если речь идет про перерисовку на превьюшке в студии, то там есть еще некоторые проблемы с тулзами для разработки, но это дело поправляемое. Например, если дебажить на физическом устройстве, то все довольно шустро отрабатывает (тут просто нужно капать в причину, почему вы столкнулись с такой проблемой).
Если речь про перформанс в сборке, то тут, на самом деле, многое зависит от того, как использовать рекомпозицию. В Compose есть свои особенности связанные с условиями при которых происходит перерисовка. И если пользоваться этим инструментом неправильно, то вместо, скажем, рекомпозиции отдельной кнопки, будет происходить перестроение всей иерархии. Тогда да, тогда перформанс просядет ощутимо (особенно заметно будет на списках или вложенных компонентах интерфейса).
Но тут на самом деле даже причина не в инструменте, а в том как его используешь. Просадить перфоманс можно и наверстав LinearLayout'ов вложенных, условно)
Хранение на устройстве - не самая идеальная история, согласен, но она определенно проще контролируется с точки зрения безопасности, нежели хранение личных данных на стороннем сервере. Если мы гоняем данные, пусть и по защищенному каналу в облако, то проблема здесь в том, что данные хранятся в облаке и агрегрируются данные там не только мои, но и миллионов других пользователей. С точки зрения банального экономического "интереса взломщика" такой узел, на котором много данных (которые потом отлично продаются), становится куда более интересным для атаки, нежели мой личный телефон.
Да и безопасность телефона определенно будет выше, со стороны внешнего взлома при условии: приложения с непроверенных источников не ставить, по не нужным сайтам не ходить, файлы непонятные не качать и т.д. и т.п.. Шифрование в моем случае, это своего рода второй фактор безопасности к первому естественному (этим устройством пользуюсь только я и пользуюсь с соблюдением банальных правиль личной безопасности).
На самом деле, из абсолютно надежных средств хранения можно выделить, разве что: "блокнот и ручка в сейфе". Здесь даже личная голова будет далеко не идеальным средством, т.к. она имеет свойство "забывать".
Я не пытаюсь сказать, в однозначном порядке, что мол "нет, не пользуйтесь облачниками, это ужасно и плохо". Нет, они хороши по своему. Просто, когда ты параноишь, но при этом бесишься от того, что постоянно нужно вводить ручками пароль с бумаги или пользоваться существующими решениями с интерфейсом времен 2000х, то со временем появляется устойчивое желание найти что-то удовлетворяющее всем твоим требованиям. А когда не находишь, то берешь и делаешь что-то подобное сам =)
P.S.: В моем случае главным мотиватором, чтобы отказаться от внешнего хранилища было как раз таки то, что мои данные с этого облачного менеджера слизали.
Дело в том, что когда я выбирал тему приложения, то я руководствовался несколькими параметрами:
Жизненная ситуация: мои пасы были слиты одной компанией N (я пользовался их сервисом безопасного облачного хранения - имен называть не буду по известным причинам)
Хотел максимально маленькое приложение (в минимальном приближении, но не бесполезное с точки зрения функционала), чтобы сильно не зарываться на первых парах (т.к. все таки "обкатываю" Compose)
Я люблю интуитивные, понятные, эстетически приятные интерфейсы (коим KeePassXC в моем представлении не удовлетворяет - опять же это только мое субъективное восприятие)
А еще я в перспективе, хочу добавить возможность напрямую подрубать, условно, флешку в девайс. чтобы хранилищем выступало не устройство, а внешний носитель. Тогда безопасность будет уровня "тетрадка в сейфе", т.к. приложение будет выступать лишь удобным интерфейсом взаимодействия с хранилищем. Как-то так. Надеюсь ответил на ваши вопросы о причинах выбора данной темы приложения)