Разница в иерархии представлений при добавлении дочернего VC в коде или IB

Я заметил что-то довольно странное, когда я добавляю дочерний VC в иерархию представлений в IB, иерархия выглядит так

родительское представление vc
- -представление контейнера
- - - -дочернее представление vc

при добавлении вручную

родительское представление vc
- - дочернее представление vc

Следуя инструкциям Apple в их руководстве, они никогда не говорить о представлении контейнера как о части иерархии, однако в коде на практике, например, когда я пытаюсь вызвать

    - (void) hideContentController: (UIViewController*) content {
   [content willMoveToParentViewController:nil];
   [content.view removeFromSuperview];
   [content removeFromParentViewController];
}

представление контейнера все еще «загрязняет» мою иерархию представлений. Я не понимаю отношения между этим контейнером и моим ребенком VC.

Практический пример в моем коде: я помещаю эти viewControllers в UIStackView, и при попытке удалить UIViewController, который был вставлен с Embed Segue, я остаюсь с фантомным видом. Единственный способ получить доступ к этому представлению — это IBOutlet из раскадровки.

У кого-нибудь есть опыт обработки, замены или удаления ChildViewControllers, добавленных с помощью IB? Или может объясните откуда такая разница и как от нее избавиться?


ios interface-builder uicontainerview
person Yoav Schwartz    schedule 23.11.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я бы сказал, что «представление контейнера», которое вы можете использовать в IB, немного, ну… вводит в заблуждение?

Если вы выберете его на панели библиотеки объектов, вы получите всплывающее окно с информацией, в котором он указан как UIContainerView. Однако, если вы будете искать документацию Apple, этого нигде не будет.

И, как вы, наверное, заметили, если вы соедините его с IBOutlet, он будет установлен как UIView.... и если вы попытаетесь сделать что-то вроде:

UIContainerView *vc;

or

let cv: UIContainerView?

вы получите ошибку «Использование необъявленного типа».

Что делает его «отличным», так это то, как он ведет себя в IB, и автоматическая «загрузка и отображение» его встроенного контроллера дочернего представления. Это очень похоже на Segues... вы можете создавать и "видеть" их в IB; вы можете назначать им свойства; во время выполнения они служат цели / имеют действия; но... вы не можете создать UISegue в коде.

Итак... если вы хотите использовать автоматизацию визуального проектирования и внедрения "контейнерных представлений" в IB, вы должны знать, что оно добавляется как UIView к вашей иерархии представлений, а .view его embedded VC является добавлено как подпредставление для самого себя... и вам нужно будет использовать IBOutlet, чтобы иметь ссылку на него во время выполнения, если вы хотите удалить его (или изменить его размер или изменить любое другое его свойство).

Когда вы видите "только код" реализации контроллеров дочерних представлений, вы, как правило, также видите код для добавления представления дочернего VC в качестве подпредставления "основного" представления (или некоторого другой взгляд). Это просто не похоже на UIContainerView, который вы можете использовать в IB, потому что на него никогда не ссылались таким образом.

Имеет ли это смысл?

person DonMag    schedule 23.11.2017