The EkoClient
class also provides a variety of account and error handling methods. Please make sure to first instantiate an instance of EkoClient
before using any of following.
The displayName
is an optional property that helps other users identify a user. It is mainly used for push notifications in order to identify the sender of a message, but you may also use this property for displaying user data in the UI.
Keep in mind that the SDK does not handle user management: if your UI requires to display more complex user data (e.g. age, title, avatar ..etc), we recommend you to build this functionality directly into your application/backend.
Display names are usually set on registerDevice:
, however, you may also set it after device registration with the following method:
client.setDisplayName("John Appleseed") { success, error in...}
EkoClient
class provides hasPermission:
methods which allows to check if the current logged-in user has permission to do stuffs in given channel. Permissions are tied to roles and can be configured from admin panel.
hasPermission:
method checks the permissions in global scope.
hasPermission(channel: )
andhasPermission(community:)
checks for permissions in both global scope and channel/community scope. If current user has permission in either global or channel/community scope, it returns true.
User
payload contains an optional property called metadata
that allows you to store specific data on each user. It is used mainly to store user avatar urls (which we do not provide on our side). You may also use this property for displaying user meta data in the UI or any other purposes. The format of the metadata will be a dictionary
object.
client.setUserMetadata({"position": "Customer Support"}) { success, error in...}
Error objects can be returned to you via LiveObjects, callbacks, or clientErrorDelegate
. All the errors returned by the SDK come in form of an NSError with domain Eko
. The possible error codes are listed in a public EkoErrorCode
enum: each case is named after its error and they're pretty self explanatory.
The SDK will automatically handle all recoverable errors such as connection state errors without notifying you. For example, if you try to perform an action while the client is offline, the SDK will automatically retry until the action is successful. As a result, any errors return by the SDK are due to unrecoverable business errors.
The error codes are always six digits, with the first three identifying the type of error, and the latter three digits identifying the specific error. Errors that are originated from the server start with 400 (therefore the server error codes will be 400xxx) and 500 (500xxx), while client errors start with 800 (800xxx).
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
GlobalBanError: 400312
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
includes a clientErrorDelegate
property that can be set to an error handler delegate class on your application. This error delegate gives you a chance to be notified of errors that can potientially 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.