The mobile service solution manages the synchronization of the offline data.

Requirements

1. Needs a form with name 'offline_data'
2. The form offline_data needs a method ws_read(version,name)
3. If the data shown in mobile app is user specific the form offline_data needs a method ws_authenticate(useruid,password)
4. The mobile_service and rest_ws plugin to be installed

...

function onSolutionOpen() {
	// prevent prefilling of form foundsets with default query
	databaseManager.setCreateEmptyFormFoundsets()
}

Constructing

...

an Offline Data Package

...

for the Mobile Client

The ws_read(version,name) on the offline_data form has to return an OfflineDataDescription (=JSON) object filled with foundset data the developer wants the mobile client to retrieve.
An OfflineDataDescription instance is created with:

...

Basically addFoundSet in the service solution exposes an unrelated foundset to the mobile client, which can be used in an unrelated way like in a (first) form or databaseManager.getFoundset(...)
For each record in the provided (unrelated) foundset the specified relations are traversed and all data taken.

User Specific Data

In order to provide a mobile client with user specific data the ws_authenticate(useruid,password) method should be added:

...

function ws_read(version,name)
{
	var questionParams = arguments[arguments.length-1];

	//create return value
	var retval = plugins.mobileservice.createOfflineDataDescription('data_');

	//setting the key for user_select relation
	var authenticate_info = questionParams.ws_authenticate[0];
	globals.username = authenticate_info.username;

	//prepare personal data
	var fs_contact = globals.contact_data$username;//global related foundset using username global var, containing the account manager contact

	/**
	 * @type {Array<String>}
	 */
	var traverse = new Array();
	traverse.push('accountmanager_to_companies');
	traverse.push('companies_to_contacts');

	retval.addFoundSet(fs_contact, traverse);
	return retval;
}

Providing/Retrieving Entity(=table) Row Sata

Row/record data is retrieved in separate calls for each entity, for example for 'orders' row data results in a call to 'orders' form is made on ws_read method.
Note: If a prefix is provided in the offlinedata the call will end up at prefix+entityname, example for prefix 'data_' the call happens on form 'data_orders'

...

TIP: since ws_read for entities is likely the same, it might be beneficial to create a base form containing this logic and extend from this form

Syncing Back

...

the Changes

...

from the Mobile Client

ws_update is called for changes made by mobile client, example code:

...

function ws_delete(version,pk)
{
   if (foundset.find())
   {
     var table = databaseManager.getTable(controller.getDataSource());
     var pkname = table.getRowIdentifierColumnNames()[0]
     foundset[pkname] = pk;
     var count = foundset.search();
     if (count > 0)
     {
       var rec = foundset.getRecord(1);
       foundset.deleteRecord(rec);
     }
   }
}

Transaction Based Syncing

By default the mobile client will do a rest call per changed row, these are separated calls so every call will be on a fresh new client on the serverside.

...

This code above starts a transaction then calls the performSync method of the mobile service plugin. This plugin will dispatch all the changes to the various ws_update/create/delete methods of the entity forms. If something goes wrong then an exception will be thrown and the transaction will rollback.

User Properties

If using get/setUserProperty() in the Service Solution, the properties are stored in the Mobile Client that connected to the Service Solution.
As such, a user property can be used to store for example an authentication token to be used between multiple calls to the Service Solution from the Mobile Client.

...