Data Abstract Class Prefixes

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 the “RemObjects SDK”, the underlying remoting framework that Data Abstract uses to communicate with the server.

When developing a regular Data Abstract application, you don’t usually have to care about how the communication between the client and the Relativity Server is handled, because Data Abstract encapsulates all that for you.

When building Data Abstract applications, the RemObjects SDK is contained within libDataAbstract.a, the static library for Data Abstract.

Data Abstract Classes

When developing a Data Abstract for Cocoa application, the core classes that you will be interacting with are DARemoteDataAdapter, DADataTable and DADataTableRow.

DARemoteDataAdapter

The DARemoteDataAdapter (frequently referred to as the “RDA” for short) acts as a central connection point for your client application to communicate with the Relativity Server to receive data tables, send updates, and handle any other data-related communication tasks.

DADataTable

Data received from the Relativity Server is represented by DADataTable instances.

A DADataTable contains an array of rows containing the actual data, and also maintains information about any changes that may have been made to these rows locally, but that have not yet been sent back to the server. Each row is represented by a DADataTableRow instance, and contains data as specified by a list of DAFieldDefinitions. Fields can either be real fields, for which the data is contained within the table itself, or Calculated and Lookup Fields, where the value is determined at runtime, when needed.

The individual rows in the table can be accessed as an NSArray of DADataTableRow's using the rows property.

DADataTableRow

The DADataTableRow class represents a single data row in a DADataTable. Each DADataTableRow not only maintains its data, but also keeps track of any changes made to its values until they have been successfully applied back to the server.

The value for individual fields can be obtained in a Key-Value-Coding (KVC) compliant manner by sending a valueForKey: message, and changed by sending setValue:forKey:. Changed values will be cached locally on the row until the applyChanges or the beginApplyChanges method on the RemoteDataAdapter is used to send them back to the server.

Pending changes can be reverted by sending a revertValueForKey: message to revert a single field, or revert to revert all changes to the row in question. You can also obtain the current or original value for a specified field by using valueForKey: and originalValueForKey:, respectively. The rowState property can be evaluated to see if a given row contains changes and whether these changes consist of the row being modified, newly inserted, or deleted.

DADataTableRow allows to change its data in several ways:

Directly changing data

You can change the data inside the row directly. After that, you can cancel your changes by calling the cancel method, or send them to the server using the applyChanges/beginApplyChanges methods of the DARemoteDataAdapter.

Two-phase editing data (edit, post & discard)

You can alternatively set a row into edit mode by calling the edit method and begin to change the data. In edit mode, the row will store its current values including any pending changes that were made previously. In order to confirm or discard changes made in edit mode, you will need to use the post or discard methods, respectively.