Cocoa EOF? No thanks

It appears to be with increasing frequency that one can hear experienced Cocoa developers reminiscing about EOF for desktop applications and new developers wondering why Core Data doesn’t use stores in network RDBMS’s from a range of vendors.

As Watershed’s persistence framework will shortly be replaced, I’ve been working on some possible replacements. One of the best things about being an in-house developer is, I get to to see people using my applications every day. I walk past people’s desks and see which windows are open and what tasks users perform. An incredibly frequent task runs as follows:

1. The user needs to make a quick edit to an item stored in a relational database.
2. The user opens their Cocoa client and a window opens, normally containing a NSTableView listing all the entries.
3. The persistence routines generate the required SQL, sends it to the database and receives a stream of data.
4. The persistence routines turn the data into a object graph generating thousands and thousands of objects. Each business object, even with relationships represented by proxy objects, contains many attributes each of which is represented by an object.
5. Once the persistence routines have finished creating the thousands and thousands of objects, making copies & caches and linking them together by setting object instance variables: the user opens the first item in the list, corrects a typo and quits the application.

The problems evident in the example could be seen as a UI issue. Possibly the way forward is to follow iPhone applications’ methods of display a small number of entries then prompting the user to load then next batch. iTunes displays thousands of tracks in a table on launch so why can’t my applications do the same? The business object implemented using NSManagedObject or an EOGenericRecord is an atomic unit. Why does the application need to populate an entire business object just to display the title in one column?

Caching large chunks of data on the client made efficiency enhancements that were just not needed. Launch times are incredibly slow, damaging the user experince. Worried about excess network traffic, we started off designing clients with aggressive caching. Our controllers in the Cocoa applications now save changes more frequently, and with less modality in the edits. This results in a constant trickle of data across the network but a much smoother user experience.

Public applications with a large number of users render bulky local caches ineffective. As the number of editors increases, the probability that a local cache is no longer synchronised increases.

Frameworks such as EOF or ActiveRecord work very well over high speed, high quality networks but many network connections for Macintosh, and iPhone, clients are mobile and made wirelessly or are intermittent. Many clients connect over fragile internet connections where the performance will destroy the user experience.

So, no I don’t want Apple to re-release EOF for Objective-C or allow Core Data stores to reside in a network RDBMS—I want something better.