Координация навигации по вью в SwiftUI с помощью паттерна Flow Coordinator
В этой статье я продемонстрирую, как можно использовать паттерн Flow Coordinator (далее флоу-координатор) в SwiftUI, чтобы отделить логику навигации от логики представления.
В UIKit этот шаблон был очень популярен — координаторы такого рода позволяют легко заменять или создавать новые вью-контроллеры (view controller), отделяя эту работу от кода вью-контроллеров и вью-моделей (view model). Это позволяет разделить во вью-контроллере код, затрагивающий саму вьюху, и навигацию, что в свою очередь облегчает изменение “потока приложения” (того самого флоу).
В некоторой степени подобное можно реализовать и в SwiftUI.
Kotlin Multiplatform Mobile — совместное управление состоянием пользовательского интерфейса
В своей предыдущей статье я рассказал о том, почему считаю, что мы можем значительно улучшить управление UI State (состояние пользовательского интерфейса) между View (представление) и ViewModel (модель представления) в Android, используя архитектуру Model-View-Intent (модель-представление-намерение) (MVI) с помощью Finite State Machine (машина с конечным числом состояний. конечный автомат) (FSM).
В этой статье я подскажу вам шаги, необходимые для модернизации этого решения до уровня Kotlin Multiplatform Mobile (KMM), где можно воспользоваться общим исходным кодом, содержащим MVI+FSM, так что обе платформы — Android и iOS — могут унаследовать его преимущества, отвечая только за платформозависимые реализации: UI/UX.
Облегчаем внедрение зависимостей и модульное тестирование с помощью асинхронных функций
Очень часто подготовка кода к модульному (или юнит-) тестированию имеет обыкновение идти рука об руку с работой по разделению ответственности, улучшению управления состояниями и его архитектуры в целом. Как правило, чем лучше абстрагирован и организован ваш код, тем легче его будет покрыть автоматизированными тестами.
Однако, стремясь сделать код более тестируемым, мы очень часто можем обнаружить, что в рамках этого процесса вводим массу новых протоколов и других видов абстракций, и в конечном итоге значительно усложняем наш код — особенно при тестировании асинхронного кода, который полагается на ту или иную форму сетевого взаимодействия.
Но действительно ли мы обречены платить такую цену за тестируемость? Что, если бы мы могли сделать наш код полностью пригодным для тестирования таким образом, чтобы от нас не требовалось вводить какие-либо новые протоколы, всевозможные моки или сложные абстракции? Давайте же разберемся, как мы могли бы реализовать это, используя новые возможности async/await Swift.
Не совсем очевидные тренды развития рынка приложений, как к ним подготовиться мобильному разработчику?
Когда платформа погибает, вакансий становится мало и остается пару лет подумать куда идти. С какого-то момента я стал заранее анализировать куда пойдет платформа, на которой я зарабатываю деньги. Мобильные приложения — это растущий рынок: за 2021 пользователи потратили в 142 млрд. долларов в App Store (92B $) и Google Play (50B $) на цифровые сервисы. Сегодня регуляторы вынуждают магазины приложений добавлять сторонние платежные сервисы, что создает хорошую перспективу для развития индустрии. Я преподаю разработку под iOS 8 лет, и в своих поздних авторских курсах мне уже удается прогнозировать рынок на несколько лет вперед и заранее готовить студентов к технологическому стеку, который будет востребован в будущем.
Хочу не просто рассказать про тренды, а проанализировать, какой технический стек будет важен на первых этапах развития ниши.
Развитие способностей коллекций в Swift (на примере функции suffix)
Протоколы иерархии Sequence/Collection имеют одно из самых важных значений в Swift, начиная со встроенности в язык (например, конструкция цикла for in) и заканчивая популярными функциями высшего порядка map, reduce и т.п. Часто разработчики путаются в особенностях, не осознавая возможности, предоставляемые отдельными протоколами иерархии коллекций. Давайте попробуем разобраться с этими особенностями на примере одной функции, которая по разному реализуется в этих протоколах — функция suffix.
Золотые правила “weak self”
Захват self в замыкании — обычная вещь в Swift, которая скрывает множество нюансов. Нужно ли делать его weak, чтобы избежать цикла ссылок? И является ли проблемой сделать его weak постоянно?
На прошлой неделе в iOS Dev Weekly была опубликована статья Benoit Pasquier, посвященная захвату self в замыканиях. Моя статья будет ей противоречить. И это нормально! Примите все эти советы с определенной долей скептицизма, разберитесь в компромиссах и выберите те техники, которые подходят вам лучше всего.
Память в Swift (куча, стек, ARC)
Для хранения объектов Swift использует две структуры данных: стек и кучу. Управление распределением памяти подразумевает выделение памяти под объект (аллокацию) и ее последующее высвобождение (деаллокацию).
В iOS существуют две модели управления памятью:
- MRC: manual reference counting (ручной подсчет ссылок)
- ARC: automatic reference counting (автоматический подсчет ссылок)
