The PageSense Android Full Stack SDK provides customization options that allow you to control how the SDK behaves inside your application. These options help you balance freshness of experiment configuration, logging verbosity, and operational stability.
SDK customization is optional. If you do not configure any options, the SDK runs with sensible defaults.
Using SDK customization, you can configure:
Polling interval for refreshing project settings
Custom logger for handling SDK logs
Log level control through your logging implementation
All customizations are applied during SDK initialization using PageSenseSDKOptions.
The SDK uses polling to refresh Full Stack project settings. You can configure how frequently polling occurs.
Default polling interval: 5 minutes
Polling interval must be 5 minutes or higher
Any value below 5 minutes is not permitted
If a value lower than 5 minutes is provided, it is automatically normalised to 15 minutes
Polling is triggered only when the app is active and follows the lifecycle rules described in the Project Settings documentation.
Polling interval is specified in minutes.
JAVA Example
KOTLIN Example
By default, the SDK logs messages using its internal logger.
If your application uses a centralized logging framework, you can plug in a custom logger to capture and manage SDK logs yourself.
When a custom logger is configured:
All SDK logs are routed through your logger
You control where and how logs are stored or displayed
Your custom logger must implement the PageSenseLogger interface and handle log messages at different severity levels.
JAVA Example
KOTLIN Example
Once polling and logging options are configured, pass the PageSenseSDKOptions object while initializing the SDK.
JAVA Example
KOTLIN Example
The SDK supports multiple log severity levels, including:
TRACE
DEBUG
INFO
WARN
ERROR
SEVERE
When using a custom logger, log level handling is fully controlled by your implementation.
This allows you to:
Suppress verbose logs in production
Enable detailed logs during development
Integrate with existing logging pipelines
Use the default polling interval unless you have a clear need to change it
Avoid aggressive polling to reduce network and battery usage
Use a custom logger in production environments
Keep verbose logging (DEBUG / TRACE) limited to development builds
If no SDK options are provided:
Default polling behavior is applied
Internal SDK logging is used
The SDK operates safely with standard defaults
Learn how to use the best tools for sales force automation and better customer engagement from Zoho's implementation specialists.
If you'd like a personalized walk-through of our data preparation tool, please request a demo and we'll be happy to show you how to get the best out of Zoho DataPrep.
All-in-one knowledge management and training platform for your employees and customers.
You are currently viewing the help pages of Qntrl’s earlier version. Click here to view our latest version—Qntrl 3.0's help articles.