Вопрос стиля: вы устанавливаете свой контроллер nav для всех дочерних контроллеров представления, даже если они не являются представлением верхнего уровня, которое находится в стеке nav?

Question

Допустим, у вас есть контроллер представления вкладок в стеке просмотра контроллера навигации.(Ради аргумента.) Ваш контроллер вкладок имеет массив контроллеров представления для каждого из своих представлений вкладки.Navigation Controller вашего контроллера вкладок явно настроен на контроллер Nav (поскольку его представление находится в стеке).

Но вы бы установили навигационный контроллер для каждого из ваших вкладок, чтобы он указывал на контроллер Nav?Их представления на самом деле не находятся в стеке навигации (они являются вложенными представлениями к представлению с вкладками), но им необходимо иметь возможность поместить представление в указанный стек.Это плохая идея?Должен ли я сделать это, но использовать другую переменную экземпляра?

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

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

Answer 1

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

Что касается сохранения указателей между представлениями и контроллерами, не путайте иерархию представлений со стеком контроллера представлений, они связаны только ортогонально в отношении стека ваших контроллеров представлений. У их контроллеров представлений есть естественное "владение" представлениями, и вам не нужно самим манипулировать этими указателями, которые естественно выпадают из загрузки и создания представлений, а также вызовов API управления стеками контроллеров.