I’m wondering how big of a data can UITableViewController handle… I understand that most of the time we use arrays to represent data in each of the table view’s cell.
Suppose that the array contains a fair amount of strings and some kind of integer (as an id for that row, to be passed when you select that row). Then each element of the array is something like 4 bytes for the string and 4 bytes for the integer. I’m not sure though how to calculate the maximum elements we can have in a single tableview.
However this leads to another question: even if the iOS device can handle very big data (say 2000-3000 rows), is it a good design decision to present user with such large amount of data? In Apple’s Contacts app, they present data of so many contacts all at once while giving the A-Z quick jump on the right hand side. In the Twitter app, users are presented with hundreds of tweets (although cut off in the middle if it’s older than a day).
So which way is best when presenting user with such large amount of data?
You don’t need to keep all the data in memory at once. Sure, an array is the easiest way of doing it but if you’re going to have many rows (which I guess you are because you asked this question!) then you really need to be caching the recently used values.
But that’s not the only thing you need to consider.
When the table is first displayed it first asks the delegate how many sections and then it asks every section how many rows it has (even if they’re not going to be displayed initially). This means that the more sections you have, the longer the table will take to display.
One of the big changes I made between version 1.x and 2.x of my app was to reduce the number of sections displayed on the main screen. I also stored meta-data — such as the number of rows in each section — so that I wouldn’t need to calculate them each time the view became visible. This meant it could deal with far more rows and was much quicker even when the volume increased