Logging and error handling

Logging

The Unblu SDK uses a configurable internal logger.

The default value of the log level is VERBOSE. In release builds, however, the VERBOSE and DEBUG logs are removed with ProGuard rules.

You can change the log level by means of the Unblu.setLogLevel method.

By default, the logger doesn’t print any security-relevant information or additional details. To change this behavior for debugging purposes, set Unblu.enableDebugOutput to true.

To get logs about mobile co-apping performance, set Unblu.enableCapturingPerformanceLogging to true. For this the log level has to be DEBUG or less and also the enableDebugOutput flag has to be enabled.

If, for security reasons, you want to strip out the complete log statements from the compiled app, check out the Log stripping^ section of the article Security-relevant configuration^ first.

Error handling

Errors can occur either during initialization or at runtime. The error types are defined in the package com.unblu.sdk.core.errortype.

Initialization errors

If an error occurs during initialization, the user can’t use Unblu.

Errors during initialization are returned via the InitializeExceptionCallback callback passed to the initialization method (see Code setup and initialization^).

You should either inform user that Unblu is momentarily unavailable or ensure that the Unblu integration isn’t displayed in your app to prevent users from trying to access the Unblu UI.

Runtime errors

Most error types are returned on the callback of the method call they’re associated with. For example, if an error occurs when you try to start a mobile co-apping session by calling UnbluConversation.startMobileCoBrowsing, the MobileCoBrowsingExceptionCallback contains a MobileCoBrowsingErrorType.

Runtime errors can also be emitted with the Unblu.onError event. The event returns an ErrorData object containing an UnbluClientErrorType.

How you should handle runtime errors depends on the specific error type. Most runtime errors aren’t fatal, but the following errors require you to deinitialize and reinitialize the SDK:

Offline behavior

The mobile visitor UI provided by the mobile SDK depends heavily on the connection to the Unblu Collaboration Server. However, losing the connection to the Collaboration Server doesn’t result in an error.

If the mobile SDK is no longer connected to the Collaboration Server, it attempts to establish the connection again. After a brief time period, it displays a banner informing the user that it’s attempting to reconnect to the server.

While this is happening, any chat messages the user enters are stored in the local storage and queued. In the UI, such messages are displayed with an icon showing that they’re pending.

Once the mobile SDK has reconnected to the Collaboration Server, it sends the queued messages.

When the mobile SDK isn’t connected to the Collaboration Server, users can navigate out of the current conversation and see the last state of the list of conversations. However, they can’t reconnect to a conversation, even if they viewed it earlier. If they tap a conversation to open it, Unblu displays the loading indicator. Since they’re offline, the conversation doesn’t load, and Unblu subsequently displays a timeout dialog.

Attempts to deinitialize and reinitialize the mobile SDK while it doesn’t have a connection to the Collaboration Server fail. Initialization is only possible with a connection to the Collaboration Server.