Где мне следует устанавливать ограничения автоматического размещения при программном создании представлений

Я вижу разные примеры, когда устанавливаются ограничения. Некоторые устанавливают их в viewDidLoad/ loadView(после добавления подпредставления). Другие устанавливают их в методе updateViewConstraints, который вызывается viewDidAppear.

Когда я пытаюсь установить ограничения, updateViewContraintsможет возникнуть скачок в макете, например небольшая задержка перед появлением представления. Кроме того , если я использую этот метод, я должен очистить существующие ограничения первого т.е. [self.view [removeConstraints:self.view.constraints]?

Я установил свои ограничения в viewDidLoad/ loadView(я нацелен на iOS> = 6). updateViewConstraintsполезен для изменения значений ограничений, например, если какое-то ограничение зависит от ориентации экрана (я знаю, это плохая практика), вы можете изменить его constantв этом методе.

Добавление ограничений viewDidLoadпоказано во время сеанса «Введение в автоматический макет для iOS и OS X» (WWDC 2012), начиная с 39:22. Я думаю, что это одна из тех вещей, о которых говорят на лекциях, но не отражаются в документации.

ОБНОВЛЕНИЕ: я заметил упоминание о настройке ограничений в управлении ресурсами в контроллерах представления :

Если вы предпочитаете создавать представления программно, вместо использования раскадровки, вы делаете это путем переопределения loadView метода контроллера представления . Ваша реализация этого метода должна делать следующее:

(...)

3. Если вы используете автоматический макет, назначьте достаточные ограничения для каждого из только что созданных представлений, чтобы контролировать положение и размер ваших представлений . В противном случае, реализовать viewWillLayoutSubviewsи viewDidLayoutSubviewsметоды для настройки каркасов подвидов в иерархии представлений. См. «Изменение размера представлений контроллера представления».

UPDATE 2 : Во время WWDC 2015 Apple , дал новое объяснение о updateConstraintsи updateViewConstraintsрекомендуемое использование:

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

В идеале вся ваша начальная установка ограничений должна происходить внутри Interface Builder.

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

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

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

Итак, когда вам нужно использовать ограничения обновления?

Что ж, все сводится к производительности.

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

Оказывается, изменение ограничения внутри ограничений обновления на самом деле происходит быстрее, чем изменение ограничения в другое время.

Причина в том, что движок может обрабатывать все изменения ограничений, которые происходят в этом проходе, как пакет.

Я рекомендую создать BOOL и установить их в -updateConstraintsUIView (или -updateViewConstraintsдля UIViewController).

-[UIView updateConstraints]: (яблочные документы)

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

Оба -updateConstraintsи -updateViewConstraintsмогут вызываться несколько раз в течение жизни представления. (ВызовsetNeedsUpdateConstraints представления вызовет это, например.) В результате вам необходимо убедиться, что вы не создали и не активировали повторяющиеся ограничения - либо с помощью BOOL, чтобы выполнить настройку определенных ограничений только один раз, либо убедившись, что для деактивации / удаления существующих ограничений перед созданием и активацией новых.

Например:

  - (void)updateConstraints {  // for view controllers, use -updateViewConstraints

         if (!_hasLoadedConstraints) {
              _hasLoadedConstraints = YES;
             // create your constraints
         }
         [super updateConstraints];
    }

Приветствую @fresidue в комментариях за указание на то, что в документации Apple рекомендуется позвонить superв качестве последнего шага. Если вы позвоните superперед внесением изменений в некоторые ограничения, вы можете столкнуться с исключительной ситуацией во время выполнения (аварийным завершением).

Это должно быть сделано в ViewDidLoad, согласно видео WWDC от Apple и документации.

Понятия не имею, почему люди рекомендуют updateConstraints. Если вы это сделаете в updateConstraints, вы столкнетесь с проблемами с NSAutoresizingMaskLayoutConstraint с автоматическим изменением размера, потому что ваши представления уже приняли во внимание автоматические маски. Вам нужно будет удалить их в updateConstraints, чтобы заставить работать.

UpdateConstraints должен быть именно для этого, когда вам нужно «обновить» их, внести изменения и т. Д. Из начальной настройки.

Сделайте это в виду, сделал ли метод подвидов макета

override func viewDidLayoutSubviews() {
    super.viewDidLayoutSubviews()
}

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

-(void)updateViewConstraints{

    dispatch_async(dispatch_get_main_queue(), ^{

            //Modify here your Constraint -> Activate the new constraint and deactivate the old one

            self.yourContraintA.active = true;
            self.yourContraintB.active= false;
            //ecc..
           });

    [super updateViewConstraints]; // This must be the last thing that you do here -> if! ->Crash!
}

Вы можете установить их в viewWillLayoutSubviews: тоже:

 override func viewWillLayoutSubviews() {

    if(!wasViewLoaded){
        wasViewLoaded = true

        //update constraint

        //also maybe add a subview            
    }
}

Это сработало для меня:

Swift 4.2

override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)

// Modify your constraints in here

  ...

}

Хотя, честно говоря, не уверен, стоит ли оно того. Кажется, он загружается немного медленнее, чем в viewDidLoad (). Я просто хотел убрать их из последнего, потому что он становится массовым.

Следующий пример - передать любое представление другому классу. создать мое представление из раскадровки

Swift 5.0

    override func viewWillAppear(_ animated: Bool) {
        
      super.viewWillAppear(animated) 
        DispatchQueue.main.async {
            self.abcInstance = ABC(frame: self.myView.frame)
          } 
      }

 

Если вы пропустите DispatchQueue.main.async, потребуется время, чтобы обновить ограничения в viewWillAppear. Создайте myView в раскадровке и задайте ограничения, такие же, как ширина и высота экрана, затем попробуйте распечатать фрейм myView. он даст точное значение в DispatchQueue.main.async или в viewDidAppear, но не даст точного значения в viewWillAppear без DispatchQueue.main.async.