Populating a hierarchy of TableViews from CoreData - Should I rely on an NSFetchedResultsController

I'm currently developing on the iPhone targeting iOS 4.2.

I'm wondering what the best way to populate a set of TableViews is when dealing with tree like model objects. Each level has a one-to-many relationship with the items b开发者_如何学Goelow it.

Here's a simple example of the sort of data I'm dealing with:

Magzine [has many] issues [has many] articles

I want to create a TableView with a list of Magazines. Tapping a cell will produce a list of issues. Tapping an issue cell will produce a list of articles.

It seems to me that the simple way of doing this would be to create a root view controller with a fetched NSSet of magazines. When one magazine cell is tapped, the controller creates a new IssueViewController and passes it selectedMagazine.issues. Now in the IssueViewController, when an issue cell is tapped, the corresponding issue's articles NSSet is passed to a new ArticleTableViewController.

What I'm wondering is the following...

• Is there a consensus on the "best" way to go about getting the data? Traversing Object Graphs from a root node vs using NSFetchedResultsController?
• Will Core Data ever unload something (say an issue) from its parent magazine's set if that issue isn't accessed for a while? Or will more stuff be cluttering up memory as more nodes on the object graph are accessed?

I've done a fair amount of browsing on here, but haven't seen anything that quite answers my question. Thanks in advance.

I prefer the use of NSFetchedResultsController when using these drill down type of interfaces. The learning curve is a little steep, but it provides you with a lot of functionality and control especially when using the app templates provided by xCode that you would normally have to code yourself. i.e. in the setup of the NSFetchedResultsController you can set your fetch batch size (helpful for performance tuning), sections (UI optimization), sort descriptors, etc. Where as if you are going the NSSet route, you will have to hand code a lot of what the NSFetchedResultsController already provides you.

I've asked on the Apple Dev forums if there was a best practices on when to use NSSet or NSArray v. NSFetchedResultsController and the response from Apple gurus is that it is up to you and your implementation. After working on several apps over the last couple of years, I understand where they are coming from now. It really depends on what you need for the app and how much time you want to spend learning the ins and outs of NSFetchedResultsController.

I'm not sure what software tool or programming language are you using, (ABAP/SAP ???), but I have work with different tools and hierarchical structures, and this is what I have learn.

First, skip the visual control / database connection, and think about the data model, altought trees are better to use than graphs.

Second, data stored in different tables and represented hierarchical, is difficult to use, and manage.

Third. Don't try to load/populate controls with all these hierarchical information, do it incrementally.

Example, load a treeview control first level nodes with your "issues" only. Latter, add a button that loads the "articles" of the selected issue/treenode.

Another way, is to have a form with grid with all "issues", add a button that opens a new form and grid with the "articles" that relate to the specific selected "issue" row and cell.

Cheers.