I am creating a Source List for my application and I want it structured in a way similar to that of iTunes, with two types of items:
In my iTunes analogy:
(source: perspx.com)
The way I've structured my data so far is as follows:
Group
Core Data entities.SourceListItem
regular Objective-C object so that I can associate each item with a title, icon, child items etcSourceListItem
instances, stored in an array in my controller object.I am unsure of how to amalgamate these two types of item into the Source List, so that the fixed items are at the top and always there and do not change, and the editable items are at the bottom and can be moved around and edited.
These are the ideas I've come up with so far:
Add the fixed items to the Core Data model. This means that I can create an entity to represent Source List items and have my fixed and editable items placed in instances of these. Then these can be bound to the Outline View table column with an Array/Tree Controller. However, this means that I'd have to create a new entity to represent the Source List items, and then sync the Group
s with this. I'd also have to have some way of creating all the fixed items only once, and if something happened to any of the persistent store files then the fixed items would not be displayed.
Merge the fixed items with the group items. Whilst both are stored in separate arrays, this could be done in the controller for my window when the Outline View requests the data (if adopting the NSOutlineViewDataSource
protocol, not bindings). However this means that I'd have to create new SourceListItem
s for each group in the array controller (to associate each with icons and other attributes), store these and then watch the group array controller for changes to remove, add or modify the SourceListItem
instances when changes are made to the groups.
Does anyone have any better ideas on how I can implement this?
I would like my application to be compatible with OS X v10.5 so I'd prefer any solutions that didn't depend on having Snow Leopard installed.
I'm working on an app that has this exact same behavior, and here's how I'm doing it:
I have 5 main entities in my Core Data Model:
AbstractItem
- an abstract Entity that has the attributes common to all items, like name
, weight
, and editable
. Also has two relationships: parent
(to-one relationship to AbstractItem
) and children
(to-many relationship to AbstractItem
, and the inverse of parent
).Group
- concrete child Entity of AbstractItem
.Folder
- concrete child Entity of AbstractItem
. Adds a many-to-many relationship to the basic Item
entity.SmartFolder
- concrete child Entity of Folder
. Adds a binary attribute predicateData
. Overrides Folder
's "items" relationship accessor to return the results of executing a fetch request with the predicate defined by the predicateData
attribute.DefaultFolder
- concrete child Entity of SmartFolder
. Adds a string attribute identifier
.For the "Library" section items, I insert DefaultFolder
objects and give them a unique identifier so I can retrieve them easily and differentiate between them. I also give them an NSPredicate
that corresponds to what Items
they're supposed to show. For example, the "Music" DefaultFolder
would have a predicate to retrieve all Music items, the "Podcasts" DefaultFolder
would have a predicate to retrieve all Podcast items, etc.
The root-level items ("Library", "Shared", "Store", "Genius", etc) are all Group
items with a nil
parent. The groups and Folders that cannot be edited have their editable
attribute set to NO
.
As for actually getting this stuff in your outlineView, you'll have to implement the NSOutlineViewDataSource
and NSOutlineViewDelegate
protocols yourself. There's just too much behavioral complexity here to pump it out through an NSTreeController
. However, in my app, I got all of the behavior in (even drag-and-drop) in under 200 lines of code (so it's not that bad).
Don't inject nonsense into your data set simply to support a view. This not only goes against the MVC design pattern, but adds needless complexity (ie "more potential for bugs") to the single most important part: management of user data.
That said, using Bindings with this particular scenario is what's causing so much friction. Why not eschew Bindings entirely? You're on the right track, I think, using the NSOutlineViewDataSource protocol, but you didn't take it far enough. Instead, rely fully on this (still perfectly valid and in some ways superior) protocol.
You'd essentially trade ease-of-setup (and ease of change notification) for full control over the tree structure.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With