Nowadays, I have thought about how to present long list of data in a table view (Mac) or a list control (Windows/MFC).
I’m not talking about putting 1000+ items in a list control or a table view. It is about to put up-to 2 Million records. Each record can be 2 KB. It is 4 GB of data.
On 32bit Windows, user addressable space is 2GB. Although we already migrated to 64bit Windows, we should not lock out 32bit Windows yet.
With plain CListCtrl, on Windows, it can’t support more than 32767 records. Also, if you want to declare a collection variable for holding huge number of data items, you will run into 2GB barrier anyway.
Then how to solve this problem?
( Let’s assume this. You are a framework / API designer, not an application programmer. )
There are two ways to approach this problem.
- Internal Data Handling point of view
- GUI point of view
1. Internal Data Handling point of view
You can design like this : GUI element get data feed from an internal collection variable like an array or a list. The internal collection variable is connected to a memory mapped I/O mechanism. So, actual data is transparently saved on a HDD, but to programmers, whenever they ask next data item in the variable, it behaves like that it holds all the data in the memory by returning asked data to the caller.
On Windows, MFC/Win32 supports memory mapped I/O for this. And I believe the virtual list control can be connected to this mechanism. But fortunately, the virtual list control itself supports “DWORD” range of number of data in the list. Which means that it can supports more than 2 million records.
On Mac, things are even easier. This is where modern framework shines. NSTableView will handle any number of records or data sets transparently. What is even better for this Cocoa class is that GUI elements, i.e. widget, are separated from their data sources. So, you can set whatever data source for NSTableView. NSArray can be a good candidate. As far as I know, NSArray is implemented with an array and a list. If it holds items less than a certain number, it uses an array, but if it grows more than that, it is changed to list-based. I believe NSArray uses mmap, which is a memory mapped I/O library on Unix for handling huge set of data to give virtually unlimited capacity.
Cocoa is more well written framework than MFC, because its UI part is separated from its internal data, and it wraps things which are not trivial to programmers to give a natural feeling. .NET is also similar to Cocoa. Actually, if you check the both frameworks, .NET and Cocoa, you will think, “Is .NET modeled after Cocoa?” They are that similar. ( Not keyword or syntax level, but conceptual and approach level. )
2. GUI point of view
Sometimes, you, as a framework designer, would run into a situation where it is not easy to provide such flexible mechanism described in the section above. Also, that kind of approach can be inappropriate sometimes.
Then, how would you solve this problem?
iOS suggests one way to solve this problem.
Let’s take a look at a few screenshots.
The screenshot above is from App Store app on iPhone/iPod Touch. When a user touch “Show Top 50…”, it queues up-to top 50 items and displays it.
Here is another example.
Scroll-Up case is interesting. This implementation was tried first by Tweetie for iPhone or something else. In the case of Twitter, the latest tweet appears on the top. So, it is the latest data to display. However, can’t we apply this to general UIScrollView/NSScrollView for retrieving previous data? It will be possible. So, you can retrieve data from a DB backend like :
SELECT TOP 10 column FROM table
MySQL / PostgreSQL
SELECT column FROM table
LIMIT 10 OFFSET 20
The last line, “LIMIT n OFFSET x”, is to retrieve records from 20th to 29th. Then, you will see that iOS approach solves this problem nicely. ( Let’s assume that the UITableView on iOS can’t hold multiple million records and display them all at once. )
If MS and Apple provide this kind of table or CListCtrl functionality in their .NET or the latest MFC and Cocoa on desktop OS, it will solve many memory hogging scenario nicely without compromising much.
Do you expect the Lion, i.e. Mac OS X 10.7, will bring this to the desktop? ( Lion is supposed to bring many cool iOS things to the desktop OS. )