Два views для обработки поворота

Добрый день!

Решил потренировать вариант обработки поворота устройства, путем создания двух Views - для каждой из ориентаций.
Допустим, у меня на экране есть кнопка и текстовое поле, в которое выводится некий хеллоуворлд при нажатии на кнопку.
При создании второго landscape View, и размещении на нем компонентов, соответственно, они не будут иметь никакой связи с кнопкой и текстовым полем из View портретной ориентации.
Привязать одно событие клика для обеих кнопок из двух View проблем не вызвало. А, вот, теперь возникает вопрос:
Задать один reference для двух объектов, понятное дело, нельзя. Так что, получается, при нажатии на кнопку мне надо проверять - какая сейчас ориентация экрана, и обращаться, соответственно,к текстовому полю из View портретной, или ландшафтной ориентации?
Что-то подсказывает мне, что есть более красивое решение. Можете мне что-то посоветовать?

Спасибо.

0

воспользуйтесь MVP паттерном
мы так делаем для разных вьюшек на айпаде и айфоне, сохраняя общую логику

Presenter хранит в себе бизнесс-логику
View - это протокол, который описывает общий интерфейс для вьюшек, так же туда будет входить, воможно, xib и ViewController, который строит вьюшку программно и вызывает presenter в нужных местах
ну и Model - она и в Африке модель

Presenter тоже неплохо бы организовать с помошью протокола, а конкретный презентер пусть его имплементирует

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

p.s. конечно можете попробовать посмотреть ReactiveCocoa и MVVM, но лучше остановитесь на более простом (первом) варианте

1

Спасибо, наконец-то у меня есть повод нырнуть в эту тему.
Все хотел заняться паттернами, и, вот, есть причина))

0

Vorona, а какая разница между MVC и MVP? Или это синонимы?

0

ну насколько я понимаю, в MVP у вьюхи есть интерфейс, через который она делегирует действия презентеру
например кликнули на кнопку "Save", вьюха отреагировала и вызывала у презентера метод например "onSave", тот что-то там сделал и сказал вьюхе что нужно показать
такой подход позволяет мокать вьюху в юнит-тестах, что делает тестирование проще, и вообще просто заменять вьюхи, сохраняя одну и ту же логику

а вот в iOS понятие MVC немного странное, у нас есть ViewController, который делает все, и интерфейс строит напрямую и с моделью общается и выполняет какую-то бизнес-логику, хотя в идеале он просто должен получать от вьюхи сообщения, что-то делать и возвращать ей результат

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

на самом деле я и сам немного плаваю в этих отличиях, но знаю что в iOS MVC не тот, который в идеале бывает, потому его стоит заменить на MVP для сохранения логики и вынесения вьюхи в отдельное место

1

В общем, как я и предполагал, это все-таки синонимы. Просто Apple не особо строго следует своим же принципам. Недавно упоминавшийся UITableViewController - отличная иллюстрация этого.

0

нуу они не совсем синонимы хотя очень и очень похожи, а Apple – да, хотя в Андроид такая же ситуация, тут скорее среда мобильной разработки больше имеет значение, даже на WindowsPhone, если не ошибаюсь, используется MVVM, по крайней мере так было в WPF.NET, откуда многое перенялось в ВП7

0