Ты прав, спасибо за уточнение. Действительно, хотя обычно viewDidLoad() вызывается только один раз в жизненном цикле контроллера, существуют редкие случаи, когда это может произойти снова. Например, при получении системного предупреждения об недостатке памяти система может сделать это или при использовании вьюконтроллера снова, когда вью выгружается и повторно загружается. В этих и других исключительных ситуациях может возникнуть необходимость в повторном выполнении инициализации и настройки вью. В целом, это редкое поведение, но оно имеет место быть.
и по-моему, не совсем правильно обобщать и говорить, что viewDidLoad используется для верстки UI. для проставления констрейнтов - да, но ведь ручной подсчет фреймов нужно делать где-то в районе layoutSubviews. поправьте, если я не прав.
@@anemesis9635 layoutSubviews является часть жизненного цикла view, но не viewController’a. В контексте vc этот метод вызывается для вью, которые управляются контроллером, а не для него самого. Поэтому хоть этот метод и важен для расположения вью, он не имеет прямого отношения в жизненному циклу вью контроллера
@@anemesis9635 согласен полностью по поводу замечания касательно "верстки UI". Сам автор потом говорит про другие методы, что размеры для subviews еще не просчитаны. О какой вёрстке UI тогда может идти речь?
5:55 "в методе loadView корневая view равна nil и мы можем подменить её на нашу кастомную". А в каком моменте дефолтный view становится не nil, если ничего не подменять и ничего не трогать? В методе viewDidLoad? Ну если так, то какой смысл подменять на кастомную view, если она почти сразу же перезапишется на дефолтную view от apple, так как это заложено жизненным циклом? Зачем тогда что-то подменять? Ну либо подменять view нужно в методе viewDidLoad, а не loadView, как говорит автор? Тема не раскрыта целиком и собеседующий просто завалит наводящими вопросами. На собеседовании такие поверхностные ответы не прокатят
Разобрался самостоятельно. Если в методе loadView не вызвать super, то view не настроится и будет nil, а view controller будет метаться и вызывать метод loadView несколько раз. А если еще попытаться обратиться ко view, то программа начинает сходить с ума и вызывать метод loadView бесконечно. Поведение view controller'а очень странное если у view нет значения. Если не трогать свойство view, то view controller как-то умудряется жить и вызывать другие методы своего жизненного цикла. Но если хоть где-то дёрнуть свойство view, то это конец работе программы.
Божественно
Автор, большая умница! Спасибо!
Именно то, что искал! Спасибо тебе большое за твой труд! Очень подробное и детальное объяснение темы! Ценю! ✊🏻😊
deinit вызывается перед деаллокацией а не после 5:00
Эти видео - лучшие!
Большое спасибо за труд!!!
отличное объяснение. спасибо большое!
Спасибо большое за прекрасное видео! Если в планах выпускать еще?)
Жаль 2 лайка нельзя поставить)
Лучший на ютубе
Лучшее пояснение на данную тему 🆒
Спасибо большое, очень помогло данное видео
Спасибо большое!!!
Супер! Спасибо
Жаль не успели рассказать про новый метод isappearing
кайф! будет еще?
будет)
хороший видос)
только viewDidLoad может вызваться не один раз
и да верстают же еще и на фреймах, и делают это позже него
Ты прав, спасибо за уточнение. Действительно, хотя обычно viewDidLoad() вызывается только один раз в жизненном цикле контроллера, существуют редкие случаи, когда это может произойти снова. Например, при получении системного предупреждения об недостатке памяти система может сделать это или при использовании вьюконтроллера снова, когда вью выгружается и повторно загружается. В этих и других исключительных ситуациях может возникнуть необходимость в повторном выполнении инициализации и настройки вью. В целом, это редкое поведение, но оно имеет место быть.
если что то принтануть можно так print(\(#function) - \(Self.self))
а почему layoutSubviews не входит в цикл?
и по-моему, не совсем правильно обобщать и говорить, что viewDidLoad используется для верстки UI. для проставления констрейнтов - да, но ведь ручной подсчет фреймов нужно делать где-то в районе layoutSubviews. поправьте, если я не прав.
@@anemesis9635 layoutSubviews является часть жизненного цикла view, но не viewController’a.
В контексте vc этот метод вызывается для вью, которые управляются контроллером, а не для него самого. Поэтому хоть этот метод и важен для расположения вью, он не имеет прямого отношения в жизненному циклу вью контроллера
@@MagicSwift спасибо большое!
@@anemesis9635 согласен полностью по поводу замечания касательно "верстки UI". Сам автор потом говорит про другие методы, что размеры для subviews еще не просчитаны. О какой вёрстке UI тогда может идти речь?
0:30 на картинке вообще 4 метода, а не 6
5:55 "в методе loadView корневая view равна nil и мы можем подменить её на нашу кастомную". А в каком моменте дефолтный view становится не nil, если ничего не подменять и ничего не трогать? В методе viewDidLoad? Ну если так, то какой смысл подменять на кастомную view, если она почти сразу же перезапишется на дефолтную view от apple, так как это заложено жизненным циклом? Зачем тогда что-то подменять?
Ну либо подменять view нужно в методе viewDidLoad, а не loadView, как говорит автор?
Тема не раскрыта целиком и собеседующий просто завалит наводящими вопросами. На собеседовании такие поверхностные ответы не прокатят
Разобрался самостоятельно. Если в методе loadView не вызвать super, то view не настроится и будет nil, а view controller будет метаться и вызывать метод loadView несколько раз. А если еще попытаться обратиться ко view, то программа начинает сходить с ума и вызывать метод loadView бесконечно.
Поведение view controller'а очень странное если у view нет значения. Если не трогать свойство view, то view controller как-то умудряется жить и вызывать другие методы своего жизненного цикла. Но если хоть где-то дёрнуть свойство view, то это конец работе программы.
Ты умеешь удивить
viewIsAppearing - новый метод. Между viewWillAppear и viewDidAppear
Ты смог разобраться для чего он нужен, если у нас есть viewDidLayoutSubviews? Я вот пока что не понимаю