Понимание жизненного цикла UIViewController и передачи переменных в iOS в Раскадровках

Question

Я пытался понять, что происходит в UIViewController-> UIView при загрузке из Interface Builder или Storyboards.

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

В раскадровках, использующих контроллер навигации, у меня есть представление таблицы, загруженное элементом CoreData, и один элемент передается как NSManagedObjectID на следующий контроллер через @property в методе segue для отображенияподробный вид.На принимающем контроллере я делаю проверку существования и при необходимости восстанавливаю весь объект.

На этом этапе возникает вопрос, где лучшее место для размещения и обработки этой логики?Я пришел из истории Java EE, где контроллер называется сервлетом, и сервлет по соображениям производительности может быть инициализирован один раз и совместно использоваться многими пользователями (с помощью Thread Pool) и поэтому не рекомендуется (опаснее более уместно) иметьпеременная экземпляра.Просто потому, что @property является переменной экземпляра, и я не хочу попадать в тот же механизм, мой UIViewController создается один раз, а объект CoreData остается тем же в случае контроллера представления.

Answer 1

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