Re: Table View Blues (summary)
Re: Table View Blues (summary)
- Subject: Re: Table View Blues (summary)
- From: Sheehan Olver <email@hidden>
- Date: Wed, 20 Nov 2002 15:20:11 -0600
I thought of a solution around the release/retain problem you seemed to
have. Now suppose you manage to get your data in a c string array. You
can use this as your backend as opposed to an NSMutableArray:
char[][] *data; // string for row, column: data[column][row]
int numRows;
NSString *column1Name, *column2Name,
- (int)numberOfRowsInTableView:(NSTableView *)aTableView
{
return numRows;
}
- (id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn
row:(int)rowIndex
{
if([[aTableColumn identifier] isEqual:column1Name])
return [NSString stringWithCString:data[column][row]];
else if ...
}
Now, assuming the table only calls the get the second method when a row
is displayed, it will constantly be creating and releasing NSStrings,
but only say 25 or however many are displayed at a time. This means
that sum total of deallocating is the amount of time it takes to free
the data array, since no objects are used for your backend. I hope this
is what you were looking for.
On Wednesday, November 20, 2002, at 12:00 AM,
email@hidden wrote:
>
I couldn't have put it better myself, Alex - and I didn't! Thanks.
>
>
And yes, this is the crux of the matter. When dealing with large
>
quantities of data - let's not say "thousands of records", let's just
>
say "something that is scalable", you can never get away from the onus
>
of loading the data. That much we know. But we also know that in
>
practice you are going to run into trouble when doing away with that
>
data, and for two reasons:
>
>
1.) Your visual interface has to be able to dispense with the whole
>
ball of wax in a single call.
>
>
2.) Your internal representation has to be able to do the same.
>
>
A file of several hundred KB should load and reload instantaneously.
>
Now if the table view can just shrug its shoulders and say "he says
>
there are no rows, OK, so there's no rows" - if it's that simple, then
>
we're over one hurdle.
>
>
But underneath - in the data management - something more streamlined
>
has to be engineered. Just guessing, but is there a way to work all
>
this into an autorelease pool? For that would solve it all - given
>
that the pool doesn't waste valuable real time...
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.