When implementing the Verint XM Android SDK, it is possible that issues may arise from the particular environment in which the SDK is being used. This article aims to summarize and address some of the most common problems that may be encountered.
There are a number of reasons the invitation may not be showing. Verify the following items when testing the display of invitations:
- Ensure you have a working network connection that is not being restricted by a firewall or proxy. The SDK must be able to contact Verint servers before the invitation can be displayed.
- Ensure that the invitation is not being declined due to a failed sampling check. If your sampling check is set to less than 100%, you may find it useful to call
ForeSee.setSkipPoolingCheck(true)to skip the check.**Note:** The skip method should not be used in your production environment.
- Ensure you start from a 'Tracking' state. Once it has displayed an invitation, the SDK changes state to restrict the number of invitations shown to the same user. The state can be reset by one of the following:
- Uninstall and reinstall the app.
- Go to Settings > Apps > Your app and select 'clear data'.
ForeSee.resetState(). This also resets all other SDK information including the launch count, first launch date, and any significant events. As such, this call should not be made in the production environment.
- Verify that you are calling
ForeSee.checkIfEligibleForSurvey()in the correct place. Calls placed in an Activity's
onCreate()method are only executed when that activity is first created or after the activity is completely removed from memory. To check for eligibility every time the user switches to the app, add the check to the main activity's
- Verify you are meeting the Trigger criteria. If you require five launches in your configuration file, make sure the app has been launched five times.
See Custom Touch Capture for instructions on how to deal with custom controls where touches are not captured.
Some views which implement their own onTouchListeners have trouble receiving touches when Replay is enabled. In these instances, there are a couple of possible workarounds, which are described in the Custom Touch Capture article.
Due to the limitations of the Android operating system, capture can become slow when the screen becomes complex or intensive to draw. One example of this is when full screen bitmaps are manipulated on large screen devices such as tablets.
The screen must be rendered on the UI thread and, when this process takes a long time, the impact on the UI thread becomes noticeable as a jerky response to touches or skipped frames in animations.
Verint has taken great care to minimize this effect, but it may still be necessary to adjust the behavior of the recorder to suit particular situations - if your app makes use of large and/or complex animations, for example.
Workarounds to this issue are discussed in the Custom Image Capture article.
Dalvik errors usually occur in the
.dex compilation process for one of two reasons:
- The project uses a library which is already used by the SDK.
Packages can only be added to the
.dexfile once. If there are two dependencies which implement the same library, a conflict occurs. In these cases, Verint has provided a ’no-deps’ version of our SDK which should help solve the issue. Details on how to implement this version of the SDK can be found in the Dependencies article.
- Project contains too many functions.
The size of a
.dexfile is limited by the number of functions in the app and libraries combined. It is possible to use multiple
.dexfiles, but an easy way to reduce the number of functions is to run ProGuard on the project to remove the unused portions of dependencies. Information on how to use ProGuard can be found here. It is not necessary to run ProGuard on the SDK as the library has already been optimized.
A drop in respondents can occur for a number of reasons:
- A change in the SDK has produced a change in behavior. For example, a fix was made in v3.2 of the SDK which means fewer users are successfully sampled. This would affect anyone upgrading from an SDK version prior to 3.2. However, if you are seeing lower respondent counts and have changed to any SDK version in your new release, please contact us for additional support.
- You've changed the position of the eligibility check in your app so that
- Some users no longer hit that point in the app.
- Users are less likely to take a survey at the point you've chosen.
- A reduction that leaves close to zero respondents could indicate that a change in your app code means your app is no longer implementing the SDK correctly. Please remember that some respondents can still be on a previous version. Check the calls to the SDK against the instructions in Getting Started.
- A change has been made in the configuration you use (invitation criteria, repeatDays, etc.) which means fewer users become eligible. Please compare your
foresee_configuration.jsonfile, both before and after your release, to see if any changes have been made.
- A change in the operating systems or devices used by your users has not been allowed for in the SDK. While every effort is made to keep the SDK up to date with the latest technology, earlier versions of the SDK are likely to contain compatibility issues. Please be sure to upgrade to the latest version of the SDK for each new release.
This is a known issue in Android's WebView widget. When a strict mode policy is specified and a web page is loaded in a WebView client, a StrictMode policy violation error may appear in the logcat on some devices. You can try tweaking your strict mode policy settings in your app to avoid this error.
Updated 10 months ago