SyncManager Android v1
SyncManager Android
SyncManager
Android
Home
/
SyncManager
/
Android

Local caching

Local caching is a better option than SyncManager for Android for rapid access to the data from the local cache and Sendbird server. If you are currently using SyncManager, we strongly encourage you to migrate to the Chat SDK with local caching for enhanced usability and easier maintenance.

Note: SyncManager will be deprecated soon.

The following table displays the full range of differences between local caching and SyncManager.

Local cachingSyncManager

Implementation

Integrated to Chat SDK

Add-on to Chat SDK

Architecture

View-driven

Event-driven

Synchronization

Changelog sync and background sync

Background sync

Auto resend

Supported

Not supported

One distinct advantage of local caching over SyncManager is that it provides an event context and a callback for identifying what changes are made to which group channels and messages. This facilitates locating and debugging issues in those channels.

SyncManager relies on an event-driven architecture where its collection handlers receive all events that pass through the WebSocket connection along with the data in the local cache. In contrast, local caching relies on a view-driven structure where only those events that directly affect the user’s channel list and chat view are delivered to their respective collections.

Another advantage of local caching is that messages that were not sent the first time are automatically resent at a later time. When the WebSocket connection is lost, messages considered “pending” are stored locally until the connection comes back on, at which point the pending messages are automatically sent. This new functionality unique to local caching is called auto resend.

Note: SyncManager will continue to work if the dependency to SyncManager is not removed. The dependency should be deleted once the migration to local caching is completed.


Initialization

You can initialize the Chat SDK with or without local caching. The useLocalCaching is the boolean that determines if you are going to be using local caching. By default, the Chat SDK is initialized without local caching, the useLocalCaching set to false. If the useLocalCaching is set to true, the Chat SDK is initialized with local caching.


In local caching, the InitResultHandler() is added to the SendBird.init() method, which receives the initialization status through different event handlers. The onMigrationStarted() is called when there is a change in the local cache. Meanwhile, the values of the onInitSucceeded() and the onInitFailed() let the client app know whether the Chat SDK has been successfully initialized.

Note: If initialization fails to complete and the onInitFailed() is called while the useLocalCaching is set to true, Chat SDK will operate as if the useLocalCaching is set to false.

Connect to Sendbird server

Local caching and SyncManager are alike in keeping chat in the client app up-to-date even when the app is not connected to Sendbird server. The key difference between SyncManager and local caching at the initialization stage is that local caching requires calling the SendBird.connect() after the SendBird.init(). Calling the SendBird.connect() after the SendBird.init() is optional when using SyncManager because the SyncManager.setup() is called immediately after the SendBird.init() during the initialization process. Calling the SendBird.connect() after the SendBird.init() is required when using local caching because some platforms receive the result of SendBird.init() as a callback.

Local cachingSyncManager
// Initialize with the useLocalCaching set to true.
SendBird.init(APP_ID, getApplicationContext(), true, new InitResultHandler() {
   @Override
   public void onMigrationStarted() {
       Log.i("Application", "Called when there's a change in the local database.");
   }

   @Override
   public void onInitFailed(SendBirdException e) {
       Log.i("Application", "Called when initialization failed.");
   }

   @Override
   public void onInitSucceed() {
.       Log.i("Application", "Called when initialization is done.");
   }
});

SendBird.connect(userId, new SendBird.ConnectHandler() {
   @Override
   public void onConnected(User user, SendBirdException e) {
       if (user != null) {
           if (e != null) {
               // Proceed in offline mode with the data stored in the local database.
               // Later, connection will be made automatically
               // and can be notified through the ConnectionHandler.onReconnectSucceeded().

           } else {
               // Proceed in online mode.
           }
       } else {
           // No user is available.
           // Handle error.
       }
   }
});

Other methods

Below you will find the new cache-related interfaces that come with local caching. Local caching’s clearCachedData() replaces the functionality of SyncManager’s clearCache(), which deletes the entire data file. In addition, the clearCachedMessages() and the getCachedDataSize() are available in local caching. The following table displays a full description of each method and if the method should be called before or after the SendBird.init().

MethodDescription

clearCachedData()

- Deletes the entire data file.
- It must be called before the SendBird.init().

clearCachedMessages()

- Clears cached messages in a specific channel.
- It must be called after the SendBird.init().

getCachedDataSize()

- Checks for the current cached data size.
- It can be called before or after the SendBird.init().

Local cachingSyncManager
SendBird.clearCachedData(Context, CompletionHandler);
SendBird.clearCachedMessages(CHANNEL_URL, CompletionHandler);
long cacheDataSize = SendBird.getCachedDataSize(Context);