Logging and error handling

The Unblu SDK uses an internal Logger that you can configure to meet your needs.

By default, the logger doesn’t print any potentially security related information. To change this behavior for debugging purposes, set the flag UnbluClient.enableDebugOutput to true. You can change the log level using the field UnbluClient.logLevel.

For mobile co-apping, you can also enable performance logging. This is done via the UnbluMobileCoBrowsingModuleConfiguration object used to configure the UnbluMobileCoBrowsingModuleApi. For performance logging, set UnbluClient.logLevel to .debug or lower and ensure the UnbluClient.enableDebugOutput flag is enabled.

Error handling

You can get an UnbluClientErrorType error while initializing the SDK in the start(_:) function’s completion handler or after a successful initialization in the UnbluClientDelegate delegation protocol.

Most types of error are fatal and the main SDK functions no longer work properly. When such an error occurs, you should prevent users from accessing the Unblu UI and inform them that the Unblu functionality is momentarily unavailable.

There are two non-fatal errors:

If one of the above errors occurs, you can pass a valid token, for example by verifying that the user is logged in. Later, you can try to restart the API if the error occurred on startup. If it’s a runtime error received in UnbluClientDelegate, continue as usual.

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.

Troubleshooting encrypted notifications and incoming calls

Before you start, set UnbluClient.enableDebugOutput to true so that the SDK logs the diagnostic messages referred to in this section. For more information about enabling debug output and setting the log level, see the introduction to this article.

Notifications fail to decrypt

When an encrypted notification can’t be decrypted, it’s delivered without its content: the notification appears empty, and an incoming call shows an unknown caller.

The most common cause for this is that the keychain group is misconfigured, so the notification service extension can’t read the decryption key. Check that both the app target and the extension target declare the keychain group as described in the notification service extension setup.

To confirm that decryption fails, look for the Failed to decrypt message in the logs; see Diagnostic log messages below.

If notifications still aren’t decrypted after you verify the setup, test on a second device to rule out a stale entry in the keychain.

Accepting or declining a call has no effect

If the user accepts or declines an incoming call before the Unblu client has initialized, the SDK defers the action until initialization is complete. Only then does it accept or decline the call. If the Unblu client never initializes—for example, because the app doesn’t start it on launch—the accepted call never opens.

Make sure your app initializes the Unblu client on launch, as described in Accepting a call before the app has initialized.

The log message Failed to open conversation, after it was requested by notification. No delegate assigned. indicates that a call was accepted before the client was ready.

Diagnostic log messages

The following log messages help you diagnose issues with encrypted notifications and incoming calls:

registerPushNotificationToken received shared: The device received the decryption key from the Collaboration Server.
Failed to decrypt: The notification service extension couldn’t decrypt a notification.
Attempting to open conversation, after it was requested by notification.: The SDK is opening a conversation in response to a notification.
Failed to open conversation, after it was requested by notification. No delegate assigned.: The SDK deferred opening a call or conversation because the Unblu client wasn’t initialized.