When too much is too much ...

To store the data generated with my iPhone application, I have been using the facilities provided by the NSCoding protocol in cooperation with a NSKeyedArchiver, and it works quiet well even if it is likely not what I should be using since it force all my data to be saved or loaded all at once. Nevertheless at this stage in the development process, this is a good enough solution since my data-set is relatively small (less than 30 items). The whole concept of archiving object isn't new to me since I was using it back in my BeOS days (BMessage with the BArchivable class), however the NeXT's take on this old favorite is a little much more handy to use, thanks to Objective-C dynamic nature (compared to C++ more rigid nature) . Since the name of the class is archived at the same time than the object data, it can be later used to recreate the object automatically (granted that the executable unarchiving your object knows about that particular class).

Unfortunately, there is (of course) a price to paid for using NSKeyedArchiver. The end result bytes consumption is criminally high. For example a simple NSObject derived class, encoding a uint and a float, requires a 232 bytes long buffer. 8 bytes of real data (not counting the class name), flattened into 232 bytes ... So obviously, lots of the overhead won't be duplicated if I was encoding more than a single object, but if you want to archive a single object for transmission or storage (bytes oriented kind of storage), the cost is a little too high.

Hopefuly, since the NSCoding protocol is based on using the abstract class NSCoder, one could create its own archiver, with hopefully similar capabilities, but lower memory footprint. I know, I shouldn't waste my (limited) time making my own, and instead focus on the app, but I can't help ...