Introduction to the Library
Data Abstract for Cocoa is a sophisticated library with dozens of classes that work together to provide a state-of-the-art multi-tier client solution for iOS and Mac OS X, written in 100% native Cocoa code that is shared (with very few #ifdefs) between the two sister platforms. There are a lot of things that go on under the hood to enable the seamless data access with all its features, such as keeping track of local changes, merging conflicts, robustly communicating with the server, and so on.
Luckily, Data Abstract “abstracts” most of this functionality away from the developer (although that is not where it got its name), letting you concentrate on what is important – creating a state-of-the-art iOS or Mac application that presents or edits data according to your needs – without having to worry about the internals of what is happening behind the scenes too much (although you can take an interest and tweak DA down to the lowest levels, if the need should arise).
Per convention, type names in Cocoa frameworks usually start with two-letter prefixes, such as NS* or UI, to avoid name overlap. To be consistent with this system, classes in Data Abstract use the DA prefix throughout the framework. In addition, you might also encounter classes with RO* prefixes, for example in call stacks during debugging. These classes come from Remoting SDK for Cocoa, which is the underlying remoting framework that Data Abstract uses to communicate with the server. Developing a regular database application, you don’t usually have to care about how the communication is done, because Data Abstract encapsulates all that for you.
When resolving the static
libDataAbstract.a library into your application, Remoting SDK is contained within that library already. When working with
DataAbstract.framework, you need to separately reference
RemObjectsSDK.framework as well, and make sure it gets copied into your application bundle.
There are three core classes that are most important in working with Data Abstract for Cocoa, and which you will be interacting with in your day-to-day work with Data Abstract: DARemoteDataAdapter (“RDA”), DADataTable and DADataTableRow. We cover these three classes extensively in a dedicated article called .
To use the basics of Data Abstract, you really can stop reading here.
Data Abstract leverages the concept of Data Streamers for encoding the data that is received from and sent to the server. Currently, only one streamer type is widely in use, the DABin2DataStreamer. An abstract base class called DADataStreamer is provided, from which new streamers can be inherited.
Data Abstract supports storing data to local disk or flash memory for offline use, for example to persist data or un-applied changes across application restarts. This is implemented via the DABriefcase class cluster, and discussed further in the topic.
Beyond this, the Data Abstract library contains various helper classes – some of which are used internally by the core classes, while others are exposed publicly for you to use for certain tasks. For example, the DAArrayDataSource class can be very helpful when binding data to an NSTableView without much code.
As mentioned above, Data Abstract uses a second library called Remoting SDK as its underlying communication layer. In most cases of working with DA, your only contact with Remoting SDK will be in maybe encountering a class name here or there.
But in some cases it will be helpful to know what is going on under the hood, so we will take a closer look at Remoting SDK in the topic.
Remoting SDK also exists as a separate library and product that can be very helpful when implementing non-database driven client/server communication – whether in the context of a Data Abstract app, or standalone. If you have a need for communication between your client and your server beyond just exchanging database data, we recommend that you check Remoting SDK for Cocoa out.