Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Let users react to messages, posts, and comments, which are visible to others.
This functionality is not currently supported for Web but will be coming soon! We will update the relevant sections accordingly
Let your users showcase their unique personality right in their timelines
Feed is a new way for users to create content on various areas of the SDK. Currently, users and groups can have feeds. Each feed consists of a collection of posts. Users are able to create posts on any groups that they are a member of and any user that they can find.
There is a global feed which is an aggregate of all the posts in a user's feed.
Feed management methods are all contained in a FeedRepository
class.
You can get any user's feed by calling the method below with the userId
:
There is a quick easy method to get your own feed:
You can get any group's feed by calling the method below with the communityId
:
You can retrieve your global feed by calling the following method:
Plug in this module to enable social features such as Feeds, Groups, Profiles, Content Posts, and Social Media Type Interactions
Foster a sense of belonging among your community and make your app a safe place for your users to connect and interact with others.
Before using the Social SDK, you will need to create a new SDK instance with your API key. Please find your account API key via the Admin Panel. If you have trouble finding this, you can send our support team an email at developer@amity.co
In order to use any Social SDK features, you must first register the current device with an userId
. A registered device will be tied to the registered userId
until the device is either proactively unregistered, or until the device has been inactive for over 90 days. A registered device will receive all the events messages belonging to the tied user.
An optional displayName
can be provided, which will be used in standard push notifications (related to user's actions, such as when the new message is sent).
The
displayName
is set only on the first time the device is registered, please follow your platforms necessary directions if you would like to rename this to something else.
When the user logs out, you should explicitly unregister the user from the SDK as well. This prevents the current device from receiving unnecessary and/or restricted data.
Each user can be registered, at the same time, to an unlimited number of devices. Amity's Social SDK will automatically synchronize the user data across all registered devices. We will also automatically unregister any device that has not been connected to the server for more than 90 days.
When a device is unregistered due to inactivity, the SDK data on the device will be reset. You will need to re-register this device in order to connect to server again.
If you have any logic or UI around the connection status, you can observe the connectionStatus
property on the EkoClient
instance.
Since the SDK automatically manages the network connection and queue up any requests in cases of bad connection, there should be little need to attach additional logic to this status. However the user may want to know the exact network status to determine if their actions will be performed in real-time, therefore this status is exposed.
You can also be notified about connectionStatus
changes via the connectionStatusChanged
event.
Our Sample app adopts an open source framework that highlights how Amity Social Cloud SDK's can be implemented into application builds pragmatically.
With real life use-cases, we guide you through ways you can get started with building stellar applications for yourself and your clients and their users
Download the Web sample app
Here's an overview of posts and how you can get started with integrating them into your applications
A feed is made up of a collection of posts. Users are able to generate different types of posts as well as to react and comment on posts.
When creating a text post, call the following method:
Note. A post can consist of either a list of images or a list of files but not both.
If text, image, and file types post are not enough for you. You can create your own type with whatever data you need for rendering. To do this, you need to call PostRepository.createPost
and pass dataType
, a string that defines the type of the post so you can distinguish your new post from others, and data, an object containing whatever data you need for your post.
You can use the postForId()
method in order to get a single post:
Note. Only the post owner or an admin are able to update and/or delete a post.
As well as the general creation of posts, users are also able to interact with posts using the PostRepository
. This repository's main purpose is to manage posts, reactions, and flags on a post.
You can add a reaction to a post by calling the following method:
You can also add a comment to a post using our Comment feature:
See more on Comments
You can flag a post as inappropriate using the following method:
Here's an overview of how you can get started integrating comments into your applications
Comments are a way to create comments for a particular piece of content without needing to join a channel or manage channel memberships.
Amity Social SDK provides support for common text in comments.
All comment methods are contained in a CommentRepository
class. Before calling any comment methods, you must ensure to import it.
All comment sending methods are designed to be robust enough to work under any network conditions. When you send any comment, that comment will automatically placed into a queue in case of unstable network conditions. Once the SDK reconnects to the server, it will automatically resend all queued comments.
Additionally, sent comments are always returned in comment queries, even before they have been delivered to the server. It is done to provide the user with a fluid commenting behavior: when a user sends a comment, that comment would appear in the comment list right away, instead of waiting until it has been confirmed by the server.
Unlike messages, comments are directly tied to a specific referenceId
that is managed by the client. The referenceId
has to be unique but can be any string.
Sending a standard text comment is a simple method, call referenceId
and the message text:
To query for a list of comments in a post:
This method will return a LiveCollection of comments in the specified referenceId.
A comment can be a root for a thread. To query the children of a comment thread, you can add the parentId
parameter in a comment query, along with the filterByParentId
flag.
When creating a comment, we can also pass the parentId
to make it appear under the parent.
To flag a comment, call the following method:
To unflag a comment, call the following method:
The User can also check if they have previously flagged the comment before by calling the following asynchronous method:
You can only perform edit and delete operations on your own comments. Once the operation is complete, the comment's editedAtDate
will be set to the current time. This allows you to provide UI to the user to inform the user of specific messages that has been edited, if needed. An optional completion block can be provided to notify you of operation success.
All data returned by the SDK are wrapped in the SDK's LiveObject API. The LiveObject API allows you to easily retrieve the queried data asynchronously, as well as subscribe to any new changes to the data.
Observing live changes to any object queries can be done by observing the dataUpdated
event on the LiveObject:
In this example the block observes the data of the currently authenticated user and prints out the displayName
. The observe block can be called multiple times throughout the lifetime of the application:
If the requested object data is stored locally on the device, the block will be called immediately with the local version of the data (you can verify this through the dataStatus
property).
In parallel, a network request for the latest version of the data is fired. Once the network returns the data, the observe block will be called again with the updated data.
Any future changes to the data (whenever the user changes its displayName
on another device, for example) can trigger additional callbacks.
We recommend you to always call removeAllListeners()
whenever you are done observing event to avoid any unnecessary callbacks.
The data provided by LiveObject is directly accessible via the model
property. The model
property is always kept up to date with the latest state changes; every time when dataUpdated
event is fired, the model
property has already been updated.
If in your UI you want to exclusively display fresh data (without using the potientially out-of-date local data), you can do so by reading the object's dataStatus
property, which reflects the status of the callback data, and check that its value is set to fresh.
You can also use the object's loadingStatus
property to determine the current state of network operations being performed by the LiveObject. This is useful for any UI element that needs to provide the loading state.
The LiveObject can also emit events for updates for dataStatus
as well as loadingStatus
. As with other events, please make sure to call removeAllListeners()
when you are done observing changes to these values in order to prevent memory leaks.
The LiveObject updates statuses and data in strict order and emits related events accordingly when an instance is created. Few different cases might occurs when you create a LiveObject instance:
Initial values:
loadingStatus
= EkoLoadingStatus.Loading
dataStatus
= EkoDataStatus.NotExist
model
= undefined
Process received data:
emits loadingStatusChanged
emits dataStatusChanged
emits dataUpdated
Initial values:
loadingStatus
= EkoLoadingStatus.Loading
dataStatus
= EkoDataStatus.Local
model
= localData
Process received data (same order):
emits loadingStatusChanged
emits dataStatusChanged
emits dataUpdated
- only if data is really different
loadingStatus
= EkoLoadingStatus.Loaded
dataStatus
= EkoDataStatus.Fresh
model
= localFreshData
The LiveObject API supports queries that return a list of objects, this is known as a LiveCollection. LiveCollection has the same methods and properties as its object counterpart, but contains a few other helper methods around pagination.
Pagination with LiveCollections is very simple: the collection offers a convenient nextPage
method that you can call which will automatically trigger a local cache lookup, a network call, and multiple LiveObject updates once new data is returned. Every collection starts with one page of 20 models. After nextPage()
is successful, the dataUpdated
event will be triggered with a new array combining both the old objects as well as 20 newly fetched objects.
You can use the
hasMore
property to determine if you've scrolled to the end of the list. ThehasMore
property initially returns 'false' until the first collection query is finished.
Lastly, if there is a need to shrink the list of objects exported back to only the first 20 records (for example, if you pass the LiveCollection object to a new view), you can simply call resetPage()
.
Similar to model
property of the LiveObject, the LiveCollection provides models
property what is basically is an array of LiveObject's model
objects. models
is mutable and always contains same data as one what returned by dataUpdated
event.
Both LiveObject and LiveCollection can be subscribed to the dataError
event which is fired every time an error happens during the data update process. In other words, every time the LiveObject or LiveCollection fails to get data from the server - this error will be emmited.
We recommend you to always call dispose()
whenever you are done working with any LiveObject/LiveCollection.
Dispose is a very important functionality of the LiveObject. It allows you to avoid memory leaks and keeps your application performant. What does dispose()
do:
unsubscribe all listeners attached to the LiveObject instance;
stop all internall observers related to the LiveObject instance;
clean up an internall buffer of the LiveObject instance;
After you call dispose()
on a LiveObject instance, dataStatus and loadingStatus switch to Error
.
Error objects can be returned to you via LiveObjects, callbacks, or from the error
event emitted by the EkoClient
instance. The possible error codes are listed in a public ErrorCode
object: each case is named after its error and they're pretty self explanatory.
UnauthorizedError: 400100
ItemNotFound: 400400
BadRequestError: 400000
Conflict: 400900
ForbiddenError: 400300
PermissionDenied: 400301
UserIsMuted: 400302
ChannelIsMuted: 400303
UserIsBanned: 400304
NumberOfMemberExceed: 400305
ExemptFromBan: 400306
MaxRepetitionExceed: 400307
BanWordFound: 400308
LinkNotAllowed: 400309
BusinessError: 500000
Unknown: 800000
InvalidParameter: 800110
MalformedData: 800130
ErrorQueryInProgress: 800170
ConnectionError: 800210
When an error is returned as a result of an action from your side (e.g. trying to join a channel), the action is considered completed and the SDK will not execute any additional logic.
The EkoClient
emits a dataError
event that can be observed by your application. This error event gives you a chance to be notified of errors that can potentially break the functionality of the SDK. The SDK logic is usually robust enough to automatically handle most errors, as such, only unrecoverable errors are exposed through this delegate (for example, if the login session was invalidated).
We recommend you to always handle these errors in a production app by gracefully disabling messaging functionality in the event of an error.
added error for comment live object when create new comment
fixed user reporting
Removed check for comments since post contains only comments without replies
recalculate comments counter for replies
clean in-memory cache when the session is reset
added user displayName to comments output
fixed crash of file uploading
force unix line ending for windows
added withCredentials() so the cookie gets saved
Allowed avatarCustomUrl to be passed to show avatars which are stored in the external systems
Added case insensitive community search
You can now create custom posts
PostRepository.createPost({ dataType: string, data: Object })
Comment
Fix the issue of fetching X comments with first / last sorting in CommentRepository.queryComments(parameters: Object)
Reaction
Normalized API accross the SDK
Post
PostRepository()
PostRepository.postForId(postId: string)
PostRepository.createPost(postType: string)
PostRepository.updatePost({ postId: string, data: Object })
async PostRepository.deletePost(postId: string)
async PostRepository.addReaction(postId: string)
async PostRepository.removeReaction(postId: string)
async PostRepository.flag(postId: string)
async PostRepository.unflag(postId: string)
async PostRepository.isFlaggedByMe(postId: string)
Comment
CommentRepository()
CommentRepository.queryComments(parameters: Object)
CommentRepository.commentForId(commentId: string)
CommentRepository.createComment(parameters: Object)
CommentRepository.editComment({ commentId: string, data: Object })
async CommentRepository.deleteComment(commentId: string)
async CommentRepository.addReaction(commentId: string)
async CommentRepository.removeReaction(commentId: string)
async CommentRepository.flag(commentId: string)
async CommentRepository.unflag(commentId: string)
async CommentRepository.isFlaggedByMe(commentId: string)
User
UserRepository.getAllUsers(sortBy?: EkoUserSortingMethod)
UserRepository.searchUserByDisplayName(search: string)
Ensure that your users don’t miss important content from each other.
This functionality is not currently supported for Web but will be coming soon! We will update the relevant sections accordingly
This page will guide you through the steps you need to take to integrate community chat groups into your applications for Web
When creating a new community, first instantiates the CommunnityRepository
, a class that contain all community related methods. Then call createCommunity()
to obtain the LiveObject and observe it in order to obtain the final community model.
Note that the event listener was registered using once()
. Unlike on()
, once()
will automatically unregister the event listener once the first event was emitted. This is useful if you just need to use the model once but do not need to listen to further events.
In the case where you only want to fetch communities data without joining, you can use the communityForId()
method:
There are methods to obtain communities that only match specific criteria:
the search
parameter let you filter communities based on the community displayName
the isJoined
parameter let you filter communities based on the logged in user membership status
the tags
parameters let you filter communities based on the tags set (or not set) in each community
the categories
parameters let you filter communities based on community categories
the sortBy
parameters let you filter communities based on the order that the communities were created or based on alphabetical order
If you want to update a community, you can call the following:
Note. By default, only the communities original creator or adminstrators can update the community.
You can get a list of community members by calling the following method:
The CommunityRepository
will also be able to manage community categories. When community are put into a category, you will be able to sort and filter each of the community in that category.
Note. Right now categories will only be creatable and updatable from the admin panel.
You can fetch a particular category by calling the categoryForId()
method:
You can also fetch a list of categories:
This method provides the ability to obtain all the categories.