Последствия плохого программирования: rejectViewController vs popViewController
Я понимаю разницу между dismissViewControllerAnimated:completion: и popViewControllerAnimated:, как описано при переполнении стека, и здесь:
-dismissViewControllerAnimated:completion: используется метод отклонения UIViewController, который был представлен методом: -presentViewController:animated:completion:.
-popViewControllerAnimated: используется метод UINavigationController показанный методом -pushViewController:animated для UINavigationController.
Недавно я ошибся в своем приложении, где я использовал [self dismissViewControllerAnimated:completion:], чтобы отклонить VC, который был представлен нажатием встроенного приложения для навигации. Я французский жареный, когда я должен был пицца. Я не ошибся, потому что все работает нормально, и мой VC был освобожден, как и ожидалось.
Мой вопрос: Каковы последствия смешивания этих двух методов?
Ответы
Ответ 1
-presentViewController:animated:completion: и -pushViewController:animated: означают разные вещи. Первый говорит: "Представьте этот другой контроллер представления, чтобы заменить себя". Последний говорит: "Покажите этот другой контроллер представления внутри себя, как часть списка, который вы контролируете".
Итак, о том, кто, как считается, отвечает за дисплей после перехода. В первом случае навигационный контроллер передает управление. В последнем он сохраняет контроль.
Первая функциональность предоставляется UIViewController. Последнее относится к UINavigationController.
Поскольку два действия совершенно разные, противоположные действия являются отдельными. Контроллеры навигации могут поймать dismissViewController:... и проверить, как был указан именованный контроллер, разветвляясь либо в суперкласс, либо в pop..., но объединение задач было бы неприемлемым с точки зрения дизайна и обслуживания.
Поскольку навигационный контроллер не обещает сопоставить одну вещь с другой, а UIViewController не обещает какого-либо конкретного поведения, если контроллер, который вы передаете, ранее не был представлен, я думаю, что буквальный ответ на ваш вопрос заключается в следующем: последствием смешивания этих двух вещей является поведение undefined.
Ответ 2
Я не уверен, могу ли я объяснить это лучше всего, чем хотелось бы, но позвольте мне попробовать.
Сейчас я работаю над приложением на основе табуляции, и каждая вкладка имеет свой собственный контроллер навигации. Для боковых функций у меня есть barbuttonitem на ветке navbar до модального вида (и в некоторых случаях модальный для нового навигационного контроллера для управления стоп-кадрами для определенного пути функции.
Я вызову rejectViewController в корневом представлении любого контроллера навигации, который я запускаю из другого в качестве модального. (Надеюсь, это имеет смысл.)
Возможно, это лучше:
Контроллер представления представления отвечает за отклонение представленного контроллера представления. Если вы вызываете этот метод на представленном контроллере представления, он автоматически пересылает сообщение в контроллер представления.
Если вы последовательно представляете несколько контроллеров представлений, создавая стек представленных контроллеров представлений, вызов этого метода на контроллере представления ниже в стеке отклоняет его непосредственный контроллер детского представления и все контроллеры представлений над этим дочерним элементом на стек. Когда это происходит, только верхняя часть обзора отклоняется анимированным образом; любые контроллеры промежуточного вида просто удаляются из стека. Верхний вид отклоняется с использованием модального стиля перехода, который может отличаться от стилей, используемых другими диспетчерами представлений ниже в стеке.
Нажмите для навигации на основе навигации, и при необходимости используйте popViewController. Модифицируйте все, что отходит от навигации, и в случае необходимости используйте rejectViewController.
