Перевод статьи подготовлен в преддверии старта занятий в новой группе курса "iOS Developer. Professional".
Фреймворк SwiftUI появился в прошлом году, и реализованный в нем подход «один раз выучить и применять на всех платформах» сразу же заинтересовал многих разработчиков ПО для Apple. Немного позанимавшись им, мы написали обзор самого SwiftUI, а также оценили возможности его использования совместно с Combine.
Сочетание этих технологий показалось нам перспективным, а работать над пользовательским интерфейсом оказалось очень приятно. Однако фреймворк не был лишен недостатков и поддерживал лишь простейшие операционные системы. Возможно, поэтому ему не удалось завоевать популярность сразу.
Улучшенный SwiftUI
Набор инструментов подвергся существенным доработкам, а на конференции WWDC, которая состоялась в этом году, объявили о выходе очередных обновлений. Благодаря этим улучшениям все больше команд смогут постепенно перейти к новой методике разработки кроссплатформенных слоев пользовательского интерфейса для iOS, iPadOS, macOS, tvOS и даже watchOS с использованием единого набора инструментов и API.
Ожидается переход к более декларативному программированию, и мы должны быть к нему готовы.
Именно об этом я говорил на недавней виртуальной конференции Shift Remote E05: MOBILE. Здесь можно посмотреть запись.
Теперь давайте разберемся: что обещали нам создатели SwiftUI, что мы в итоге получили и что ожидает нас в перспективе. Располагайтесь поудобнее — мы начинаем.
Тихое начало громкой истории
Анонсируя разработку SwiftUI, компания Apple обещала, что новый фреймворк станет революционным поворотом в истории разработки приложений для платформы Apple. Вот что они говорили.
Нам нужно будет писать меньше кода. Написание длинного шаблонного кода для tableView и collectionView останется в прошлом.
Интерфейсы станут адаптивными во всех отношениях.
Платформа: наши приложения будут использоваться как объекты первого класса на всех платформах Apple — от Mac до iPhone и часов Apple. Код будет адаптироваться так, чтобы в полной мере использовать возможности соответствующей платформы, например средства выбора будут отображаться в виде прокручиваемого списка в iOS и в виде раскрывающегося списка в macOS.
Светлая и темная темы: используя функции, которые появились в iOS 13 (такие как системная палитра), можно будет адаптировать приложение к одной из них. Я написал руководство по адаптации приложения к темной теме. Для этого в SwiftUI есть очень удобная обертка свойств @Environment, которую можно использовать для доступа к текущим параметрам среды и ее обновлениям.
Масштабируемость шрифтов: шрифты, которые используются в SwiftUI, будут согласовываться с размером шрифта, установленным пользователем, и представления (например, Text) будут масштабироваться в соответствии с настройками.
Идем дальше. Наряду с адаптивностью нам обещали обновления, которые ускорят процесс разработки и повысят его эффективность, — возможность предварительного просмотра интерфейса приложения в процессе работы над ним.
Во Flutter и React Native уже была такая возможность, и в прошлом году у нас появилась наконец собственная альтернатива цепочке команд build-install-run, которая позволяет существенно экономить время разработчика при выполнении повседневных задач. Функция предварительного просмотра будет автоматически выводить на экран код по мере его написания, а также внесенные изменения. Предусматривалась также функция динамического просмотра, позволяющая протестировать пользовательское взаимодействие или навигацию по аналогии с запуском приложения в эмуляторе или на настоящем устройстве.
Благодаря сочетанию новых возможностей работы с кодом и предварительного просмотра мы получили единый источник достоверных данных о нашем пользовательском интерфейсе. Больше не требовалось проверять раскадровку, файлы xib или код, чтобы узнать, где произошла перезапись функции, приведшая к возникновению багов в интерфейсе.
Декларативный подход к разработке приложений для Apple
И наконец появился собственный декларативный подход к разработке приложений для платформы Apple. Императивный подход прошел испытание временем, но общий прогресс в области разработки пользовательских интерфейсов, а также повышение сложности приложений, ожидаемых нашими пользователями, требовали свежих решений, повышающих производительность и упрощавших управление состоянием.
Поэтому предполагалось, что SwiftUI будет как раз тем самым потрясающим инструментом, который компания Apple завернула в красивую обертку и вручила нам со словами: «Вот, можете экспериментировать». Поэтому, когда нам выдали что-то новое и совсем незнакомое, ничего другого нам и не оставалось. Тем временем стали появляться статьи, в которых утверждалось, что Objective-C, UIKit/AppKit скоро совсем исчезнут и их полностью заменит SwiftUI.
Но медовый месяц не может длиться вечно, и вскоре нам пришлось снять розовые очки. Оказалось, что в SwiftUI еще есть над чем поработать. Функция предпросмотра работала нестабильно. Новые версии Xcode/Swift ломали существующий код SwiftUI. Навигация тоже иногда вылетала. Фреймворк не сохранял стек навигации при работе со вкладками. Для элементов интерфейса, к которым мы привыкли, работая с UIKit, не было аналогов.
Простые интерфейсы разрабатывались быстро и просто, но для создания чего-то чуть более сложного или для корректировки существующих элементов (например, Lists) приходилось возвращаться к UIKit/AppKit, что лишало этот подход заявленной декларативности.
И что не менее важно, SwiftUI можно было развернуть только на iOS 13 или более поздних. В контексте крупномасштабных приложений это означало потерю значительной части клиентской базы. Что никого не устраивало. И тут мы задумались об управлении состоянием и о том, как его декларативность поможет решить возникающие проблемы.
Управление состоянием (непростая задача)
Управлять состоянием очень непросто.
Почтовый клиент Apple Mail.
Рассмотрим экран приложения Apple Mail. Это список данных, организованных в виде модели данных (в нашем случае данных электронной почты), а также дополнительные функции навигации, фильтры и действия.
Для того чтобы создать такой экран, нужно подключить файлы представления к моделям. Каждая стрелка на изображении ниже обозначает зависимость.
Зависимости в одном интерфейсе
Как видите, здесь много взаимосвязанных элементов, так как действия UI могут обновлять модели, которые в свою очередь могут обновлять UI. Если вам это кажется сложным, задумайтесь: это всего лишь один интерфейс. В современных приложениях интерфейсов гораздо больше, и для них может использоваться одна и та же модель, что делает нашу задачу еще более запутанной.
Зависимости между несколькими интерфейсами
Здесь хочется вернуться к самому началу раздела: управление состоянием — непростая задача, а управление состоянием крупномасштабных приложений, которые мы разрабатываем для своих клиентов, года от года становится все труднее. Поддержка различных размеров экрана, светлая и темная темы, специальные возможности, сложные элементы устройств, например AR или Bluetooth, многопользовательские режимы и так далее — все эти требования делают разработку приложений в 2020 году сложной как никогда. В командах стало больше разработчиков, каждый из которых обладает отдельными навыками. Чтобы получить целостное приложение, требуется дополнительно координировать их работу.
Конечно, разместить многофункциональную кнопку на экране несложно. Но как она поведет себя при использовании специальных возможностей? Корректно ли она отображается на экранах разных размеров и с разной ориентацией? Изменяется ли ее представление при смене размера шрифта? Передается ли состояние, которое она изменяет, всем связанным интерфейсам? А теперь представьте, что все сказанное нужно реализовать не для одной кнопки, а для всех элементов интерфейса. Это уже не так-то просто, да?
Задача iOS-разработчиков — создать приложение с адаптивным дизайном, соответствующее требованиям клиентов и доступное людям с ограниченными возможностями. Если мы не сделаем этого, наши клиенты испытают разочарование, а конечный продукт будет выглядеть дешевым и ненадежным.
Не забывайте: клиенты видят только интерфейс. Если интерфейс сделан плохо, клиенты думают, что и весь продукт тоже плохой. И уже неважно, насколько хорошо проработана серверная часть или программный код.
Декларативное решение
Теперь у нас есть SwiftUI, и не нужно беспокоиться о том, как будет происходить переход между всеми этими состояниями. Старая, как мир, проблема, с которой сталкивался, наверное, каждый программист, — анимация переходов на основе построчного сравнения кода — ушла в прошлое. Нам всего лишь надо написать код, который описывает каждое состояние, а система выполнит все остальное. И это похоже на магию!
Декларативный подход SwiftUI к управлению состоянием
В SwiftUI реализован декларативный подход к разработке пользовательского интерфейса. Создавая иерархию представлений, вы указываете зависимости данных для этих представлений. При изменении данных в результате внешних событий, таких как уведомления или в результате действий пользователя, SwiftUI автоматически обновляет все связанные части интерфейса. То есть этот фреймворк выполняет почти всю работу, которую прежде выполняли контроллеры представлений.
Это однонаправленный подход: Действие -> Состояние -> Представление. Нам больше не нужно задаваться вопросом о синхронизации UI и моделей данных. Обновить Представления может только Состояние, а обновить Состояние могут только Действия. Поскольку Представления не могут напрямую обновлять Состояние, задача решается автоматически.
Ближайшие перспективы
Понимая, каким был SwiftUI в самом начале и для чего он был предназначен, перейдем теперь к обновлениям, о которых было объявлено на конференции WWDC, и рассмотрим перспективы этого фреймворка.
Новые элементы и функции UI
В этом году в SwiftUI добавлено много новых представлений. Это потрясающая новость как для разработчиков, которые уже разобрались с фреймворком, так и для тех, кто только начинает его осваивать.
Большинство из нас с нетерпением ожидали новых элементов UI, к которым мы привыкли, и думаю, я не ошибусь, если скажу, что мы остались довольны нововведениями.
TextEditor — встроенная возможность добавлять в интерфейс увеличенные текстовые поля. Этим она отличается от текстовых полей (TextField), которые использовались в SwiftUI со времен первого релиза. Больше не нужно заключать в обертку UITextView в UIKit, по крайней мере в тех случаях, когда нам нужно добавить в приложение базовые функции редактирования текста.
ProgressView — новое представление индикатора загрузки, которое адаптируется к платформе и может также использоваться в качестве индикатора выполнения (например, при загрузке данных).
Поддержка документоориентированных приложений — у нас появилось два новых типа: протокол FileDocument, который определяет, как будет выглядеть документ в приложении, и структура DocumentGroup, которая позволяет пользователям создавать, открывать и сохранять документы.
LazyHGrid и LazyVGrid — в первоначальной версии SwiftUI нам явно не хватало альтернативы для представления коллекции, а теперь в нем появились эти сетки, с помощью которых можно создавать макеты, похожие на те, к которым мы привыкли. Это контейнеры, чьи потомки расположены в виде сетки, которая может увеличиваться как в горизонтальном, так и в вертикальном направлениях по мере необходимости.
Реализация концепции лени — одно из главных изменений фреймворка, которые произошли в этом году. В SwiftUI также появились представления LazyHStack и LazyVStack, которые могут использоваться наряду со своими традиционными (не ленивыми) аналогами. Ленивые представления выполняют свою задачу не сразу, а только тогда, когда это потребуется. Они могут существенно повысить быстродействие приложения, особенно когда приходится работать с большими коллекциями и другими данными, на обработку которых уходит много ресурсов.
В SwiftUI появилось еще много новых возможностей, о которых можно написать отдельный пост: matchedGeometryEffect, ScrollViewReader, ColorPicker, DisclosureGroup и др. Следите за новостями на Capsized Eight!
Новые обертки свойств
Помимо широкого набора оберток над свойствами, которые уже есть в SwiftUI, появились новые обертки, которые облегчат нам жизнь.
@AppStorage — позволяет считывать и записывать UserDefaults
@ScaledMetric — масштабирует значения относительно параметров Dynamic Type
@StateObject — безопасно создает типы обращений в представлениях
и другие, например @UIApplicationDelegateAdaptor, @Namespace, @SceneStorage
В iOS 13 нам приходилось использовать UIHostingController (или NSHostingController на Mac), чтобы отрисовать представления SwiftUI, но теперь иерархию корневых представлений можно встроить в тип, соответствующий новому протоколу App, и добавить к нему атрибут @main. Это будет точкой входа в наше приложение — без AppDelegate и кода начальной загрузки.
Не просто альтернатива
Все, что мы сейчас наблюдаем, приводит меня к выводу:
SwiftUI — это не просто альтернатива, это наше будущее.
Компания Apple уже начала позиционировать его как единственное средство создания виджетов для новейших версий ОС. Фреймворк используется и в macOS для работы над обновленными функциями, например над новым центром уведомлений.
Новый унифицированный язык дизайна, который продвигает компания Apple, а также тот факт, что на компьютерах Mac под управлением Apple Silicon можно будет запускать приложения для iOS/iPadOS, говорит о том, что идея использования единого фреймворка для разработки пользовательского интерфейса для любых платформ вполне жизнеспособна.
SwiftUI появился чуть больше года назад, и его история только начинается. Все обновления и доработки уже делают его практически незаменимым инструментом, а в будущем он будет использоваться для разработки интерфейсов приложений для всех платформ Apple.
Разве не так?
Странное изображение появилось на этой странице благодаря дизайнеру Kata Juras.
