Messaging events and service responses are redirected to a store interface implementation inside your app that you register on SDK initialisation.
First you must provide a CMPStoreFactoryBuildable
protocol conforming object when initialising the SDK.
Its only method completion should in return provide CMPChatStore protocol
conforming object with all its persistence layer methods. Once we have the implementations of both protocols, we can pass the factory object to the config object:
// create an instance of CMPStoreFactoryBuildable implementing class and keep reference to it somewhere
ChatStoreFactoryImplementation *factory = [ChatStoreFactoryImplementation alloc] init];
// create a config builder
CMPComapiConfigBuilder<CMPChatConfig *> *builder = [CMPChatConfig builder];
// create a config object with your api-space-id and an object conforming to CMPAuthenticationDelegate protocol;
CMPChatConfig *config = [[[[[builder setApiSpaceID:<YOUR_API_SPACE_ID>]
setAuthDelegate:<CMPAuthenticationDelegate_Conforming_Object>] setChatStoreFactory:factory]
build];
[CMPChat initialiseWithConfig:config completion:^(CMPComapiChatClient * _Nullable client) {
if (client) {
// we can use the client object now
}
}];
@interface ChatStoreImplementation : NSObject <CMPChatStore>
// Implementation of chat store class that provides a way to store data relevant both to SDK and the app.
@end
@implementation ChatStoreImplementation
// Provide implementation for all the CMPChatStore protocol's methods, as well as other methods you might need.
@end
This implementation queues changes in a single pending transaction and performs the db inserts/update when the endTransaction
method is called. The underlying data should be synchronised, since the transactions can be performed in different threads.
The SDK internally calls below methods to start queuing changes and to tell the store to apply the changes:
// begin transaction, from this point calling other methods of this class will queue store updates and inserts to be executed when {@link ChatStore#endTransaction()} on same instance is called
[store beginTransaction];
// end transaction, execute queued store updates and inserts
[store endTransaction];
The below methods that need to be implemented are used by the SDK to keep the local chat data inside your database consistent with the server.
// Get conversation with ID.
- (CMPChatConversation *)getConversation:(NSString *)ID;
// Get all stored conversations.
- (NSArray<CMPChatConversation *> *)getAllConversations;
// Update or insert a conversation.
- (BOOL)upsertConversation:(CMPChatConversation *)conversation;
// Update a conversation.
- (BOOL)updateConversation:(CMPChatConversation *)conversation;
// Delete a conversation for ID.
- (BOOL)deleteConversation:(NSString *)ID;
// Update or insert a new message.
- (BOOL)upsertMessage:(CMPChatMessage *)message;
// Update message status.
- (BOOL)updateMessageStatus:(CMPChatMessageStatus *)messageStatus;
// Delete all messages.
- (BOOL)deleteAllMessages:(NSString *)conversationID;
// Delete message in conversation with ID for given messageID.
- (BOOL)deleteMessage:(NSString *)conversationID messageID:(NSString *)messageID;
// Clear the database from existing entries.
- (BOOL)clearDatabase;
// Begin a transaction.
- (void)beginTransaction;
// End a transaction.
- (void)endTransaction;
The upsert and update methods can provide more information than is required by GET methods. This additional data can be safely ignored.
Core data example
We provide a full implementation example using Apple's CoreData framework.
The above sample makes use of a separate CoreData manager class with a single NSManagedObjectContext
for simplicity.
The models are mapped almost one-to-one to what the Chat SDK provides. Each model provides a direct mapping (to and from) its SDK counterpart. You can check the xcdatamodeld file here, as well as separate model classes here. You are free to map your models however you like as long as the consistency of data remains.