Как можно общаться между контроллерами представления в приложении типа UINavigation?

Question

У меня есть приложение на основе UINavigation, которое собирает информацию на различных экранах и в конечном итоге делает запрос веб-службы, используя все собранные параметры.

Итак, у меня есть контроллеры просмотра A, B, C, D. A получает имя и номер, затем выводит B на экран с некоторой базовой информацией ETC ETC, пока не дойдет до D, где я фактически отключу веб-сервис.

Плохой метод, который я использовал, состоит в том, чтобы дублировать поля класса, начиная с А. Это означает, что если я собираю имя и число, то я делаю эти поля B, которые затем добавляют несколько полей, а затем C имеет поля класса A и B, что кажется плохой практикой программирования.

Что я могу сделать, чтобы получить доступ к полям класса A в классе D? Я получил определенные идеи, но не уверен, насколько они верны.

1). Использовать NSNotification (это перебор?) Если да, то как мне пройти поля? 2). Я просто сохраняю все 5 контроллеров представления и просто получаю информацию в конце? (кажется очень неэффективным)

3). Должен ли я просто создать экземпляр класса NSObject с именем Payload и просто устанавливать его поля каждый раз, когда я отскакиваю от одного контроллера представления к другому? (Если это так, я создаю его в классе A? Что если пользователь перейдет обратно в класс A, получит ли он сброс ETC ETC)

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

Answer 1

В зависимости от ситуации есть несколько подходящих способов.

1. Знакомство Шаблон проектирования MVC

2. Классы не являются хранилищем данных.Если у класса нет интерфейса для взаимодействия с представленным объектом, за исключением средств доступа, вы делаете это неправильно.

3.

У меня есть UINavigationприложение, которое собирает информацию на различных экранах и в конечном итоге делает запрос веб-службы, используя все собранные параметры.

Итак, ваш веб-запрос основан на параметрах, собранных из различных представлений.Почему бы не создать модель указанного запроса?MyRequest или что-то в этом роде :) Или несколько более конкретных вариантов, разделяющих общий родительский класс?Этот генератор хранит логику, собирает данные и параметры по мере продвижения по видам желоба и в конце предоставляет NSUrlRequest для WebView или, возможно, другого типа объекта, который является делегатом NSURLRequest и соответствует протоколам UITableViewDataSource / Delegate, которые будут использоваться для отображения загруженных данных.

Answer 2

Почему бы не использовать одноэлементный объект и передать его?

Преимущества этого метода:

• Есть только один экземпляр которого ссылка передается вокруг между контроллерами представления
• меняет тебя сделать отражаются в следующий раз, когда вы получить доступ к этому объекту из другого вида Контроллер

И чтобы ответить на один из ваших вопросов, NSNotification позволяет нам передавать объекты вместе ...

Вот хороший пример Мэтта Галлоуэя об одноэлементных объектах в iOS. Это то, к чему я всегда обращаюсь:

http://www.galloway.me.uk/tutorials/singleton-classes/

Answer 3

Я бы пошел на 3), и да, вы должны создать его в начале (класс А).

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