Fallbacks

What is Fallbacks?

The Fallback System is a smart offline mechanism that ensures your No-Code screens remain accessible even when the network is unavailable or blocked. Think of it as a backup plan that automatically kicks in when your app can't reach the server.

Why Do You Need It?

In today's world, network connectivity isn't always reliable. Users might be:

• In areas with poor internet coverage
• Behind corporate firewalls
• Experiencing server outages
• In regions with network restrictions
• Without fallback, your users would see error screens or blank pages. With fallback, they get a seamless experience with locally stored screens.

How It Works

The system operates intelligently:

1. Smart Detection: Automatically detects when network or server errors occur
2. Seamless Switch: Instantly switches to local fallback screens without user intervention
3. Fast Loading: Local screens load instantly since they're stored on the device
4. Graceful Recovery: When network returns, the system automatically switches back to online mode

What Triggers Fallback?

The system automatically activates fallback for:

• Network Issues: DNS problems, connection timeouts, network unreachable
• Server Errors: HTTP 500-599 errors, rate limiting, geoblocking
• Provider Blocking: Connection refused, socket exceptions
• CDN Issues: Gateway timeouts, service unavailable

Adding Fallback to Your Project

Setting up fallback support is straightforward and requires minimal configuration. This section will guide you through downloading the fallback file from Qonversion Dashboard and integrating it into your project with either automatic or custom configuration.

Step 1: Download Your Fallback File

To download the fallback file for your No-Code screens, on the screens page, click the "Download fallback file" button.

Then choose the screens for which you want to download fallbacks and click the “Download” button, or just download a fallback file for all published screens.

🚧

Keep in mind that whenever you release new screens or modify the existing ones, it’s essential to update your fallback file as well. Otherwise, it will still have outdated screens.

Step 2: Add to Your Project

Default Setup (No Code Required)
If you place the downloaded file in your assets folder for Android or root directory for iOS with the same name as provided by Qonversion Dashboard, the fallback system will work automatically. No additional configuration needed!

Custom Setup
If you need to use a different file name or path, configure it in your app:

let configuration = NoCodes.Configuration(projectKey: "your-project-key", fallbackFileName: "my_custom_fallbacks.json")
NoCodes.initialize(with: configuration)

val config = NoCodesConfig.Builder(context, "your-project-key")
    .setCustomFallbackFileName("my_custom_fallbacks.json")
    .build()

NoCodes.initialize(config)

NoCodesConfig config = new NoCodesConfig.Builder(context, "your-project-key")
    .setCustomFallbackFileName("my_custom_fallbacks.json")
    .build();

NoCodes.initialize(config);

🚧

For iOS, you only need to specify the filename as the file will be automatically located within the app bundle. For Android, you should specify both the path and filename.

Examples:

• iOS
  • Custom name: "my_offline_screens.json"
• Android
  • Custom name: "my_offline_screens.json"
  • File in subdirectory: "assets/fallbacks/my_fallbacks.json"
  • Different path: "assets/offline/my_screens.json"

The system will automatically detect and use your fallback file, providing seamless offline experience for your users.

⚠️ Store Products Still Require Internet

While fallback screens load instantly, any screens that display App Store or Google Play products (subscriptions, one-time purchases, etc.) will still require an internet connection to fetch current pricing and availability information.

⚠️ Important Note About Android Asset Caching

When working with fallback files in your Android project, be aware that changes to asset files (including fallback JSON files) are cached by the build system. If you modify the fallback file's content, filename, or location, you must run a clean build to ensure the changes are properly included in your app. Without a clean build, the old cached version of the file may continue to be used, even if you've updated the source file.

Best Practices

• Always run ./gradlew clean after modifying fallback files during development
• Test fallback functionality after any file changes

Conclusion

The Fallback System ensures your app provides a consistent, reliable experience regardless of network conditions, making your users happy and your app more robust.