Re: Display csv in a tableView with bindings
Re: Display csv in a tableView with bindings
- Subject: Re: Display csv in a tableView with bindings
- From: Aaron Burghardt <email@hidden>
- Date: Sun, 26 Jul 2009 15:52:47 -0400
On Jul 26, 2009, at 10:53 AM, I. Savant wrote:
On Jul 26, 2009, at 6:32 AM, Aaron Burghardt wrote:
Neither, you want an array of dictionaries where each row of CSV is
a dictionary in which the values keyed to column names and each row
of CSV is one dictionary object in the array.
This is a bit more complicated than that, actually.
There's a bit of a catch-22 here. On the one hand, you have a
performance consideration. On the other, you have an ease-of-
programming consideration. Using NSDictionary is easier, but for
moderately-sized files it is noticeably slow, for large files, it's
unusably so.
Well, you are correct that I assumed that it was a beginner question
and that the OP was working with a fixed number of known columns (a
reasonable assumption, I suppose, since he wants to use bindings). He
could start with dictionaries, then switch to a custom class for rows
if the performance using dictionaries was inadequate.
If you go the dictionary route, using the keys to identify the
"fields" in each row, you're storing *way* more than just the
individual field contents. You're storing a copy of your field
identifier keys for every field, for every row. Best-case scenario,
you're storing a pointer to some object that represents the "column"
to which the fields belong, but this defeats the ease-of-use with
bindings as you need string keys.
Not necessarily. If the keys are NSStrings, then they are copied when
added to the dictionary, but a copy of an immutable string is
optimized to just retain it, so the data isn't duplicated (assuming
all rows have the same columns in the same order, an assumption you
don't seem to be making).
As I mentioned above, with increasingly large files, this
dramatically increases your reading/writing time and uses a lot of
memory. But at least you get the ability to easily use bindings and
to sort, all for free, performance be damned.
Keep in mind that an NSArrayController created in Interface Builder is
defined by default to create an NSMutableDictionary for each item in
the dictionary. It's not unreasonable, and we don't know the OP's
performance requirements.
If you go another route (an array of arrays of strings), it's far
more efficient, but adds a few programming complexities:
1 - How do you sort by a column? There's no key for sort descriptors
and sorting via selector provides no way to pass additional
information (such as column index or identifier).
2 - To what do you bind? The same limitation that causes concern in
problem #1 makes #2 difficult ... and there is little by way of over-
the-counter laxative to make #2 less difficult.
3 - If you intend to allow reordering of columns (built-in
NSTableView feature) or even adding/removing columns, how do you
handle keeping the columns mapped to the correct fields in the row
array in the absence of an associative array (dictionary)?
The easiest solution to all three of these problems (in my opinion)
is to make a "row" a custom class and a helper class (we'll call it
"ColumnMapper" - one mapper shared among all rows). The row's
internal storage can still be an array of strings for low overhead,
but the Row class has a trick up its sleeve. It overrides -
valueForUndefinedKey: so that it can still look up associative
values (like a dictionary) but without storing them. The storage
occurs once in the ColumnMapper.
A reasonable idea if the circumstances require it. It would certainly
avoid storing a reference to each key in each row, so it would save a
little memory, but with the mapping of indexes to column names, it may
not be any faster than a dictionary.
Of course for very large files, both methods will be slow (and
memory-intensive), and the problem becomes far more complex because
then you need to start considering low-level solutions that don't
ignore encodings. The anthesis to this concern is that, as the
complexity and size increase, the likelihood that a human will want
to see it as a table they will manually manipulate decreases (or at
least, the reasonableness of the request does). At that magic
tipping point, it's easy to argue that a GUI editor is no longer
feasible and most of this problem goes away.
Unfortunately, I know from experience that when the row count gets
above 8xx,000, NSTableView can no longer accurately draw rows in the
view (if they are the standard-sized text fields). But that is well
beyond that magic tipping point :-)
Regards,
Aaron
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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