UIKit - это бывший, из которого нельзя бросить, но можно заставить его работать

Ажиотаж и ажиотаж вокруг SwiftUI потрясающий. Все это гудит в Twitter, Sub-Reddits, подкастах, Stack Overflow и, конечно же, прямо здесь, на Medium. Да, хотя есть ряд причин, по которым, вероятно, не стоит выпускать приложение SwiftUI в производство прямо сейчас, нет никаких сомнений в том, что сообщество iOS уже начало внедрять его в некоторые из своих проектов.

Даже несмотря на весь ажиотаж, ажиотаж, проекты и марафоны 100 дней SwiftUI, в комнате все еще есть слон. И имя ему - UIKit.

SwiftUI все еще молод и свеж (в разработке ему буквально чуть больше месяца). Хотя есть свидетельства того, что Apple использует SwiftUI в последних версиях своих платформ, это не означает, что они охватили все это. Этого никогда не следовало ожидать, да и не должно быть в ближайшее время. И это не говоря уже обо всех фреймворках, модулях и пакетах с открытым исходным кодом, которые мы знаем и любим, которые, возможно, никогда не оставят позади свою идентичность UIKit.

Представительный: не совсем притворство

Выпущенный вместе со SwiftUI, Apple предоставляет обходной путь. UIViewRepresentable и UIViewControllerRepresentable - это протоколы, настроенные для обертывания элементов UIKit в View вместе с заглушками, которые устанавливают взаимодействие между вашими элементами и кодом SwiftUI.

Это означает, что ваш UIView является настоящим UIView и находится внутри реального SwiftUI View. Однако (не вдаваясь в политическую подоплеку), репрезентация - это не то же самое, что прямое личное общение. Особенно, когда репрезентативная модель (или, в данном случае, протокол) сделана универсальной.

Давайте быстро рассмотрим пример, чтобы понять, что я имею в виду.

LinkPresentation: изменение размера имеет значение

LinkPresentation - это новая функция для разработчиков в iOS 13, которая открывает то, что Apple использует для предварительного просмотра ссылок в сообщениях. LPLinkView - это UIView, что имеет смысл по нескольким причинам. Во-первых, он делает его доступным для существующих проектов (даже если это для iOS 13+). Во-вторых, он явно уже существовал в Messages до того, как появился SwiftUI, поэтому здесь не нужно изобретать колесо.

Без проблем! Мы просто обернем его UIViewRepresentable:

И все, правда? Готово, конец истории, до свидания.

НЕПРАВИЛЬНО! Это, к сожалению, не. Хотя наш UIView может обрабатывать завершение выборки по протоколу makeUIView (или даже updateUIView), нет ничего, что могло бы сказать SwiftUI, что нам нужно перерисовать или изменить размер, даже если мы вызываем это в UIKit. Поскольку SwiftUI полагается на состояние, нам нужно использовать свойство State для запуска перерисовки.

Теперь мы увидим нашу LinkPresentation во всей красе:

Неправильно, но я знаю, что это так правильно

На самом деле это лучшее решение между SwiftUI и UIKit… хотя это кажется неправильным. Причина в том, что я разрываюсь между двумя мирами и вынужден осознавать, что двигаться дальше - значит отпускать.

Чтобы быть более конкретным, старая версия UIKit моего мозга ищет протокол, в котором я могу вручную вызвать обновление для моего Representable, как если бы я был в ViewController. Но на самом деле мне нужно принять, что это View, и с ним нужно обращаться как с таковым.

Допустим, LinkPresentation был реализован как SwiftUI View. Я могу представить, что мы обернем LPLinkMetadata как свойствоState. Таким образом, когда обратный вызов fetch устанавливает это State, он служит нашим триггером перерисовки. По сути, мы обязаны использовать привязки в SwiftUI. В Reactive framework мы настраиваем реакцию, которой должен придерживаться наш пользовательский интерфейс.

Реальность такова, что присоединение свойства State к нашему Representative фактически является необходимым финальным шагом в правильном представлении UIView.

Не могу выйти из U (IKit)

UIKit никогда не исчезнет. Я сказал это. Разработчики-ветераны могут вздохнуть с облегчением, а новички в этом квартале могут пыхтеть и пыхтеть, сколько захотят.

Прежде всего, я видел приложения, которые до сих пор используют XIB в производстве. Затем есть безумно сложные и впечатляющие UIView, написанные на UIKit (как в коде, а не в раскадровке). И, наконец, существует огромное количество пакетов / модулей пользовательского интерфейса, которые уже написаны и получены в открытом доступе.

Да, со временем появятся новые приложения, новые пакеты и те, кто займется конверсией. Но любой, кто думает, что SwiftUI полностью сотрет UIKit из App Store, очень взволнован. И я понял, я люблю SwiftUI. Я хочу любить это больше. Нам просто нужно дать ему время вырасти.