Re: Design for custom tableviewcell button action
Re: Design for custom tableviewcell button action
- Subject: Re: Design for custom tableviewcell button action
- From: Brian Slick <email@hidden>
- Date: Fri, 03 Jul 2009 17:45:34 -0400
On Jul 3, 2009, at 4:39 PM, mmalc Crawford wrote:
On Jul 3, 2009, at 11:54 AM, Brian Slick wrote:
I did make a slight adjustment to the technique - most
significantly the omitting of the identifier in the XIB file,
This is actually a very significant factor.
If you haven't set an identifier, it's not clear how you're
retrieving cached cells in tableView:cellForRowAtIndexPath:?
I assume you have a test along the lines of:
UITableViewCell *cell = [tableView
dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil) {
cell = ...
Could you check whether you're creating a new cell each time?
That's impressive; good call. It was indeed creating a new cell each
time. And now that I take a second look at the code, I'm pretty sure
I see why. The XIB-loading command itself doesn't actually have the
identifier as a parameter, and is thus totally dependent on that info
being in the XIB. Therefore, the cell never gets queued. My initial
thought was that omitting it would make it generic, but I now see the
flaw in that thinking. Simply declaring the identifier doesn't make
it get used anywhere. :p
Incidentally, that's what is wrong with TaggedLocations... it also
does not have the identifier in the XIB. I manually added it, then
retested, and saw dramatically better performance (for my own program,
too).
So now I either need to figure out how to make my scenarios all work
with a single identifier, or I may just go ahead with the code-only
cell I just built in response to the performance issue. If would be
nice if there was some kind of queueWithReuseIdentifier: method for
these XIB cases. (This is what I'm trying to do: http://bit.ly/l55eH )
All this aside, please file a performance bug against the
TaggedLocations sample.
Done, although I'm not sure if I did so correctly. Thank you for your
help.
Brian
_______________________________________________
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