Dynamic Logic Shifting Between Client and Server
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing web-based applications on mobile devices face challenges with battery power, network bandwidth, and latency, as current solutions are inflexible and costly, requiring upfront decisions on client-side or server-side execution of application logic without the ability to dynamically adjust based on real-time conditions.
Innovation Solution
A system that automatically detects deficiencies in mobile devices and dynamically shifts application logic between client and server, using a stub generator, function processor, and client stub to seamlessly and transparently move execution based on conditions such as battery status, without requiring profound knowledge of device-specific APIs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Use of energy by moving object
If complex calculations are shifted to server-side, then battery power consumption on mobile device is reduced, but server infrastructure costs increase
Solution Approach 1:
The system dynamically shifts application logic execution between client and server based on real-time conditions such as battery status, network availability, and device capabilities. The stub generator creates platform-specific code that automatically determines whether to execute functions locally or remotely, allowing the system to adapt its architecture dynamically rather than being fixed in one direction.
Solution Approach 2:
The system changes operational parameters by monitoring device state (battery level, network connection, CPU load) and adjusting the execution location accordingly. When battery level is high and network is available, more functions are executed on the server; when battery is low or network is unavailable, functions are executed locally on the device.
2Device complexity
If application logic is shifted to server-side, then device complexity is reduced, but adaptability to different conditions deteriorates
Solution Approach 1:
The system employs dynamic condition checking where the stub code continuously monitors device state and adjusts execution location in real-time. This allows the system to maintain simplicity in terms of code structure while achieving high adaptability through runtime condition assessment and dynamic decision-making about where to execute functions.
Solution Approach 2:
The stub generator and stub code act as intermediaries between the application logic and the execution environment. The stub code embedded in platform-specific code serves as a mediator that handles the complexity of condition checking and execution location determination, allowing the main application logic to remain simple while the intermediary handles adaptability concerns.
3Speed
If application logic is shifted to server-side, then client-side processing speed is improved, but network bandwidth consumption increases
Solution Approach 1:
The system dynamically adjusts the balance between client-side and server-side execution based on network conditions. When network bandwidth is abundant and latency is low, more functions are executed on the server to improve client-side speed. When network conditions deteriorate, the system shifts execution back to the client to avoid excessive bandwidth consumption and latency issues.
Solution Approach 2:
The system implements feedback mechanisms where the stub code monitors network performance metrics (bandwidth availability, latency, connection stability) and uses this feedback to adjust execution decisions. This closed-loop control allows the system to optimize the trade-off between processing speed and network resource consumption based on real-time conditions.
Data Source
AI summary
A system for condition-based application logic shifting between a client and a server uses a stub generator, a function processor, and a client stub. Both the stub generator and the function processor are located in the server and the client stub is generated by the stub generator. Normally an application function's execution occurs on the client. The client stub determines whether or not a client shift condition (CSC) exists for shifting an application function's execution from the client to the server when the CSC does exist, and shifting the application's function back to the client when it is determined that the CSC does not exist (or no longer exists).