Best practice regarding display of many similar items in a lengthy view
Best practice regarding display of many similar items in a lengthy view
- Subject: Best practice regarding display of many similar items in a lengthy view
- From: Stuart Malin <email@hidden>
- Date: Thu, 23 Apr 2009 08:41:53 -1000
I am building an app that displays a list of "composite" items. By
composite I mean that each item has multiple clickable icons, images,
and multiple bits of text. In my first implementation, I modeled these
items with a Nib containing a custom NSView and a variety of IB
installed sub views (NSImageView, NSTextView, NSButton). Because the
user can apply filters to the list, and so the visible subviews would
need to be managed, I made inquiry a couple of weeks ago (http://www.cocoabuilder.com/archive/message/cocoa/2009/4/2/233579
) regarding the best way to handle this (add/remove subviews versus
show/hide). I was advised that my approach was a conceptual error and
that I should be using cells. I didn't have any experience with cells,
and so was hesitant, but since have been rebuilding new functionality
using a common custom cell that is used in by NSTableView to render a
column (only one column). I have been studying Apple's PhotoSearch
example to learn how this is done, and how to handle NSrackingArea
entities, because my items can each have many tracking areas. I'm
seeking confirmation that using a custom cell to "stamp out" items is
in fact the better approach than having hundreds of views each with a
variety of subviews.
1) Because Tracking Areas must be associated with a view, all of the
tracking areas (which can be hundreds) are being attached to the table
view. Will this be a problem? In my original approach, there were only
a handful of tracking areas associated with each view.
2) NSTableView seems (to me) to be causing a lot of repeated
calculations to be done. For instance, because my items can vary in
height, my table view delegate implements -tableView:heightOfRow: In
this method I have to layout all the text against the current column
width to determine the item's height. This method is called
frequently. Sure, I guess I should be caching the result for a given
column width... Anyway, it just seems to me that the table view
approach is causing lots of calculations that my view-based approach
didn't (they were sized once, and again only when changed).
3) Is there another approach besides an NSTableView that I could be
using to "stamp out" my custom cell on an underlying NSView that is
the documentView of a scrollView? Sure, I know I can calculate
positions, and call the cell to draw, but I suspect I'd run into
myriad details that the table view is already handling, so why re-
invent?
TIA.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden