Re: Best practice regarding display of many similar items in a lengthy view
Re: Best practice regarding display of many similar items in a lengthy view
- Subject: Re: Best practice regarding display of many similar items in a lengthy view
- From: Graham Cox <email@hidden>
- Date: Fri, 24 Apr 2009 11:17:12 +1000
On 24/04/2009, at 4:41 AM, Stuart Malin wrote:
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?
First off I'd say that when people advise about using "cells", they
may not literally mean an NSCell subclass. Instead it's more likely
that they will just mean the cell concept, where a lightweight object
is called upon to perform some drawing task on behalf of a view. While
this is what NSCell does, it's also very much designed around the
needs of controls, tables, matrixes and so forth. It may be carrying
too much baggage for more general purpose usage.
Regarding your question (3), the problem with using NSTableView is
that it's designed for the specific purpose of drawing tabular data
laid out in rows and columns. Why reinvent? Because it's hard to "de-
invent" its functionality to bend it to some other purpose it's not
suitable for. Sure, you could eventually do it, but it's just so much
easier to come up with a simple view-based scheme of your own that
will be very lightweight and not hampered by all the table
functionality you don't need.
So maybe you should consider defining your own "cell" type class,
subclassing NSObject, that has properties such as its bounding rect
and tracking area (maybe the same thing), and this has a reference to
another object that contains the master image (whatever that might
be). When the view draws, it simply runs through the list of "cells",
and for each one it needs to draw, calls a drawing method of that
cell, which passes its bounds to the master object which draws the
content in that rect. You'll find that this approach is about as
straightforward as you can generally get with views, and it will work
excellently in a scroll view and most importantly will be extremely
simple to design, understand and maintain. The use of a master isn't
even necessary, but such an approach might be good if you are reusing
the same image or drawing code over and over again.
Subclassing built-in classes is not always the best solution to any
problem - sometimes you have to kick out on your own.
--Graham
_______________________________________________
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