3

I have around 5,000 objects which I'd like to place into a UITableView. I'm currently doing this via a mechanism that plucks the first 50 from the array they're stored in, copies those to another array, then loads that array into the tableView. I then use willDisplayCell:forRowAtIndexPath to automatically load in the next 50 when the table reaches the penultimate cell. It does this by just keeping track of where it stopped copying earlier, and copies the next 50, and repeats the process.

This poses a problem that I've not solved yet: I should be unloading the first 50 when I load in, say, the third 50. So, we go from 0 to 50, then 50 to 100, then 100 to 150, and at that point, I need to remove 0-50. If the user scrolls back to the top of the list, it would need to load in the previous 50 again. Basically, the table would have no more than 150 entries at any one time, so 0-150, or 50-200, or 100-250, or 150-300, etc.

What I'm wondering is whether this is the best way to approach something like this. There isn't a problem with slowdown when the user scrolls to the end of the table, but I'm wondering whether something like asynchronous loading of the data would be better? I'm really new to multi-threading but if it's going to be a simpler method, I'd love to give it a try.

Hopefully this being a more opinion-based question won't be an issue, I realise there's probably not one set answer, but in case I get "not a real question", my question is: is the approach described above the most efficient and effective way to gradually load a large amount of data into a UITableView, and is there a more conventional means of achieving a similar effect via multi-threading, lazy loading, or other techniques?

EDIT: I'd also point out that the vast majority of the cells do not contain images, they're just a couple of UILabel instances.

Luke
  • 9,512
  • 15
  • 82
  • 146

1 Answers1

1

Why you create another array? If the 5000 objects are already in a array, is wastefull (IMHO) copy a slice of them to also recreate it as table cells. They are already in memory.So maybe do you need to make some transformation before render the cells?

Make a async load not make a lot of difference if the data is already in memory, and not CPU/IO intensive task is done between the data and the final render. If the scroll feel right, then I think is as fast as is possible.

Another thing is if the data (the one that make the original array) came from disk/net or is a CPU/intensive transformation. THERE is where the big gains can be done.

mamcx
  • 15,916
  • 26
  • 101
  • 189
  • The data comes from a .plist (which contains an array of dictionaries) that I've already assembled. At present I'm just loading the entire array in. Would doing that in parts be better? – Luke Feb 22 '13 at 15:11
  • Check http://stackoverflow.com/questions/2936725/iphone-long-plist and http://stackoverflow.com/questions/10861935/load-a-big-plist-from-url-in-background. In short, plist are not meant for big data (measured in MB, not numbers of items). If the app is fast as is, then not worry too much. If is slow loading the plist, do it async. Or move to sqlite/coredata so you can do it in chuncks.BTW I load 5000 rows from sqlite directly to array, no in chuncks and feel ok for me... – mamcx Feb 22 '13 at 15:55