Перейти к содержанию

Рекомендации по использованию Webim Mobile SDK

В этом материале описаны наиболее частые проблемы, которые встречаются при разработке/использовании мобильного приложения на базе Webim Mobile SDK, их пути решения, а также полезные рекомендации для разработчиков.

№1 При открытии чата в мобильном приложении сразу закрывается сессия

При возникновении критической ошибки при подключении к серверу сессия может закрываться сама, т.к. при возникновении такого рода ошибки, ей больше нельзя пользоваться.

В таком случае рекомендуется обрабатывать критические ошибки методом onError интерфейса FatalErrorHandler и вызывать .setErrorHandler(FatalErrorHandler) при настройке сессии. Под обработкой в этом случае подразумевается показ сообщения об ошибке и/или попытка создать новую сессию.

Также в мобильном приложении рекомендуется проверить, обрабатывает ли оно все критические ошибки, которые могут прийти с сервера.

№2 При первом сообщении из мобильного приложения кнопочный бот отправляет первое сообщение дважды

Такое может быть, если для отдела, в котором ведётся чат, задана настройка "Посетитель должен задавать вопрос первым", но при этом в мобильном приложении это не учтено: в таком случае, при старте чата из мобильного приложения, первое сообщение посетителя будет отправлено не как первый вопрос, а как обычное сообщение. Для избежания подобных ситуаций в мобильном приложении следует использовать метод startChatWithFirstQuestion.

№3 Невозможно начать чат в мобильном приложении, отправив файл

В этом случае, стоит проверить используемую вами версию SDK на наличие возможности начинать чат отправкой файла. По умолчанию, метод sendFile проверяет наличие активного чата перед отправкой файла. Если чата в сессии нет, то метод возвращает ошибку. Для уточнения функциональных возможностей используемой вами версии SDK обратитесь, пожалуйста, в техническую поддержку.

№4 Лаги сервера при одновременном открытии большого количества сессий

В некоторых мобильных приложениях, основанных на Webim Mobile SDK, реализована функциональность получения информации о количестве непрочитанных сообщений. В силу технических особенностей Webim получить количество непрочитанных сообщений можно получить только при наличии активной сессии, из-за чего нередки случаи сильных и продолжительных лагов Webim Server. Это связано с тем, что большое количество одновременно открытых сессий создаёт большую нагрузку на сервер. Если в вашем мобильном приложении реализована описанная выше функциональность, рекомендуется в приложении сделать следующее:

  • Оставлять сессию активной только при открытом экране с чатом

  • Если требуется обновить данные - запускать сессию только для обновления этих данных и останавливать её сразу же после получения обновления.

    N.B.

    Если ChatState соответствует none/closed, то сессию можно закрыть, так как в неактивном чате число непрочитанных сообщений не изменяется. Отслеживать это можно через ChatStateListener.

  • В остальных случаях активной сессии в мобильном приложении быть не должно

№5 Посетитель авторизовался в одном мобильном приложении на разных устройствах/в нескольких мобильных приложениях на одном устройстве, но push-уведомления приходят не на все из них

В случае, если посетитель авторизуется через мобильное приложение с использованием Webim Mobile SDK, связанные с чатом поддержки push-уведомления будут приходить ему на все устройства и во все приложения, где он авторизован с использованием своего visitor_id и/или provided_visitor_id, т.е. в случае, если на одном устройстве имеется несколько мобильных приложений, связанных с одним сервером Webim, то уведомления, например, о новом сообщении придут во все эти приложения (или на все устройства, где установлено мобильное приложение и выполнена авторизация). В случае, если push-уведомления приходят не на все приложения/устройства, то рекомендуем убедиться в том, что во всех случаях авторизации одному и тому же посетителю присваивается один и тот же идентификатор (visitor_id или provided_visitor_id).

№6 Что будет, если создать для одного посетителя несколько сессий в разных размещениях?

Поведение сервиса и SDK для таких случаев не определено. Мы настоятельно рекомендуем вам создавать только одну сессию для одного посетителя.