Synchronization methods for custom clients
Synchronization in NetWeaver Mobile client can be broadly classified into four categories.
1. User Driven Synchronization.
2. Background Synchronization.
3. Repetitive Synchronization.
4. Disc Synchronization.
User Driven Synchronization: There is a sync button on the home page or any suitable location of the client/application and the user decides when he wants to sync.
Background Synchronization: A synchronization that keeps happening without interfering with the use of the client/application at regular interval and thus the user gets updated information more regularly.
Repetitive Synchronization: A synchronization which goes on till the complete data has come down to the client/application, this can be implemented by some sort of a data completeness check. There can be a timeout based on the maximum number of synchronization which takes care of any bugs in the data completeness check logic. This type of synchronization can be implemented for both a user driven synchronization as well as a background synchronization. Thus this means that if a message is send to the server from the client the client keeps syncing till the message has gone from the server to the backend and a resulting confirmation or rejection from the backend has travelled back to the client through the server.
Disc Synchronization: This can be a way of getting data from server on a flash drive or cd and then putting it on the device at a proper location from where the device consumes it and places it in its inbound queue from where this is consumed as any other sync message coming to the client, in return the client can put the messages from its outbound queue to a location from where it might be copied and taken back to the server via cd or flash drive. The method where the client has a capability to consume a file containing data is very useful during Mass rollout of devices where the devices are fully loaded with applications and data. So when such requirements arises where in the client/application and the data needs to be ready before the device is handed out to the end user, a bundle containing all these namely, the client/application setup packages, data and in some case the database and the jdk is prepared with an executable which will install all these and start the client and make it do a disc sync. Thus when the end user launches the client and logs in he has data and he is ready to go ahead with his work.
An implementation of the Sync layer in a client almost always needs an outbound queue and an inbound queue, the outbound queue holds the data that needs to be sent from the client to the server and the inbound queue holds the data that has arrived from the server but has not yet been consumed/processed by the client.
Both queues have their own advantages, they act as a staging area for the outbound and inbound messages. The obvious advantage is that the use of network is reduced drastically since the messages only needs to be dumped in inbound queue and picked up from outbound queue, the populating of the inbound queue and the processing of the outbound queue can be totally separate activities and can be done depending on the application logic.
There can be two ways of populating of inbound queue, first, the message calculation is made during the actual sync, meaning all the rows of data changed on the client/application are marked and the sync messages are created during the actual sync, this means that each row of data that is changed will have one corresponding message in the outbound queue no matter how many times the row is edited provided it is done before the actual sync. This has the advantage of a reduction in the actual number of messages that flow from client to server, but has the disadvantage of slowing down the sync since the sync time will get a hit due to the message calculation happening, the more the number of messages the slower the sync.
The second method (which is called smart sync in NetWeaver mobile client) is, create each message as and when a change is made and saved, thus if a user makes a change and saves, one message is created and then if he decides that he needs to edit the same row of data again, another message is created for the second save, and thus it is possible that a change in one row has more than one messages in the outbound queue. But this has the advantage of having a faster sync.
There is a certain advantage of having the inbound queue, since this allows the processing to happen at a convenient time. Think about the case where a background sync is running and the processing of messages is a part of the sync, there can be cases where the user and the message processing can both be changing the same row at the same time giving rise to complications, in such cases the message processing can be delayed till the user clicks the save inside the application, or the normal processing can go on if the user is not inside the application.
This is a very high level view of a few varieties of Synchronization with their merits and possible demerits and a few ideas how they can be handled while coding for a custom client, hope this will help the reader.