Кажется по вашей логике, любой код, который написан, является легаси, но это не так. Недавно делал общий компонент на проекте, старался покрывать докой максимально подробной, так как понимаю, что в будущем будут поддерживать другие люди. Как раз дока/тесты и пр помогают снизить трение)
Постарался тут ее плюсы показать. Согласен, что есть свои нюансы, но как по мне, не критичные. Помогает отловить кучу ошибок в компайл тайме ну и оптимизации стринги, вроде там слайсы используются, значит та же самая память. Кажется чем то все равно пришлось бы пожертвовать(
Интероп в Swift 5.9 появился, в рекомендашках как раз закинул докладик с Мобиуса, в котором Андрей Филипенко поковырял фичу
Асинк авейт вообще интересным был, его когда Apple выкатила, пришлось смотреть, как работает в других языках, типа котлина или C#, а то была проблема с тестированием некоторых историй
Привет! ? У нас на проекте нет проблем даже со сложным функционалом, все новые экраны, даже высоконагруженые списки мы делаем на SUI. Также мы следим за Performance метриками и применяем оптимизации.
?Тут? можно посмотреть доклад моего коллеги Александра Свиридова о том, как мы в Озоне собираем и используем метрики для улучшения опыта пользователя.
В таком случае, как по мне, порог входа в сегмент разработки увеличивается в разы, кажется, что для сложных решений всегда можно убрать слои абстракции и забить на сахар, но пока это не требуется?
Привет! ? Спасибо большое за ваш отзыв! Для меня это очень важно!
Всё же без применения дополнительных оберток выглядит куда более уверенно, но тут опять таки всё упирается в задачу, наверняка, если у нас возникнет необходимость использовать легаси код вместе с SwiftUI, мы пойдем их писать.
Было пару моментов, когда сложные интерфейсы хотелось сделать именно с использованием UIKit, но это скорее исключение из правил, пока нам удается использовать решения на SwiftUI в нашем проекте, даже со сложным интерфейсом?
Я понимаю, что использование UICollectionView с кастомным layout может быть хорошим решением для создания макетов в iOS приложениях. С появлением SwiftUI, это стало еще проще и удобнее, он позволяет создавать списки всего за несколько строк кода, а также предоставляет множество встроенных компонентов
Тут скорее про то, что SwiftUI позволяет использовать Modern Concurrency в более удобной и эффективной форме.
Я понимаю вашу точку зрения относительно мультиплатформенности, и в некоторых случаях TvOS и WatchOS могут работать с приложениями на UIKit. Однако, мультиплатформенность может требовать создания различных интерфейсов для разных платформ, и в таком случае использование SwiftUI может быть полезным ?
Для создания элементов в коде в UIKit есть несколько причин. Некоторые разработчики предпочитают создавать элементы в коде для более точной и гибкой настройки элементов. К тому же, возможностей, которые может предоставить визуальный дизайнер, может быть недостаточно для некоторых сложных проектов.
В некоторых случаях, код может быть более читаемым и проще для понимания, чем визуальный интерфейс.
Кроме того, SwiftUI предоставляет множество новых возможностей и улучшений в сравнении с UIKit. Использование SwiftUI может быть более выгодным для некоторых проектов?
Я согласен, что иногда обновления iOS могут приводить к проблемам с SwiftUI, поскольку это новая технология и она все еще развивается. Однако, в большинстве случаев, проблемы можно решить, используя обходные пути и дополнительные библиотеки. Также, я думаю, что с каждым обновлением iOS, SwiftUI становится все более стабильным и удобным в использовании. В целом, я считаю, что SwiftUI предлагает множество преимуществ и значительно упрощает процесс разработки приложений?
Если мы не берем в расчет старые добрые способы в виде принтов и брейкпоинтов, можно попробовать использовать стороннюю библиотеку ViewInspectorну и конечно же SwiftUI Previews дает много возможностей, просто не всегда получается запускать превью корректно, особенно в большом проекте
Благодарю за материал! Кажется статья подойдет и мобильным разработчикам, а не только для QA!)
Кажется по вашей логике, любой код, который написан, является легаси, но это не так. Недавно делал общий компонент на проекте, старался покрывать докой максимально подробной, так как понимаю, что в будущем будут поддерживать другие люди. Как раз дока/тесты и пр помогают снизить трение)
Постарался тут ее плюсы показать. Согласен, что есть свои нюансы, но как по мне, не критичные. Помогает отловить кучу ошибок в компайл тайме ну и оптимизации стринги, вроде там слайсы используются, значит та же самая память. Кажется чем то все равно пришлось бы пожертвовать(
Интероп в Swift 5.9 появился, в рекомендашках как раз закинул докладик с Мобиуса, в котором Андрей Филипенко поковырял фичу
Асинк авейт вообще интересным был, его когда Apple выкатила, пришлось смотреть, как работает в других языках, типа котлина или C#, а то была проблема с тестированием некоторых историй
Хорошая статья, спасибо за полезную информацию ?
Спасибо большое за статью!
Очень интересная и круто, что актуальная для проектов со SwiftUI!
Подскажи пожалуйста, как я могу использовать макросы в своем приложении, если минимальная таргет версия 14 iOS?
Привет! ?
У нас на проекте нет проблем даже со сложным функционалом, все новые экраны, даже высоконагруженые списки мы делаем на SUI. Также мы следим за Performance метриками и применяем оптимизации.
?Тут? можно посмотреть доклад моего коллеги Александра Свиридова о том, как мы в Озоне собираем и используем метрики для улучшения опыта пользователя.
В таком случае, как по мне, порог входа в сегмент разработки увеличивается в разы, кажется, что для сложных решений всегда можно убрать слои абстракции и забить на сахар, но пока это не требуется?
Привет! ?
Спасибо большое за ваш отзыв! Для меня это очень важно!
Всё же без применения дополнительных оберток выглядит куда более уверенно, но тут опять таки всё упирается в задачу, наверняка, если у нас возникнет необходимость использовать легаси код вместе с SwiftUI, мы пойдем их писать.
Было пару моментов, когда сложные интерфейсы хотелось сделать именно с использованием UIKit, но это скорее исключение из правил, пока нам удается использовать решения на SwiftUI в нашем проекте, даже со сложным интерфейсом?
Привет! ?
Я понимаю, что использование UICollectionView с кастомным layout может быть хорошим решением для создания макетов в iOS приложениях. С появлением SwiftUI, это стало еще проще и удобнее, он позволяет создавать списки всего за несколько строк кода, а также предоставляет множество встроенных компонентов
Тут скорее про то, что SwiftUI позволяет использовать Modern Concurrency в более удобной и эффективной форме.
Я понимаю вашу точку зрения относительно мультиплатформенности, и в некоторых случаях TvOS и WatchOS могут работать с приложениями на UIKit. Однако, мультиплатформенность может требовать создания различных интерфейсов для разных платформ, и в таком случае использование SwiftUI может быть полезным ?
Плюсую много раз про конфликты?
Привет!?
Для создания элементов в коде в UIKit есть несколько причин. Некоторые разработчики предпочитают создавать элементы в коде для более точной и гибкой настройки элементов. К тому же, возможностей, которые может предоставить визуальный дизайнер, может быть недостаточно для некоторых сложных проектов.
В некоторых случаях, код может быть более читаемым и проще для понимания, чем визуальный интерфейс.
Кроме того, SwiftUI предоставляет множество новых возможностей и улучшений в сравнении с UIKit. Использование SwiftUI может быть более выгодным для некоторых проектов?
Привет!?
Я согласен, что иногда обновления iOS могут приводить к проблемам с SwiftUI, поскольку это новая технология и она все еще развивается. Однако, в большинстве случаев, проблемы можно решить, используя обходные пути и дополнительные библиотеки. Также, я думаю, что с каждым обновлением iOS, SwiftUI становится все более стабильным и удобным в использовании. В целом, я считаю, что SwiftUI предлагает множество преимуществ и значительно упрощает процесс разработки приложений?
Привет!?
Если мы не берем в расчет старые добрые способы в виде принтов и брейкпоинтов, можно попробовать использовать стороннюю библиотеку ViewInspector ну и конечно же SwiftUI Previews дает много возможностей, просто не всегда получается запускать превью корректно, особенно в большом проекте
Привет!?
Давайте разберем конкретные моменты, мне это очень поможет?
Прекрасная статья?
Очень мотивирует и вдохновляет ❤️