2 minute read
Resilient SDK (rSDK) is a new major release of the @platform with several changes to make apps using the SDK more resilient and fault tolerant. This guide is intended to help app developers with the use of rSDK.
rSDK offers three major changes:
Factory class responsible for giving the instances of AtClient and other services for a given @sign.
AtClient should be used to perform Create, Read, Update or Delete (CRUD) operations on the secondary server.
NotificationService should be used to send and receive notifications from the secondary server.
SyncService should be used to keep local and cloud secondary data in sync.
Sync in the @protocol is a process to pull or push data between local and cloud secondary servers to make sure that the data is in sync.
For example, if an app creates a key called phone@bob and saves it to the local secondary, the Sync process will push that to the cloud secondary server and make it available to be consumed by another @app on another device.
Sync process is triggered in two ways:
App sync
Apps on @protocol can request for an invocation of a Sync process by calling the “sync” method on “SyncService”. Calling “sync” would not immediately trigger the Sync process, rather it is taken as a request that needs to be fulfilled later. For example when a Sync process is requested an app could be offline but SyncService still accepts the request through the “sync” method call and fulfills it when the conditions are right for the data transfer.
System sync
SDK initiates a Sync process without any apps requesting when SDK detects that the local and the cloud secondaries are out of sync.
Please look at SyncService Dart code docs for more details on the usage.
When a sync request is submitted, SyncService waits for the following conditions to be fulfilled for the Sync process to be triggered:
Note: These internals are subject to change in future versions of SDK