Sandboxed Mobile App Partner Provisioning via Protocol Handler
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing mobile app distribution systems face challenges in providing partner-specific branding and features on sandboxed operating systems, leading to overhead in development and user confusion due to multiple app versions in app stores.
Innovation Solution
A generic build of a mobile app is provisioned with a partner identifier on a sandboxed mobile operating system, allowing the app to access partner-specific features by navigating through a partner's website and redirecting to an app store, enabling partner-specific branding and authentication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If separate partner-specific versions of the app are built and distributed through the app store, then each partner receives customized branding and features, but development overhead increases and users experience confusion due to multiple app versions
Solution Approach 1:
The app is segmented into a universal core component and partner-specific configuration data. The universal app binary is distributed once through the app store, while partner-specific branding and features are delivered through separate configuration files or data packets that the app loads at runtime based on the partner identifier detected from the device environment.
Solution Approach 2:
Partner-specific configuration data is prepared and staged in advance on the device or accessible via URL, allowing the universal app to quickly provision itself with the correct partner identity upon installation. This preliminary preparation eliminates the need for multiple app versions while enabling immediate partner-specific customization.
2Adaptability or versatility
If separate partner-specific versions of the app are built and distributed through the app store, then each partner receives customized branding and features, but user experience deteriorates due to confusion from multiple search results
Solution Approach 1:
The app is segmented into a universal core component and partner-specific configuration data. The universal app binary is distributed once through the app store, while partner-specific branding and features are delivered through separate configuration files or data packets that the app loads at runtime based on the partner identifier detected from the device environment.
Solution Approach 2:
A partner identifier mechanism acts as an intermediary between the device environment and the app configuration. The app detects the partner ID through URL parameters, device identifiers, or network information, and uses this identifier to automatically load the appropriate partner-specific configuration, eliminating the need for users to manually select between multiple app versions.
3Reliability
If the app is built to run on sandboxed operating system, then system security and stability are improved, but the app cannot access configuration information indicating the specific partner
Solution Approach 1:
A partner identifier mechanism acts as an intermediary between the device environment and the app configuration. The app detects the partner ID through URL parameters, device identifiers, or network information, and uses this identifier to automatically load the appropriate partner-specific configuration, eliminating the need for users to manually select between multiple app versions.
Solution Approach 2:
The solution moves the partner identification capability from the traditional file-system dimension (which is restricted in sandboxed environments) to alternative dimensions such as network communication (URL parameters), device hardware identifiers, or runtime environment information. This dimensional shift allows the sandboxed app to access partner-specific configuration data without violating sandbox constraints.
Data Source
AI summary
A mobile app is provisioned with an identifier of a specific partner of an app provider, on a sandboxed OS on a mobile device. A link to the app provider's website containing the partner ID is received from the partner's website. The user navigates to the provider's website, which writes a cookie containing the partner ID and redirects to an app store. The app is downloaded to the mobile device, and registers itself with the OS as a protocol handler for a provider specific protocol. The app launches the provider's website, which retrieves the partner ID from the cookie, and returns a redirect to the provider specific protocol. The redirect contains the partner ID, and causes the app to execute as the registered protocol handler for the provider specific protocol. The app reads the partner ID from the redirect, and uses it to provide partner specific features.