Связь между контроллерами вида

Question

Учитывая раздел приложения, в котором есть UINavigationController и 2 уровня UITableViews (то есть, строка выбрана на корневом контроллере, который подталкивает второй контроллер к стеку навигации) У меня есть следующие вопросы:

1) Существует объект User, который требуется обоими контроллерами. Каков наилучший способ связи между двумя контроллерами? Я видел пост на этом сайте, в котором упоминается зависимости инъекции и корневой контроллер может передать объект пользователя на второй контроллер уровня по:

@implementation SecondLevelViewController 

-(void) initWithUser: (User *) user { 
    // myUser is an instance variable 
    myUser = user; 
    [myUser retain]; 
} 

В этом примере второй контроллер, казался бы сохранить пользователь тогда как я видел другие источники (например, курс развития iPhone в Стэнфорде), которые выступают за то, что Пользователь просто назначается и не сохраняется в этой ситуации (свободная связь).

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

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

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

Благодарим за любые ответы, поскольку я пытаюсь правильно разработать вещи, а не взламывать их вместе.

Answer 1

1) «Каков наилучший способ связи между контроллерами?»

Нет ни одного «наилучшего» способа. Вы можете, конечно, передать объект модели в контроллер представления при инициализации. В этом случае контроллер обычно должен сохранять модель. Переход с делегатом является хорошим вариантом, если вы пишете класс контроллера общего вида с упором на повторное использование (например, UITableViewController).

2) «Я видел примеры, когда контроллер корневого (в указанном выше устройстве) имеет множество экземплярам контроллеров второго уровня. Это нормально в профессиональном применении»

Во-первых, вы должны ограничить свои сообщения на Так к одному вопросу за сообщение. Эффект памяти самого контроллера представления обычно довольно низок. Для его переменных экземпляра требуется всего несколько сотен байтов. Секция, требующая большого объема памяти, - это сами представления. Механизм загрузки и разгрузки UIViewController позаботится о необходимости выгрузить интенсивный объем памяти, когда это необходимо (например, если оно получит предупреждение о памяти, а представление в настоящее время не отображается на экране). До тех пор, пока вы правильно реализуете viewDidLoad, viewDidUnload и didReceiveMemoryWarning, я бы не стал слишком беспокоиться о потреблении памяти массивом контроллеров представлений.

UITabBarController также содержит массив субконтроллеров, поэтому нет ничего плохого в этом. Однако вам следует избегать того, чтобы один контроллер удерживал целую иерархию субконтроллеров (т. Е. Не только второго уровня, но и третьего уровня и т. Д.): Не столько из-за проблем с памятью, сколько во избежание ненужной связи.

Answer 2

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

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

Таким образом, вы держите свои контроллеры раздельными.