Заполнение иерархии TableViews из CoreData - я должен полагаться на NSFetchedResultsController

Question

В настоящее время я занимаюсь разработкой iPhone для iOS 4.2.

Мне интересно, как лучше всего заполнить набор TableViews при работе с древовидными объектами модели. Каждый уровень имеет отношение один ко многим с предметами под ним.

Вот простой пример того типа данных, с которыми я имею дело:

Журнал [имеет много] выпусков [имеет много] статей

Я хочу создать TableView со списком журналов. Нажатие на ячейку создаст список проблем. При нажатии на проблемную ячейку появится список статей.

Мне кажется, что простой способ сделать это - создать контроллер корневого представления с выбранным NSSet журналов. При касании одной ячейки журнала контроллер создает новый IssueViewController и передает его selectedMagazine.issues. Теперь в IssueViewController, при касании ячейки проблемы, статьи NSSet соответствующего выпуска передаются в новый ArticleTableViewController.

Мне интересно следующее ...

• Есть ли консенсус по поводу "наилучшего" способа получения данных? Обход графов объектов из корневого узла и использование NSFetchedResultsController?
• Будут ли когда-нибудь Core Data выгружать что-то (скажем, проблему) из набора родительского журнала, если к этой проблеме некоторое время не обращались? Или больше вещей будет загромождать память, так как к узлу объекта обращается больше узлов?

Я просмотрел здесь немало, но не видел ничего, что вполне отвечало бы на мой вопрос. Заранее спасибо.

Answer 1

Я предпочитаю использовать NSFetchedResultsController при использовании этих типов детализации интерфейсов.Кривая обучения немного крутая, но она предоставляет вам множество функциональных возможностей и контроля, особенно при использовании шаблонов приложений, предоставляемых xCode, которые вам обычно приходится кодировать самостоятельно.т. е. в настройке NSFetchedResultsController вы можете установить размер пакета выборки (полезно для настройки производительности), разделы (оптимизация пользовательского интерфейса), дескрипторы сортировки и т. д. Где, как будто вы идете по маршруту NSSet, вам придется много кода вручнуюо том, что NSFetchedResultsController уже предоставляет вам.

Я спрашивал на форумах Apple Dev, есть ли лучшие рекомендации о том, когда использовать NSSet или NSArray v. NSFetchedResultsController, и ответ от гуру Apple таков:для вас и вашей реализации.Проработав несколько приложений за последние пару лет, я понимаю, откуда они берутся.Это действительно зависит от того, что вам нужно для приложения и сколько времени вы хотите потратить на изучение входов и выходов NSFetchedResultsController.

Answer 2

Я не уверен, какой программный инструмент или язык программирования вы используете (ABAP / SAP ???), но у меня есть работа с различными инструментами и иерархическими структурами, и это то, что я изучаю.

Во-первых, пропустите соединение визуального управления / базы данных и подумайте о модели данных; лучше использовать деревья, чем графики.

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

Третье.Не пытайтесь загружать / заполнять элементы управления всей этой иерархической информацией, делайте это постепенно.

Например, загружайте узлы первого уровня элемента управления древовидной структуры только с вашими "проблемами".Позже, добавьте кнопку, которая загружает «статьи» выбранного выпуска / триода.

Другой способ - это создать форму с сеткой со всеми «проблемами», добавьте кнопку, которая открывает новую форму и сетку.с «статьями», которые относятся к конкретной выбранной строке «выпуск» и ячейке.

Приветствия.