PHParham HatanianPortfolio ↗
DEEPLINKX / guide

Fallbacks, installation checks, and results

Understand native, store, and browser handoffs and the limits of Boolean results.

DeeplinkX 1.5.8 · Source

For a normal action, DeeplinkX checks native availability and attempts the applicable native transport. If it cannot launch that path, fallbackToStore: true permits matching configured store actions. If no store handoff succeeds, the action's web fallback can be used when implemented. fallbackToStore defaults to false.

Future<bool> openProfileOnWebIfNeeded() => deeplinkX.launchAction(
  Telegram.openProfile(username: 'flutter', fallbackToStore: false),
);

Future<bool> preferStoreIfNeeded() => deeplinkX.launchAction(
  Telegram.openProfile(username: 'flutter', fallbackToStore: true),
);

Future<bool> tryNativeOnly() => deeplinkX.launchAction(
  Telegram.openProfile(username: 'flutter'),
  disableFallback: true,
);

disableFallback: true suppresses both store and web fallback. It does not resume the action after the user installs an app. A successful store handoff ends this launch attempt.

Reading installation checks

Use isAppInstalled when your UI has a useful installed-app decision. Native availability can be affected by missing query declarations, unsupported platforms, and provider identifiers. HTTPS links can be handled by a browser without a native installation. Distinguish loading, installed, not installed, and unsupported states where your UI exposes them.

Reading a Boolean result

true means the launch path reported a successful handoff, which can include a fallback. The destination app resolves recipients and routes, and the user completes the interaction. false means no supported attempted path reported success; show an appropriate retry or alternative in your application's UI.

Wrap launches in asynchronous error handling when your UI needs to handle unexpected platform/plugin failures. Some native launch failures become false; fallback calls can also propagate errors.

Troubleshooting sequence

  1. Verify the chosen constructor and parameters against the currently published version.
  2. Check native support for that provider on the actual platform.
  3. Confirm only the necessary scheme/package/intent declarations are present in the correct configuration file and location.
  4. Check provider credentials, identifiers, region, coordinate system, and licensing requirements.
  5. Exercise native-only, web-fallback, and store-enabled policies separately on the target device.
  6. Check the final handoff feedback and provide a retry or alternative when launching fails.

Continue reading