Source: https://rox.chat/kb/mobile/sdk/recommendations-of-usage.html

> This article describes the most common problems encountered when developing/using a mobile application based on Rox.Chat Mobile SDK, their solutions, and useful recommendations for developers.

# Recommendations for Using Rox.Chat Mobile SDK

This article describes the most common problems encountered when developing/using a mobile application based on **Rox.Chat Mobile SDK**, their solutions, and useful recommendations for developers.

## #1 When opening a chat in the mobile app, the session closes immediately { #1 }

If a critical error occurs when connecting to the server, the session may close itself, because when such an error occurs, it can no longer be used.

In this case, it is recommended to handle critical errors using the `onError` method of the `FatalErrorHandler` interface and call `.setErrorHandler(FatalErrorHandler)` when setting up the session. Handling in this case means showing an error message and/or trying to create a new session.

It is also recommended to check if the mobile app handles all critical errors that may come from the server.

## #2 When sending the first message from the mobile app, the pushbot sends the first message twice { #2 }

This can happen if the department in which the chat is running has the setting *"Visitor should ask a question first "*, but the mobile app does not take this into account: in this case, when starting the chat from the mobile app, the first message of the visitor will be sent not as the first question, but as a regular message. To avoid such situations in the mobile app, the `startChatWithFirstQuestion` method should be used.

## #3 Unable to start a chat in the mobile app by sending a file { #3 }

In this case, it is worth checking the SDK version you are using to see if it is possible to start a chat by sending a file. By default, the `sendFile` method checks for an active chat before sending a file. If there is no chat in the session, the method returns an error. Please contact [technical support](mailto:support@rox.chat) to clarify the functionality of the SDK version you are using.

## #4 Server lags when opening a large number of sessions at the same time { #4 }

Some mobile applications based on **Rox.Chat Mobile SDK** have functionality to get information about the number of unread messages. Due to technical peculiarities of **Rox.Chat** it is possible to get the number of unread messages only when there is an active session, because of which it is not uncommon to experience severe and long lags of **Rox.Chat Server**. This is due to the fact that a large number of simultaneously open sessions creates a heavy load on the server. If the functionality described above is implemented in your mobile application, it is recommended to do the following:

  * Keep the session active only when the chat screen is open

  * If you need to update data - start the session only to update this data and stop it immediately after receiving the update.

    !!! Note "N.B."
        If `ChatState` matches `none/closed`, the session can be closed, as the number of unread messages does not change in an inactive chat. This can be tracked via the `ChatStateListener`.

  * In other cases, there should be no active session in the mobile app

## #5 A visitor has authorized in the same mobile app on different devices/in multiple mobile apps on the same device, but push notifications are not coming to all of them { #5 }

In case a visitor authorizes through a mobile app using **Rox.Chat Mobile SDK**, support chat related push notifications will come to him/her on all devices and in all apps where he/she is authorized using his/her `visitor_id` and/or `provided_visitor_id`, i.e. in case there are several mobile applications connected to one **Rox.Chat** server on one device, notifications, for example, about a new message will be sent to all these applications (or to all devices where the mobile application is installed and authorized). In case push notifications are not sent to all applications/devices, we recommend to make sure that in all authorization cases the same visitor is assigned the same identifier (`visitor_id` or `provided_visitor_id`).