Developer

Java Complex Table Synchronization Components

When a complex table is defined to use a Java Virtual Machine system connection type, its synchronization component consists of a Java source file. This file contains a skeleton class declaration. This class is created specific to the complex table definition and extends the Agentry Java API class ComplexTable.

When the table is defined, the wizard for creating Java classes provided with the Eclipse Java perspective is used. This allows the developer to select the package to which the new class will be added. The source .java file created will then be stored according to the configuration of the project and package selected for the new class. Alternately an existing class in a package within the Java perspective may be selected. This class must extend the Agentry Java API class ComplexTable.

This skeleton class includes the following methods:
  • The Constructor method for the class
  • An override implementation of dataIterator(). This method is intended to contain the logic to retrieve the data from the back end system for the complex table records. It returns an iterator to the data object created to store this returned data. The Agentry Server calls this method during synchronization and uses the returned iterator to extract the data for the records from the array of data objects. Records returned by this method are sent to the Client to be added to the complex table, or to replace those records with matching key field values.
  • An override implementation of deleteIterator(). This method is intended to contain the logic to retrieve the key field values from the back end system for the complex table records to be deleted from the client application. It returns an iterator to an array of the data object created to store this returned data. The Agentry Server calls this method during synchronization and uses the returned iterator to extract the key field data for the records from the array of data objects. Records returned by this method are deleted from the Client.
  • The method willRebuildTable() can be created within the complex table class if needed. This method is called by the Agentry Server after the constructor method has been called. Its logic should check for any administrator defined conditions within the back end system to force a complex table rebuild. This method is expected to return a Boolean value. True will set the rebuild state for the complex table.
  • The method build() can be created within the complex table class if needed. This method is provided to allow for a single call to the back end system to retrieve new, updated, and deleted records. If a build method is present it will be called by the Agentry Server before the iterator methods. In this scenario, the iterator methods are still expected to provide access to the returned data. However, the build method will have already retrieved it. If two separate calls are needed to retrieve updates to the table and deletions from the table, the build() method should not be used. The logic for those separate calls should be contained in the iterator methods, which are always called by the Agentry Server.

In versions of the Agentry Mobile Platform prior to 5.1, the source class was stored on the Agentry Server’s file system. This behavior is deprecated in versions 5.1 and later. Agentry application projects created prior to this release are still supported and the Java logic will still be processed correctly. New complex tables for Java Virtual Machine system connections should use the new procedure for defining the Java synchronization component.