Tag: fallback

This post explores how to use Android Intents to detect if a native app is installed. This technique is useful for web apps that also have a native app version, especially for managing push notifications. It allows developers to seamlessly redirect users to the app if it's installed or fall back to the web experience. The method involves creating a special intent URL that opens the app if present, or redirects to a specific URL with a hash fragment. By monitoring the hash change in the browser, the web app can detect if the app launch failed and proceed with web-based push notification registration. While helpful, this approach highlights the complexity of managing push notifications across web and native apps, reinforcing the argument for web-only solutions.

Custom URL schemes for launching apps have limitations: single app handling, one-way data flow, lack of fallback, and limited mobile support. A better approach is needed, one that offers user choice, developer fallback, diverse data transport, web app registration, and online/offline functionality. Android's 'intent:' URL syntax offers a good starting point, abstracting service discovery and supporting fallback URLs. I propose exploring a new 'action:' scheme or 'web+action' to bridge web and native apps, providing a unified service resolution and registration system for a richer, more integrated user experience.

Sharing content between web and apps is difficult due to platform incompatibility. Android's intent system offers a potential solution, but it lacks portability. This post explores a workaround for sharing actions, using a server-side redirect to handle intent URLs for Android users while providing a fallback to a web service like Twitter for other platforms. This approach allows cross-platform functionality while leveraging Android's intent system when available.