Не понимаю, чем это решение лучше, чем compose-destinations? CD существуют уже больше 3х лет, задолго до создания этой библиотеки, и обладает бОльшим функционалом.
Также не понял где был "обгон" заявленный в заголовке. У самой compose навигации давно есть тоже своя система типобезопасной навигации через котлин-сериализацию, около года. Однако библиотека в статье была создана около недели назад, судя по истории коммитов. По структуре первого коммита можно увидеть что она недавно была сгенерирована из свежего шаблона, аргумент с тем, что она была в закрытом доступе, отпадает.
А вы сделали вместо этого события и всю статью пытаетесь подогнать события под состояния. Неудивительно, что ни ваше начальное, ни конечное решения работать корректно не будут. Как раз поэтому вам и нужны были делеи и прочее - вы неправильно реализовали консистентность состояний и обработку их согласно ЖЦ, следовательно обновления ваших состояний были просто утеряны. Логично, что и маркеры не отрисуются. Без обид, но я бы на вашем месте статью удалил.
И проблема не в оптимистичной рекомпозиции. Композиция отменит предыдущую отрисовку и запустит новую. Кейса когда что-то "не отрисовалось" тут быть не может, если состояние не используется неправильно. А судя по начальному силду где каждый кусок карты это отдельный Стейт - оно так и есть.
По статье видно, что у авторки айфон. В Андроиде нет "системной" клавиатуры, и "стандартной" тоже нет. Есть только приложение клавиатуры, установленное из коробки. Следовательно, все сравнения проводились используя или Gboard, или Samsung keyboard, потому что они были предустановлены на телефонах в наличии, но упоминания того, что можно поставить любую клавиатуру (в том числе как на Айфоне) не вижу. Из-за этого кастомные тулбары превращаются в отдельную статью с кастомными клавиатурами :)
Также, про SMS Retriever, неправильно, можно использовать autofill и клавиатура будет смотреть на сообщения, а приложению делать ничего не надо.
Про скрытие клавиатуры по скроллу тоже неправильно - в прошлом году появилась возможность анимировать и плавно сворачивать клавиатуру при скролле (imeNestedScroll), тогда клавиатура уедет с экрана вместе с содержимым. Также можно реализовать в целом любое поведение - автоскрытие по клику или скроллу, но это уже не из коробки, а вручную, как в iOS
1. Утечка активити через небезопасный мутабельный var в слой вьюмодели, который переживает смену конфигурации 2. Утечка navController через навигатор который тоже переживает смену конфигурации 3. Использование антипаттерна lateinit 4. Оверинжиниринг архитектуры с кучей лишних сущностей, которые просто могли быть базовой реализацией MVI 5. Небезопасные вызовы first() и equals, крашащие приложение в кейсах нелинейной навигации 6. Бесполезная пересоздающаяся сущность Actions которая могла быть заменена простыми интентами 7. Нестабильные референсы в параметрах композабл 8. Кривой английский
Автор, пожалуйста удалите статью, чтобы не рушить еще больше репутацию компании Сбербанк и избежать обучению новичков антипаттернам и созданию ошибок в приложениях. Рекомендую избавиться также от подобных косяков в вашем приложении, потому что это обнажает качество кода в Сбере
Вырезать бесполезные derivedStateOf которые не уменьшают количество вычислений и заменить их нормальными, вы (если вы писали код) пока не понимаете зачем нужны derivedState и как их использовать, рекомендую почитать доки, сделать анимации через animate*AsState а не вручную считать на каждый кадр, битмапы можно кропать через modifier.clip/size, а не пересоздавать. Блюр для иконок делать можно и правда через modifier.blur используя второй размытый слой битмапа с маской или написать шейдер. Не использовать низкоуровневые api типа canvas, сделать можно проще через композицию
И я не верю что ваше решение не лагает. Даже на гифке лагает. А самое важное это не лаги а потребление батареи и памяти
Вы не правы, транзишны уже почти готовы и их поддержка добавлена с версии 1.5 (около того) Анимаций у Row/Column тоже Анимации у lazy списков пофиксили довольно давно.
К слову в статье много ошибок в реализации, начиная от вычисления анимаций на каждый кадр и заканчивая кропом битмапа на каждый кадр... Блюр как сказали выше тоже неверно реализован.
К сожалению сейчас сделать приложение которое бы переплюнуло уже имеющиеся, развитые трекеры привычек сложно. Как пет-проект от начинающего разработчика выглядит более-менее неплохо, но пользоваться приложением нет смысла если есть respawn.pro или habitica.com .
Если сравнивать с куском бумаги, то приложение действительно "работает". Однако по сравнению с приложениями выше - совсем оно не работает.
Не понимаю, чем это решение лучше, чем compose-destinations? CD существуют уже больше 3х лет, задолго до создания этой библиотеки, и обладает бОльшим функционалом.
Также не понял где был "обгон" заявленный в заголовке. У самой compose навигации давно есть тоже своя система типобезопасной навигации через котлин-сериализацию, около года.
Однако библиотека в статье была создана около недели назад, судя по истории коммитов.
По структуре первого коммита можно увидеть что она недавно была сгенерирована из свежего шаблона, аргумент с тем, что она была в закрытом доступе, отпадает.
В чем был обгон?
Вам там и объяснили, что если вы не хотели отрисовывать все вместе, вы должны были сделать по-другому и сделать семью вложенных состояний, как я объясняю в этой статье https://proandroiddev.com/how-to-safely-update-state-in-your-kotlin-apps-bf51ccebe2ef
А вы сделали вместо этого события и всю статью пытаетесь подогнать события под состояния. Неудивительно, что ни ваше начальное, ни конечное решения работать корректно не будут. Как раз поэтому вам и нужны были делеи и прочее - вы неправильно реализовали консистентность состояний и обработку их согласно ЖЦ, следовательно обновления ваших состояний были просто утеряны. Логично, что и маркеры не отрисуются. Без обид, но я бы на вашем месте статью удалил.
И проблема не в оптимистичной рекомпозиции. Композиция отменит предыдущую отрисовку и запустит новую. Кейса когда что-то "не отрисовалось" тут быть не может, если состояние не используется неправильно. А судя по начальному силду где каждый кусок карты это отдельный Стейт - оно так и есть.
По статье видно, что у авторки айфон. В Андроиде нет "системной" клавиатуры, и "стандартной" тоже нет. Есть только приложение клавиатуры, установленное из коробки. Следовательно, все сравнения проводились используя или Gboard, или Samsung keyboard, потому что они были предустановлены на телефонах в наличии, но упоминания того, что можно поставить любую клавиатуру (в том числе как на Айфоне) не вижу. Из-за этого кастомные тулбары превращаются в отдельную статью с кастомными клавиатурами :)
Также, про SMS Retriever, неправильно, можно использовать autofill и клавиатура будет смотреть на сообщения, а приложению делать ничего не надо.
Про скрытие клавиатуры по скроллу тоже неправильно - в прошлом году появилась возможность анимировать и плавно сворачивать клавиатуру при скролле (imeNestedScroll), тогда клавиатура уедет с экрана вместе с содержимым. Также можно реализовать в целом любое поведение - автоскрытие по клику или скроллу, но это уже не из коробки, а вручную, как в iOS
Охренительная статья :D
1. Утечка активити через небезопасный мутабельный var в слой вьюмодели, который переживает смену конфигурации
2. Утечка navController через навигатор который тоже переживает смену конфигурации
3. Использование антипаттерна lateinit
4. Оверинжиниринг архитектуры с кучей лишних сущностей, которые просто могли быть базовой реализацией MVI
5. Небезопасные вызовы first() и equals, крашащие приложение в кейсах нелинейной навигации
6. Бесполезная пересоздающаяся сущность Actions которая могла быть заменена простыми интентами
7. Нестабильные референсы в параметрах композабл
8. Кривой английский
Автор, пожалуйста удалите статью, чтобы не рушить еще больше репутацию компании Сбербанк и избежать обучению новичков антипаттернам и созданию ошибок в приложениях. Рекомендую избавиться также от подобных косяков в вашем приложении, потому что это обнажает качество кода в Сбере
Вырезать бесполезные derivedStateOf которые не уменьшают количество вычислений и заменить их нормальными, вы (если вы писали код) пока не понимаете зачем нужны derivedState и как их использовать, рекомендую почитать доки, сделать анимации через animate*AsState а не вручную считать на каждый кадр, битмапы можно кропать через modifier.clip/size, а не пересоздавать. Блюр для иконок делать можно и правда через modifier.blur используя второй размытый слой битмапа с маской или написать шейдер. Не использовать низкоуровневые api типа canvas, сделать можно проще через композицию
И я не верю что ваше решение не лагает. Даже на гифке лагает. А самое важное это не лаги а потребление батареи и памяти
Вы не правы, транзишны уже почти готовы и их поддержка добавлена с версии 1.5 (около того)
Анимаций у Row/Column тоже
Анимации у lazy списков пофиксили довольно давно.
К слову в статье много ошибок в реализации, начиная от вычисления анимаций на каждый кадр и заканчивая кропом битмапа на каждый кадр... Блюр как сказали выше тоже неверно реализован.
К сожалению сейчас сделать приложение которое бы переплюнуло уже имеющиеся, развитые трекеры привычек сложно. Как пет-проект от начинающего разработчика выглядит более-менее неплохо, но пользоваться приложением нет смысла если есть respawn.pro или habitica.com .
Если сравнивать с куском бумаги, то приложение действительно "работает". Однако по сравнению с приложениями выше - совсем оно не работает.