Indicates how data is synchronized from the server to the device in Offline Native Mobile applications.
|By Row ||Default value. Indicates that the synchronization is made row by row. There are two alternatives to this mechanism (refer to the Description section).|
|By Table ||Indicates that the synchronization is made by table.|
Objects: Offline Database
Generators: Android, Apple
Since the addition of Offline Native Mobile Applications in GeneXus, there have been two different algorithms for synchronizing data from the server to the devices: synchronization by table and synchronization by row.
The synchronization by table algorithm is straightforward: on the server-side, a hash of the table is computed and compared with the hash sent by the device. If they match, there is nothing to synchronize. If they don’t, the whole table is sent to the device and there, it replaces the previous content.
The synchronization by row algorithm requires some further explanation. Without going into much detail, if the table has changed (table hashes don’t match), the changed rows are computed (inserted, updated, and deleted) and sent to the device to be processed. This is the default behavior and we'll refer to it as synchronization by hash, but there exists a second variant of the synchronization by row algorithm that uses a timestamp instead of hashes for computing the differences. We'll call this last alternative synchronization by timestamp which is defined on a per-table basis by configuring the Logically Deleted Attribute property and the Last Modified Date Time Attribute property.
Further explanation of these alternatives is discussed in Offline Native Mobile synchronization granularity alternatives article.
This property applies only at design-time.