Что такое SwiftUI?
SwiftUI — это набор инструментов для создания пользовательского интерфейса, который позволяет нам декларативно разрабатывать приложения. Если объяснить проще, то мы говорим SwiftUI, как мы хотим, чтобы наш пользовательский интерфейс выглядел и работал, и он сам дальше организует все взаимодействие с пользователем.
Декларативный пользовательский интерфейс лучше всего понимается по сравнению с императивным, которым разработчики iOS занимались до iOS 13. В императивном пользовательском интерфейсе мы могли бы заставить функцию вызываться при нажатии кнопки, а внутри функции мы читали бы значение. и меняли бы строку на экране в зависимости от происходящего.
Императивный UI вызывает всевозможные проблемы, большинство из которых связано с состоянием (state), что является еще одним причудливым термином, означающим «значение, которое мы храним в нашем коде». Нам нужно отслеживать, в каком состоянии находится наше приложение, и каждый раз убеждаться, что наш пользовательский интерфейс правильно отражает это состояние.
Если у нас есть один экран с одним логическим свойством, которое влияет на пользовательский интерфейс, у нас есть два состояния: логическое значение может быть включено или выключено. Если у нас есть два логических значения, A и B, теперь у нас есть четыре состояния:
A выключен, B выключен A включен, B выключен A выключен, B включен А включен, В включен
А если у нас есть три логических значения? Или пять? Или целые числа, строки, даты и т.д.? Что ж, тогда все становится намного сложнее.
Если вы когда-либо использовали приложение, в котором говорится, что у вас есть одно непрочитанное сообщение, независимо от того, сколько раз вы пытались его прочитать, это проблема состояния — это императивная проблема пользовательского интерфейса.
Декларативный пользовательский интерфейс позволяет нам сообщить iOS обо всех возможных состояниях нашего приложения сразу. Мы можем сказать, что если мы вошли в систему, то нужно показывать приветственное сообщение, но если мы вышли из системы, показывать кнопку входа. Нам не нужно писать код для перемещения между этими двумя состояниями вручную — сейчас это кажется странным способом работы!
Вместо этого мы можем позволить SwiftUI перемещаться между макетами пользовательского интерфейса при изменении состояния. Мы уже сказали, что показывать в зависимости от того, был ли пользователь авторизован или нет, поэтому, когда мы меняем состояние аутентификации, SwiftUI может обновлять пользовательский интерфейс от нашего имени.
Вот что означает декларативность: мы не заставляем SwiftUI показывать или скрывать компоненты вручную, мы просто сообщаем ему все правила, которым мы хотим, чтобы он следовал, и оставляем его работать, чтобы он сам гарантировать соблюдение этих правил.
Но SwiftUI не останавливается на достигнутом: он также выступает в роли кроссплатформенного пользовательского интерфейса, который работает в iOS, macOS, tvOS и даже watchOS. Это означает, что теперь вы можете изучить один язык и создать один макет, а затем развернуть его где угодно.
SwiftUI или Interface Builder?
Каждый разработчик iOS знаком с Interface Builder и сторибордами, а также, возможно, с XIB. Они могут вам не нравиться, но все знакомы с ними. Если вы не использовали их раньше, просто пропустите этот бит.
Скорее всего вы не редактировали XIB вручную. Ну, кроме, может быть, одного раза, но в целом ответ скорее всего отрицательный — XIB содержат довольно большой объем XML, который нелегко читать и сложно редактировать.
Что еще хуже, сториборды со временем становятся все больше и больше. Конечно, они могут начинаться с малого, но затем вы добавляете еще один контроллер представления и еще один, и еще один, и внезапно вы понимаете, что у вас есть десять экранов в одном файле, и любые изменения в системе управления версиями, которые вы вносите, внезапно становятся довольно болезненными.
Это лишь часть проблемы — то, что практически невозможно понять, что изменилось, когда кто-то открывает пул-реквест для получения изменений в экранах. Есть и другая проблема в сторибордах и XIB.
Видите ли, Interface Builder мало что знает о нашем коде Swift, а наш код Swift мало знает о Interface Builder. В результате мы получаем множество небезопасных ситуаций: мы, удерживая Ctrl, перетаскиваем элементы из IB в наш код, чтобы связать что-то с действием, но если мы затем удалим это действие, код все равно скомпилируется — IB действительно все равно, если код больше не существует.
Точно так же, когда мы создаем View Controller в сториборде или определяем ячейки табличного представления в очереди, мы используем строки для идентификации важных объектов в нашем коде — система настолько широко распространена, что у нее даже есть собственное имя: «API со строковой типизацией» (stringly typed API). Даже в этом случае нам нужно использовать приведение типов, потому что Swift не может знать, что полученная им ячейка табличного представления на самом деле является TableViewCell.
Эти проблемы существуют, потому что IB и Swift — очень разные вещи. В этом нет ничего удивительного — Interface Builder не только появился еще до того, как появилась оригинальная Mac OS X, но и во многом спроектирован так, как работает Objective-C.
SwiftUI делает серьезный шаг вперед. Это среда, предназначенная только для Swift, не потому, что Apple решила, что Objective-C пора умереть, а потому, что она позволяет SwiftUI использовать весь спектр функциональных возможностей Swift — типы значений, непрозрачные возвращаемые типы, расширения протоколов и многое другое.
На данный момент самое меньшее, что вам нужно знать, это то, что SwiftUI устраняет многие проблемы, с которыми люди сталкивались со старым подходом Swift + Interface Builder:
- Нам больше не нужно спорить о программном дизайне или дизайне на основе сторибордов, потому что SwiftUI предоставляет нам и то, и другое одновременно.
- Нам больше не нужно беспокоиться о проблемах управления версиями при работе с пользовательским интерфейсом, потому что код намного проще читаем и управляем, чем в случае XML файлов.
- Нам больше не нужно так сильно беспокоиться о API-интерфейсах со строковой типизацией — они все еще есть, но их значительно меньше.
- Нам больше не нужно беспокоиться о вызове несуществующих функций, потому что наш пользовательский интерфейс проверяется компилятором Swift.
Итак, я надеюсь, вы согласитесь, что переход на SwiftUI принесет много преимуществ! Об остальном мы расскажем в следующей статье, не пропустите!