UIView & UIViewControllers desing pattern

Question

Правильно ли, когда ViewController создает другой ViewController внутри своих методов (скажем, viewDidLoad или viewWillAppear)?

В моем случае - у меня есть вид A, который содержит несколько других представлений - B и C, которые довольно сложны сами по себе, поэтому для них были разработаны специальные контроллеры vcB и vcC, и эти контроллеры представлений создаются внутри vcA вид контроллера A.

Это нормально? Что, если, например, vcA устанавливает себя как делегат для vcB. Это означает, что vcB сохранит vcA. В этом случае, чтобы правильно выпустить все объекты, нам нужно где-то установить делегат vcB в nil, но для чего это хороший момент? viewWillDisappear:, viewDidDisappear: или smth. еще?

Я уверен, что это не единственный случай, когда возникают проблемы, поэтому я ищу ваши мнения о том, как правильно спроектировать эти взаимодействия между контроллерами представлений.

Answer 1

Я был свидетелем догматической приверженности идеи что одновременно должен работать только один контроллер вида. Что касается меня, я склоняюсь к использованию нескольких контроллеров одновременно, если он упрощает общий дизайн (уменьшает сложность) и упрощает управление проектами. Как вы можете прочитать в recent response that I posted, мне кажется, что Apple движется в одном направлении, предоставляя поддержку настраиваемых контроллеров представления контента, которые позволяют одновременно управлять несколькими контроллерами представлений.

Блог Джона Уильямса стоит прочитать, просто чтобы быть в курсе того, с чем вам придется иметь дело. Но, честно говоря, у меня не было проблем, противоречащих его советам. (Эта должность составляет около года.)

Ключевой рулон контроллера вида предназначен для хранения методов делегата вида, которым он управляет. На самом деле все равно, какой объект выступает в качестве его делегата. Поэтому, если вам нужен дизайн, который более гармоничен с точкой зрения VC с одним VC, вы можете поместить методы делегата в подклассовый NSObject и не называть его контроллером представления. Скорее всего, вам придется создать некоторые из методов, которые UIViewController уже имеет в нем. Но тогда вам не нужно называть это контроллером вида. Я просто подклассифицирую UIViewCcontroller.

Answer 2

Как правило, вам не нужны отдельные контроллеры представлений для подсмотров другого контроллера. Это не то, как планировщики представлений были разработаны для работы.

навигации и панель вкладок контроллеры компании Apple сделать это, но они чудовищно сложными и нестандартным (который, по-видимому, почему вы не разрешили подкласс их.)