How big of a data can UITableViewController handle?

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 s开发者_高级运维tring 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

UITableView can handle a huge number items because it only requires the data that is being displayed. However, the limitation of the device means that you may not be able to store all data in memory. If this is the case you can use Core Data to keep the amount of data stored in memory to a minimum. NSFetchedResultsControlleris your friend.

As far as the UI is concerned I think the index bar displayed on the right of the table can make large data sets possible. However, lets take an example of 3000 items. If we have 25 index points (eg A, B, C, D etc), then this would be 120 items between index points. I would advise against using an strict alphabetical index in this case because the distribution would be very uneven. I would parse the data and have the first 2 or 3 letters of each 120th item. With this in mind I would guess that 3000 wouldn't be a great UX.

I think that for large amout of data, all data are not in an array in RAM, but in a base on flash drive (core data or sqlite).
Just data for visible rows are in memory.