Хороший подход - использовать делегатов.Это позволяет одному представлению вызывать обратный вызов, предоставленный другим.В этом случае детальный вид опирается на существующий мастер, поэтому его обратный вызов вполне подойдет.Я не позволю им иметь прямые ссылки друг на друга и читать данные друг друга напрямую.
Что именно делегат делает в проекте xcode ios?
Вот учебник с UISplitViewController, который делает это (делегирование между master / detail):
http://www.raywenderlich.com/1040/ipad-for-iphone-developers-101-uisplitview-tutorial
В частности, этот раздел:
Соединение левого с правым
Время играть в сваха и перехватить эти дваСтороны вместе.
Существует множество различных стратегий для достижения наилучших результатов.В шаблоне приложения Split View они дают левому контроллеру представления указатель на правый контроллер представления, а левый контроллер представления устанавливает свойство на правом контроллере представления, когда выбирается строка.Правильный контроллер представления переопределяет свойство, чтобы обновить представление при обновлении свойства.Это прекрасно работает, но мы собираемся следовать подходу, предложенному здесь в ссылке на класс UISplitViewController, - использовать делегаты.Основная идея заключается в том, что мы собираемся определить протокол с одним методом - selectedBotChanged. Наша правая сторона будет реализовывать этот метод, а левая будет принимать делегата от кого-то, кто хочет знать об этом.
Другой подход заключается в том, чтобы иметь общую модель - что-то вроде одиночного пакета с уведомлениями для запуска различных представлений для обновления самих себя на основе данных из уведомления или запроса модели в ответ на изменения модели.Иногда это лучше в приложении с множеством представлений, которые не полагаются друг на друга и просто раздувают данные различными способами (в данном случае это не так - подробное представление опирается на существующий мастер, поэтому делегат в порядке).