views:

46

answers:

1

I am developing an iOS application and am having some issues deciding how to approach a problem.

I am using two UITableViewControllers to display different views of the same data. One is a master list, and the other only contains items which are marked as "favourite". Also the items are variable height, so I am using "heightForRowAtIndexPath" to indicate the height for each item. The problem is speed, when I switch from one view to another, it needs to be updated to display the changes made in the other (marked favourite/unfavourite).

Solution #1:

Reload the data each time a table view becomes visible. This does not work nicely because although the data is display using lazy loading, the "heightForRowAtIndexPath" is called for every item before ANY data is loaded, and its slow. on my iPhone 4 a list of about 300 items takes about four seconds to load, even if the height values are cached (the bottleneck is applying the height, not retrieving it).

 

Solution #2:

Manually manipulate the tables when changes are made. I have not tried this, but it would likely be buggy. Your thoughts?

 

Solution #3:

Using a notification type system to notify the other table of updates to items that might currently be loaded. I have not tried this, because it seems over the top and might not work at all.

Does anyone know of an easy way to show two views of the same data?

+1  A: 

You can reload n rows with reloadRowsAtIndexPaths:withRowAnimation. I never did it, but I think it's there because it's faster, so you might want to try it out.

On the heightForRow: thingy, I can remember reading in the Apple docs that that function is indeed a killer for performance. Perhaps you could take the maximum height of the rows, and set that in the UITableView.rowHeight?

Nick
Indeed. - (void)reloadRowsAtIndexPaths:(NSArray *)indexPaths withRowAnimation:(UITableViewRowAnimation)animation
Tom Irving
Yeah heightForRowAtIndexPath is very slow, but I just don't think the app would look right with identical sized rows. The only alternative I will consider for speeding it up is perhaps serializing the table view and deserializing it when the NIB loads. Not sure if its possible but its an idea.
Nippysaurus
@Nippysaurus: Sorry for the late comment. I don't know any other ways to speed this up. What do you mean by (de)serializing the tableview?
Nick
@Nick: If you are not familiar with serialization, the Wikipedia definition: "In computer science, in the context of data storage and transmission, serialization is the process of converting a data structure or object into a sequence of bits so that it can be stored in a file or memory buffer, or transmitted across a network connection link to be "resurrected" later in the same or another computer environment."
Nippysaurus
@Nippysaurus What do you mean by serializing the view? What are you going to serialize?
Nick
@Nick: I'm running with assumptions (because I'm a Cocoa n00b), but I think the state of the control is stored in the "controller.view"? If you serialize that it should retain its state. I could be wrong, but that was the idea I was trying to communicate.
Nippysaurus
@Nippysaurus: What state of control? I don't think any state is stored in the view, it'd be very bad practice.
Nick