UIView & UIViewControllers desing pattern

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Контроллеры навигации и панели вкладок Apple делают это, но они ужасно сложны и нестандартны (вероятно, поэтому вы не можете их подклассовать).