Enhanced WebView API

[damonkohler]

From @GoogleCodeExporter on May 31, 2015 11:28

What should be supported?
Expanding the WebView control API with finer control options.

Individual problem: Currently, "refreshing" the webview means executing 
WebViewShow() again so that the present webview is destroyed, and a new one 
created in its place. This breaks the menu display (the new webview does not 
contain the old menu).

Examples of new functionality that would be individual API functions:
1. WebViewShow(filename) and WebViewShow(source):
 - Distinguish between loading filenames and straight HTML source
 - Since both arguments are strings, might have to either use key-value pairs as arguments (does this violate the present style?) or use two separate functions: WebViewShowFromFilename or WebShowFromSource or similar.
 - Alternately, use several function calls to set up and then display the WebView, reflecting current behavior of the various dialog() functions.
 - Current behavior: WebViewShow takes a filename, then internally opens the file, reads the source, and passes that into the WebView as source.
 - Benefit: Allow the interpreter to form the source code and pass directly, rather than the present behavior of interpreter writing file to disk, SL4A loading from disk
 - Benefit: Loading from filename means that refreshing the page can be done without additional arguments (just reload page from disk), while starting from source means that refresh page requires a source code argument, either option makes sense depending on what is going on. Loading from filename also allows the REFRESH timer/event functionality in HTML to actually properly load the page (not possible now)

2. WebViewRefresh(<optional source>)
 - Allow the current page's code to be replaced by different raw code, or refresh from file.
 - Benefit: If the interpreter code internally maintains all data in the HTML,then it makes sense to simply reload the source directly, and avoid issues with keeping files up-to-date whenever an internal data change is made.

Adding these appears to require either passing back some kind of WebView 
identifier to interpreter, or assuming that a single execution of SL4A is using 
a single WebView instance. I think the first option is more functional, but 
maybe unnecessary.

There are a lot of other WebView API options in Android that would be helpful 
to expose to the interpreters. Is there any clever way of programmatically 
getting the list of available Java API calls and automatically mirroring those 
to the interpreters?

Original issue reported on code.google.com by james.bu...@gmail.com on 5 Feb 2011 at 9:54

Copied from original issue: damonkohler/android-scripting#514