On Aug 8, 2010, at 8:48 AM, Ignacio Enriquez wrote: > Keary: > >>> I have a recursive structure where there are folders and files. >>> Folders can contain various folders and/or files. (File entity has a >>> boolean "isDirectory" flag) >>> >>> Is easy to show the highest (upper) level data in an UITableView but I >>> am not sure how to implement the UITableView datasource for next >>> levels. >>> (The structure was discussed further here: >>> http://www.cocoabuilder.com/archive/cocoa/291457-coredata-warning-file-children-to-many-relationship-does-not-have-an-inverse.html) >> >> The structure as expressed here is inherently flawed, and will likely break >> down completely at the third tier depth. You need an intermediary entity >> that maintains inks between item and enclosing "folder". > > Could you point what part is exactly inherently flawed? And if > possible, how can I correct it?
This is actually probably not an issue, as I forget that Core Data will handle many-to-many properly, as long as you specify the relationships properly, and are targeting 10.5 or higher (or not using a sqlite store, in your specific case). >>> A simple approach would be to get the objects of the relationship of >>> the object at a particular cell and pass this objects set to the new >>> UITableView as its datasource. >>> But I am not sure this is the best approach, specially when the user >>> goes deeper in a big structure (ie.:go to >>> folder>folder>folder>folder>folder>file) is it? >>> (I fell like it would be loosing some CoreData merits like: batchSize, >>> maybe sorting, etc.) >> >> The only drawback I can see with this approach is memory usage. As long as >> you maintain the "state" of each level as you drill down, you could instead >> use an NSFecthedResultsController for each level. > > How can I create a NSFecthedResultsController for each level ? It is not necessary to create one for each level. Each level probably has the same UI, but you may want a UINavigationController, in which case nib instantiation is probably easier. In this case, I would have just two view controllers, one root and one non-root, and update the non-root as part of the drill-down. The main controller could maintain state (or use a custom UINavigationController), which minimally is the item "name" and whatever additional may be required to create the fetch predicates. Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
