Реорганизуйте это!
Вместо того, чтобы использовать раскадровку, вы можете… можете. Также избегайте загрузки Massive View Controller!
Сложность: Начинающий | Легко | Нормальный | Испытывающий
Предпосылки:
- Нет, но вам может быть полезно ознакомиться с основными принципами использования игровых площадок.
Возможно, вы даже нашли учебные пособия, которые помогут вам поместить код в нужное место в вашей модели MVC. Они могут даже упомянуть переопределение loadView () для такой задачи, но могут не указывать, где мы помещаем жесты для кнопок и другой код, который просто не может быть выполнен в подклассе UIView.
Общая идея здесь заключается в том, что ограничения (а таких не должно быть в классе контроллера представления. Давайте посмотрим, как это работает, на примере.
Пример
Это будет одно из самых простых приложений, которое вы можете себе представить. Есть одно представление, вы нажимаете кнопку и переходите к следующему представлению. Вот и все. За исключением кнопки для возврата к первому виду. Это будет выглядеть примерно так:
Класс бога
Представьте, что у нас есть довольно простое приложение, в котором нажатие кнопки перемещает один UIViewController на другой.
Код здесь довольно длинный, но смирись (он не слишком сложный!). Вероятно, вы сами сможете создать этот код примерно за 30 секунд. Этот пример создается в коде (а не в раскадровках), а это означает, что будут добавлены некоторые ограничения, и в этом заключается проблема.
Эта проблема? Ограничения не должны быть в UIViewController, они должны быть в UIView
loadView wtf
loadView() существует для создания представления, которым управляет контроллер представления. Это кажется немного… необычным в использовании, если вы привыкли использовать Раскадровки для своих проектов по этой причине.
Если вы используете Interface Builder для создания ваших представлений и инициализации контроллера представления, вы не должны переопределять этот (
loadView()) метод.
Однако в случае этого примера мы можем переопределить loadView (), поскольку именно здесь мы собираемся создавать наши представления.
Реализация
Первый контроллер представления, MyViewController, создает экземпляр представления (которое я творчески назвал ButtonView()). Интересная часть находится в loadView(), потому что действие кнопки должно быть в контроллере представления. Почему? Мы должны представить контроллер представления из контроллера представления, поэтому present(controller, animated: true, completion: nil) должен находиться в контроллере представления. Поэтому мы установили цель и действие buttonDidTap() в экземпляр MyViewController (предпочитая это делегату для контроллера представления и обмена данными).
Аналогичное обоснование имеет свойство DetailViewController, которое дает как аналогичные проблемы, так и аналогичные решения этих проблем.
Заключение
Переопределение loadView() - лучший способ программно создавать представления в Swift.
Вы, конечно, можете разделить свои представления (и действительно должны) в отдельные файлы для рабочих приложений, но я уверен, что вы это уже делаете.
Целью при написании должно быть удобочитаемость и ясность для ваших приложений, и я надеюсь, что это руководство дает вам способ сделать это для ваших контроллеров представлений и представлений при создании приложений Swift.
Контактное лицо в Twitter:
Любые вопросы? Вы можете связаться со мной ЗДЕСЬ
