Troubleshooting - Common Problems
When implementing the Android SDK, it is possible that issues may arise from the particular environment in which the SDK is being used in. This section of the documentation aims to summarize and address some of the most common problems that may be encountered.
The invite isn’t showing when I expect it to
There are a number of reasons the invite may not be showing. Make sure of 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 contact the ForeSee servers before showing an invitation.
- Ensure that the invite 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 will change 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 will also reset all other SDK information including the launch count, first launch date and any significant events and as such it should not be called in the production environment.
- Make sure you are calling
ForeSee.checkIfEligibleForSurvey()in the correct place. Calls placed in an Activity’s
onCreate()method will only get 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 into the main activity’s
- Make sure you are meeting the Trigger criteria. If you require 5 launches in your configuration file, make sure the app has been launched 5 times.
Touches are not captured in some views
Instructions on how to deal with custom controls where touches are not captured are found under the heading ’Custom views that are not identified as touch-enabled by Replay’ in the Customizing Touch Capture section.
Some views stop responding to touches
Some views which implement their own OnTouchListeners have trouble receiving touches when Replay is enabled. In these cases, there are a couple of possible workarounds, which are described in detail under the heading ’Custom views that implement their own OnTouchListeners’ in the Customizing Touch Capture section.
The client’s app becomes unresponsive or jerky
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.
ForeSee has taken great care to minimize this effect, but it may still be necessary to adjust the behaviour of the recorder to suit particular situations – if the client’s app makes use of large and/or complex animations, for example.
Workarounds to this issue are discussed in detail under the heading ’Avoiding jerky or unresponsive behaviour’ in the Customizing Image Capture section.
Dalvik errors when compiling the .dex file
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 ForeSee 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, ForeSee 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 under the heading ’Using the no-deps version of the SDK’ in the Dependencies section
- 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 ForeSee SDK as the library has already been optimized.
I’m experiencing a drop in respondents after a new release
A drop in respondents can occur for a number of different reasons:
- A change in our SDK has produced a change in behaviour. For example, a fix was made in v3.2 of our SDK which means fewer users will be successfully sampled. This would affect you if you upgraded from an SDK version prior to 3.2, but 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; remember that some respondents could still be on a previous version. Please check the calls to the ForeSee SDK against the instructions in the Quick Start guide.
- 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 OSs or devices used by your users has not been allowed for in our SDK. While we strive to keep our 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.