[Borborygmi]

Hi all, I'm a beginner Cocoa programmer who has messed around with REALbasic quite a bit. I'm trying to figure out how to store large amounts of data on disk, and then browse it easily. For example, as a starter app, a window with 5 text fields, and a button that wrote that info to disk, and then another window with a 'prev' and 'next' button that could advance through the data showing me those 5 fields for every 'record' that I had written to disk. RB had database functionality built-in, so I'm trying to figure out what Cocoa has... can anyone take a minute and give me the big picture here?
Thanks,
Borborygmi

[TheBum]

Originally posted by Borborygmi:
<STRONG>Hi all, I'm a beginner Cocoa programmer who has messed around with REALbasic quite a bit. I'm trying to figure out how to store large amounts of data on disk, and then browse it easily. For example, as a starter app, a window with 5 text fields, and a button that wrote that info to disk, and then another window with a 'prev' and 'next' button that could advance through the data showing me those 5 fields for every 'record' that I had written to disk. RB had database functionality built-in, so I'm trying to figure out what Cocoa has... can anyone take a minute and give me the big picture here?
Thanks,
Borborygmi</STRONG>

Check out Mike Beam's excellent series "Programming With Cocoa" at http://www.oreillynet.com/mac. The last installment talks about saving data using the XML capabilities built into the Cocoa frameworks. Granted, XML is not exactly the most compact data format in the world, but if you're not worries about disk space, it has the advantage of being human readable and text-editable.

[ 09-06-2001: Message edited by: TheBum ]

[coredump]

This is actually a HUGE can of worms. Many universities offer a semster long class on this very topic as part of their undergraduate CS programs.

Since you mentioned you will be storing/accessing a large amount of data, I would suggest you pick up a good book on file structures. I recommend "File Structures: An Object-Oriented Approach with C++" by Folk, Zoellick, and Riccardi ISBN# 0-201-87401-6. The examples are in C and C++, but the text is verbose enough that example code isn't even really needed.

If you're short on cash you might get by entering a few of these terms in the search engines: B-Tree, B+ Tree, Avail List, Hashing, Heapsort, Mergesort, Record Structures, Fixed Length Record, Variable Length Record.

I'm not really familiar w/ all of the Cocoa Framework myself yet; however, a quick perusal of the docs turned up a few items of interest: NSData, NSCoder, NSArchiver, NSUnarchiver, and NSFileHandle. I'm not exactly sure just how efficient these classes are. If it were me, and I had a LARGE amount of data, I would probably write custom classes.

As "TheBum" pointed out, please do your users a favor and don't use Cocoa's XML serialization method thingy. Along with increased disk usage, you get increased data access times.

Welcome to the world of REAL programming languages. Your productivity will probably drop for a while, but your quality should immensely improve.

Obligatory UNIX bigot remark:
man 2 open && man 2 write && man 2 read && man 2 lseek && man 2 close

[ 09-07-2001: Message edited by: coredump ]

[Borborygmi]

With all this talk of being able to write Cocoa apps in 1/10th the time, I'm surprised data storage seems so difficult to implement. Writing the contents of 5 text fields to a file as a 'record' and then browsing that data shouldn't be too hard.... but perhaps it is?

[coredump]

I'm quite sure that Cocoa apps can be developed 10x faster than ToolBox apps in C, but I don't think one would see an increase in productivity like that coming from a RAD, component based language like RB. Like I said, your productivity will probably drop a bit, but your quality should improve.

Data storage and retrieval can be as complicated as you want it to be. Here is one possible solution to the starter app you mentioned. Use fixed length records and visit them sequentially. This is eaasy to implement and meets your stated requirements. If you later decide you want to be able to search for a particular record, this solution quickly falls apart. Assuming you had 100,000 records in your file, you would have to make 100,000 trips to disk.

If you don't feel like taking the time to implement this sort of stuff, you can take a look at Berkeley DB or gdbm.

[amonitzer]

Originally posted by Borborygmi:
<STRONG>With all this talk of being able to write Cocoa apps in 1/10th the time, I'm surprised data storage seems so difficult to implement.</STRONG>

That's because Apple killed the DB-part of Cocoa, called EOF. Their impression is that nobody except web-pages needs data storage (or something like that).