Как я (должен?) Передать контекст между UITableViews при использовании Базовых Данных в навигационном приложении? - PullRequest
1 голос
/ 29 мая 2011

У меня есть приложение на основе навигации, использующее базовые данные и несколько уровней детализации навигации.На последнем уровне навигации я добавляю записи в хранилище управляемых объектов. На каждом уровне навигации я создаю массив контроллеров представления для следующего UITableView.

Мой вопрос касается размещения методов стека базовых данных, которые создают managedObjectContext, managedObjectModel и persistentStoreCoordinator.

Создаю ли я эти методы в контроллере представления самого высокого уровня, который должен извлечь данные из persistentStore и затем передать объект контекста в контроллеры представления более низкого уровня?Мне также нужно передать координатора?

Многие вопросы указывают на то, что эти методы помещаются в делегат приложения, но затем многие ответы говорят: «Не» - помещают их в делегат приложения.Так где же лучшее место для этих методов и какие объекты нужно передать, чтобы все необходимые уровни могли быть извлечены из хранилища данных?

Ответы [ 2 ]

4 голосов
/ 30 мая 2011

Во-первых, некоторые предварительные условия:

Если вы создаете приложение, использующее базовые данные, то вы , скорее всего, столкнетесь с ситуациями, когда вам потребуется иметь более одного контекста управляемого объекта (MOC). Однако вам потребуется один MOC, который будет «жить» на протяжении всего сеанса приложения. Назовите это своим основным MOC (поскольку вы будете получать к нему доступ только из основного потока !!).

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

Чтобы ответить на ваши вопросы:

Я предлагаю, чтобы ваш основной MOC принадлежал AppDelegate, поскольку последний является единственным, который живет до тех пор, пока работает приложение. Вы можете поместить методы для создания / сохранения основного MOC в AppDelegate или делегировать эти задачи служебному классу. Я нахожу второй вариант немного чище, поскольку вы можете использовать этот служебный класс для добавления методов, которые создают другие MOC на лету, или для получения ссылки на основной MOC из любого контроллера в вашем приложении. Таким образом, вы не будете вызывать AppDelegate постоянно.

Также обратите внимание, что если у вас уже есть NSManagedObject в ваших руках, вы можете получить ссылку на MOC, в которой он зарегистрирован, просто позвонив по номеру [yourManagedObject managedObjectContext]. Получив ссылку на MOC, вы можете получить соответствующие ссылки NSPersistentStoreCoordinator и NSManagedObjectModel. (Это ответ на ваш вопрос о «прохождении координатора»: я предпочитаю работать с NSManagedObject s и NSManagedObjectContext, поскольку они находятся на самом верхнем уровне абстракции, а не передают координатор или модель) .

Надеюсь, это поможет!

1 голос
/ 30 мая 2011

Apple помещает стек основных данных в делегат приложения, который работает в большинстве случаев.

Мне кажется, что вы используете базовые данные. Похоже, ваш дизайн приложения просто использует Core Data для сохранения некоторых данных после того, как вы спустились вниз по иерархии представлений, которые заполнены массивами. Хотя вы можете получить эту работу, вы теряете большую часть автоматической функциональности Core Data.

Базовые данные - это не только сохранение данных. Вместо этого это API для создания слоя модели в приложении разработки Model-View-Controller. Таким образом, базовые данные обычно содержат действительные логические «внутренности» приложения. Apple помещает стек в делегат приложения, поскольку предполагается, что базовые данные будут использоваться во всем приложении.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...