Mobile SDK Dynamic Workflow Rendering Without App Updates
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional mobile applications have limited workflows hard-coded into them, requiring updates or new versions to implement changes, which is inefficient and inflexible, especially for complex functionalities or transactions like CIP.
Innovation Solution
A Software Development Kit (SDK) on mobile devices dynamically renders workflows by communicating with an external server to obtain and interpret programming code templates, allowing mobile applications to update workflows without new versions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If workflows are hard-coded into mobile applications, then the application structure is simple and stable, but the workflows cannot be updated dynamically without releasing new versions
Solution Approach 1:
The patent divides the workflow system into two independent parts: (1) the mobile application that provides the user interface and basic functionality, and (2) the external server that stores and manages workflow definitions. This segmentation allows workflow updates to occur on the server without requiring app store releases, resolving the contradiction between adaptability and structural stability.
Solution Approach 2:
The patent introduces an external server as an intermediary between the mobile application and the workflow definitions. The server acts as a mediator that provides workflow data to the application dynamically, enabling workflow updates without modifying the application code or requiring new versions to be deployed.
2Productivity
If new versions of mobile applications are released to update workflows, then the workflows can be updated, but the update process is time-consuming and requires app store approvals
Solution Approach 1:
The patent implements preliminary action by pre-defining workflow templates and logic on the external server before they are needed. When a workflow update is required, the server can immediately provide the updated workflow definitions to active applications without waiting for app store review and deployment, thus eliminating update delays.
Solution Approach 2:
The external server intermediary enables rapid workflow updates by allowing direct deployment of workflow changes to the server, which then automatically makes them available to all connected applications instantly, bypassing the traditional app store release process and significantly reducing update time.
3Adaptability or versatility
If mobile applications support only a limited set of native workflows, then the application is simpler to maintain, but the application lacks capability to handle complex transactions
Solution Approach 1:
The patent implements universality by creating a platform where a single mobile application can support multiple different workflows by retrieving them from the external server. The application maintains a universal interface that can adapt to various workflow types (CIP, KYC, onboarding, etc.) without needing separate code for each, thus increasing workflow variety while maintaining functional simplicity.
Solution Approach 2:
The external server acts as an intermediary that provides complex workflow logic and definitions to the mobile application. This allows the application to handle complex transactions and diverse workflow types without embedding the complexity within the application itself, maintaining a clean separation between simple client and sophisticated server.
Data Source
AI summary
A first request to conduct a transaction via a mobile application is received from a user of the mobile application. In response to the receiving of the first request, a first portion of a transaction flow is rendered on a graphical user interface of the mobile application. A determination is made that the mobile application is unable to render a second portion of the transaction flow. In response to the determining, a second request is sent to a server to provide details for the second portion of the transaction flow. After the sending, computer programming code is received. The computer programming code corresponds to the details of the second portion of the transaction flow. Based on the received computer programming code, the second portion of the transaction flow is rendered for the mobile application on the mobile device.