UIKit впервые появился в iOS 2 и до сих пор остаётся с нами. Со временем мы привыкли к нему и научились с ним работать. Мы нашли различные архитектурные подходы, и MVVM стал самым популярным, на мой взгляд. С выходом SwiftUI, MVVM ещё больше укрепил свои позиции, в то время как другие архитектуры не очень хорошо себя чувствую на SwiftUI.
Однако архитектуры, которые, казалось бы, не могут быть использованы со SwiftUI, возможно адаптировать к SwiftUI, и они даже могут быть удобнее, чем MVVM.
Я хочу рассказать об одной из таких архитектур — MVI
За годы работы разработчиком iOS, я собрал множество инструментов и полезных штук, которые облегчают процесс разработки. В этой статье, я хочу поделиться одним из таких инструментов. Это будет не большая статья. Я покажу, как пользоваться этой утилитой, продемонстрирую её в действии. Надеюсь, что статья окажется полезной для вас.
SwiftData отлично функционирует внутри View: достаточно добавить декоратор @Query к свойству, и все будет работать 'из коробки'. Однако, когда возникает желание вынести работу со SwiftData в отдельный модуль, начинают появляться сложности, особенно касаемо выполнения операций в фоновом режиме.
За годы работы разработчиком iOS, я собрал множество инструментов и полезных штук, которые облегчают процесс разработки. В этой статье, я хочу поделиться одним из таких инструментов. Это будет не большая статья. Я покажу, как пользоваться этой утилитой, продемонстрирую её в действии. Надеюсь, что статья окажется полезной для вас.
Как можно начать переезжать на SwiftUI? Постепенно. Переписывать целый экран слишком дорого по времени, а вот переписать ячейку или кнопку куда быстрее. Таким способом можно мигрировать на SwiftUI, постепенно переписывая экран. В этом поможет класс HostingView.
За годы работы разработчиком iOS, я собрал множество инструментов и полезных штук, которые облегчают процесс разработки. В этой статье, я хочу поделиться одним из таких инструментов. Это будет не большая статья. Я покажу, как пользоваться этой утилитой, продемонстрирую её в действии. Надеюсь, что статья окажется полезной для вас.
Мне часто встречалась ситуация когда надо подписать enum со вложенными типами под протокол Equitable и приходилось реализовывать его функции
Чтобы упростить жизнь и каждый раз не писать сложные static func ==(lhs: T, rhs: T) -> Bool Можно подписать enum под protocol ComplexEquatable
За годы работы разработчиком iOS, я собрал множество инструментов и полезных штук, которые облегчают процесс разработки. В этой статье, я хочу поделиться одним из таких инструментов. Это будет не большая статья. Я покажу, как пользоваться этой утилитой, продемонстрирую её в действии. Надеюсь, что статья окажется полезной для вас.
При разработке очень важна безопасность данных при параллельном доступе к ним. В этой статье я покажу , как создать потокобезопасное свойство с использованием свойства-обёртки @SynchronizedLock.
За годы работы разработчиком iOS, я собрал множество инструментов и полезных штук, которые облегчают процесс разработки. В этой статье, я хочу поделиться одним из таких инструментов. Это будет не большая статья. Я покажу, как пользоваться этой утилитой, продемонстрирую её в действии. Надеюсь, что статья окажется полезной для вас.
Работа с UserDefaults может быть удобной и простой, в этом поможет обертка UserDefaultsWrapper. Давайте разберемся, как она работает.
За годы работы разработчиком iOS, я собрал множество инструментов и полезных штук, которые облегчают процесс разработки. В этой статье, я хочу поделиться одним из таких инструментов. Это будет не большая статья. Я покажу, как пользоваться этой утилитой, продемонстрирую её в действии. Надеюсь, что статья окажется полезной для вас.
При разработке приложений, одним из ключевых аспектов является адаптивность интерфейса к различным режимам отображения, особенно к светлой и тёмной теме. Я покажу подход к управлению цветами интерфейса с использованием свойства-обёртки DynamicUIColor
В этой статье я объединил все свои знания и опыт, охватил все этапы разработки мобильных приложений. В статье не будет кода, она будет полезной не только для Android, iOS и Flutter-разработчиков, но также тем, у кого нет опыта в программировании.
Я пройдусь по основным этапам разработки мобильного приложения:
• Проработка идеи • Проектирование UX/UI • Разработка • Аналитика • Продвижение • Дальнейшее развитие приложения
Расскажу о том, как создать свое приложение, которое будет интересно не только вам.
UIKit first appeared in iOS 2, and it is still here. Eventually we got to know it well and learned how to work with it. We have found many architectural approaches. MVVM, the most popular architecture in my opinion, has strengthened its position with the release of SwiftUI, while other architectures seemed to have some kind of problematic relationships with SwiftUI.
But what if I told you that Clean Swift, VIPER and other approaches can be adapted to SwiftUI. What if I told you that there are some modern architectures which might be as good as MVVM or even better.
SwiftUI – это молодая и пока что не совсем изученная технология. С одной стороны, большое пространство для творчества и исследования, а с другой – неизвестность, нестабильность и проблемы.
Так ли просто писать на SwiftUI, как показывают на WWDC? Я расскажу о сложностях, с которыми столкнулся лично я во время написания собственного приложения. Оно полностью написано на SwiftUI и выложено в App Store.
Какие проблемы могут встретиться во время разработки? Давайте разбираться.
Представим, нам нужно внести небольшую правку в работу экрана. Экран меняется каждую секунду, поскольку в нем одновременно происходит множество процессов. Как правило, чтобы урегулировать все состояния экрана, необходимо обратиться к переменным, каждая из которых живет своей жизнью. Держать их в голове либо очень трудно, либо вовсе невозможно. Чтобы найти источник проблемы, придется разобраться в переменных и состояниях экрана, да еще проследить, чтобы наше исправление не поломало что-то в другом месте. Допустим, мы потратили уйму времени и все-таки внесли нужную правку. Можно ли было решить эту задачу проще и быстрее? Давайте разбираться.
Представим команду, где не проводится Code review. Разработчики пишут код, и без проверок вносят все изменения в основную ветку. Спустя время расширяется функционал или находятся баги, они возвращаются к исходному коду, а там все переменные названы одной буквой, нет следования архитектуре, да и качество не самое лучшее. Этот некачественный код будет копиться и однажды наступит момент, когда, при любом мало-мальском нововведении, проект начнёт разваливаться: в лучшем случае – увеличится время разработки, в худшем – поддержка проекта станет невозможной. И это при том, что когда-то давно задача была выполнена и все хорошо работало.
