Размотайте Segue и Mutl-Threading

sigmonky спросил: 12 мая 2018 в 05:02 в: ios

Контроллер представлений запускается модально с родительского контроллера представления и затем разматывается к его родительскому элементу, если нажата одна из трех кнопок:

@IBAction func parentSelected(_ sender: UIButton) {
    switch sender.tag {
    case 1:
        parentType = ParentStoryboardId.meetings
    case 2:
        parentType = ParentStoryboardId.accounts
    case 3:
        parentType = ParentStoryboardId.contacts
    default:
        parentType = ParentStoryboardId.accounts
    }
    self.performSegue(withIdentifier: "unwindToNotes", sender: self)
}

Развернутый обработчик segue в родительском VC затем запускает другую таблицу VC со списком записей:

@IBAction func unwindToNotes(sender: UIStoryboardSegue) {
     if let sourceViewController = sender.source as? SelectParentVC {
         DispatchQueue.main.async {
            guard let parentType = sourceViewController.parentType 
             else {
                return
             }
            self.parentSelected = parentType
            self.displayParents(parentType)
            self.selectParentView.isHidden = true
          }
     }
 }

Первоначально я не указывал основную очередь при выполнении всех операций пользовательского интерфейса, вызываемых обработчиком разматывания segue в родительском VC. И просмотр списка, который я пытался вызвать, не отображался, хотя отладка подтвердила, что список VC частично выполнялся.

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


1 ответ

Есть решение
Paulw11 ответил: 12 мая 2018 в 08:39

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

Используя DispatchQueue.main.async, вы вызываете представление контроллера вида происходят на следующей итерации основной runloop, после того как предыдущий контроллер просмотра был уволен.

sigmonky ответил: 13 мая 2018 в 08:52
Благодарю. Этот ответ дает много смысла. Я избавился от развязки и вернулся к использованию метода увольнения по другим причинам. Интересно, что это устранило необходимость указания основного потока для этих операций. Любая идея, почему диспетчер представлений, отклоняющий себя, а не разматывание через segue, устранит необходимость закрытия основного потока?