Miscellaneous

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.

Display Name

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
...
}

Permissions

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: ) and hasPermission(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 Metadata

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 Handling

Error Codes

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).

Server Errors

  • 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

Client Errors

  • 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.

Asynchronous Errors

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.