Setup the Webview to fetch from URLs for the default WSGI app and the zipcontent WSGI app via custom PathHandlers that directly invoke the relevant WSGI app #214
Currently, we are dependent on the starting of the webserver stack to resolve webview calls in the Kolibri App. Part of this is due to the complexity of invoking Python from within Java with Python for Android.
However, every call to server is handled via a WSGI server, either by the default WSGI server, or the zipcontent WSGI server. These can be instantiated and then invoked as functions on a WSGI request.
The Android Webview is customizable, in that specific paths can be delegated to have their handling rerouted to Java code.
To approach this, we would create functionality to map from the request that Android generates in this case, and create a Python compatible WSGI request object (which should just be a dict with appropriate keys).
We would then invoke via Python in Java (using Chaquopy) the appropriate WSGI server for that request and get the Python response.
We would then map from the WSGI Response to the appropriate Android response object.
One particular area for more consideration will be in returning large files, particularly where we have a streaming response. We would not want to potentially bloat memory usage by loading it all into memory, so we would want to stream that to the webview, especially in the case where the user then navigates away from the page. In this instance, we would also want to make sure we properly garbage collect and clean up the stream.
Currently, we are dependent on the starting of the webserver stack to resolve webview calls in the Kolibri App. Part of this is due to the complexity of invoking Python from within Java with Python for Android.
However, every call to server is handled via a WSGI server, either by the default WSGI server, or the zipcontent WSGI server. These can be instantiated and then invoked as functions on a WSGI request.
The Android Webview is customizable, in that specific paths can be delegated to have their handling rerouted to Java code.
To approach this, we would create functionality to map from the request that Android generates in this case, and create a Python compatible WSGI request object (which should just be a dict with appropriate keys).
We would then invoke via Python in Java (using Chaquopy) the appropriate WSGI server for that request and get the Python response.
We would then map from the WSGI Response to the appropriate Android response object.
One particular area for more consideration will be in returning large files, particularly where we have a streaming response. We would not want to potentially bloat memory usage by loading it all into memory, so we would want to stream that to the webview, especially in the case where the user then navigates away from the page. In this instance, we would also want to make sure we properly garbage collect and clean up the stream.