Headless WebView

[Serhii Virchenko]

Hello, android-webview-dev team!

For reasons, I have to explore an idea of a headless WebView. 
It has to be done in the scope of an sdk, so the only context available is application one. Attempt to attach the webview to the window is out of question, unfortunately, because it creates  either set of unsolvable problems or very invasive and intrusive sdk. 

The plan is to create a webview, but never attach it a window. And use it as a crude replacement for a socket connection in this particular use case. 
The webview loads a page with some js runtime, that contains business logic. The sdk communicates some native calls to the js runtime, the page responds with some events. Both calls and events are asynchronous. The headless webview remains headless for the whole cycle, and other webviews, conventionally attached and detached to a widnow, can coexist at the same time. 
I know this is not the best solution by a big margin, and I know js bridge is obsolete and unsafe. I'm not the shot caller, and this question is part of my effort to turn the tides. 

My line of thought is: it's called a WebVIEW, and being attached to view hierarchy is part of it's expected lifecycle. But what happens when it's not attached? I barely can find any information on that. I understand that a quote from android developers WebView documentation: "WebView objects allow you to display web content as part of your activity layout, but lack some of the features of fully-developed browsers" implies without attaching to a window all bets are off. But it's a feeling and vague logic, not an evidence. 

Most likely the functionality will be implemented this way regardless, because the POC I created kinda works.
My question is what are the risks?
At the very least I want to warn the web page developers and management of what risks\pitfalls to expect with this approach. Unfortunately, I don't know anything about the webpage being loaded, i.e. js version, frameworks, etc. But I can try gather any information necessary for the best recommendation. 

Thank you in advance android-webview-dev team!
Best regards,
Serhii
P.S: Here is a class which demonstrates the idea in a nutshell

internal class HeadlessWebViewAsService(
private val context: Context,
) {

private var webView: WebView? = null

private val bridge: Any = object : Any() {
@JavascriptInterface
fun sendEvent(event: String) {
// do stuff according to the received event
}
}

fun start(url: String) {
disposeWebView()
webView = WebView(context).apply {
settings.apply {
setWebContentsDebuggingEnabled(true)
javaScriptEnabled = true
}
addJavascriptInterface(bridge, "NativeAppInterface")
webViewClient = object : WebViewClient() {
override fun onPageFinished(view: WebView?, url: String?) {
super.onPageFinished(view, url)
inject(pingInjection)
}
}
}
webView?.loadUrl(url)
}

fun stop() {
disposeWebView()
}

fun inject(js: String) {
Handler(Looper.getMainLooper()).post {
webView?.evaluateJavascript(js, null)
}
}

private fun disposeWebView() {
webView?.destroy()
webView = null
}

private val pingInjection = """
(function() {
function sendPing() {
if (window.NativeAppInterface && NativeAppInterface.sendEvent) {
NativeAppInterface.sendEvent('pingEvent');
}
}

sendPing();
setInterval(sendPing, 1000);
})();
""".trimIndent()
}

[Nate Fischer]

Hey, thanks for writing in to discuss the project idea. We've spoken with other app developer teams doing something similar.

The short summary is: this will mostly work, but there are some risks and corner cases. This is not fully supported in the way that we support actually using WebView on-screen to show websites.

There are three main things to consider:

• WebView is really intended to be launched with an Activity context. Some of our UI features depend on this. The risk is that your WebView will crash in some edge cases depending on user interaction or web page behavior.
• There may be more memory-efficient alternatives.
• Plus, you'll have all the "usual" tradeoffs with WebView usage. For example. there are certain web platform features which aren't implemented in WebView.

The first point is the biggest risk. We don't catalog all the cases where this can crash, but you can try searching in chromium codesearch to get a feel for this. Here's a link to get you started: https://source.chromium.org/search?q=%22activity%20context%22%20-f:chrome%2F%20lang:java&ss=chromium.

In terms of memory, keep in mind that WebView is designed to show web pages, so we will have some overhead because the software expects to be doing that. You also need to consider the lifetime of whichever process is using WebView: WebView's code will stay in memory for the full lifetime of the process, so you should really try not to use WebView from a long-lived background process because this puts quite a bit of memory pressure on the device. If you're open to considering other libraries, then Cronet is a great standalone networking library and JavascriptEngine is a great library for executing JS. Those two libraries are both built on top of chromium code, but using that pair of libraries would be more memory efficient than using a full WebView instance. But you may decide that those aren't sufficient for your use case or you prefer the simplicity of using just WebView.

Once again, I have to emphasize that we don't support this. You can try it and it will mostly work, however we can't necessarily commit to fixing bugs in cases where this breaks. You may find that a future WebView update suddenly breaks this type of headless use case. In that situation, we may not be able to triage/fix the bug and you would need to figure out your own workaround for your app.

Nate Fischer | Software Engineer | ntf...@google.com

--
You received this message because you are subscribed to the Google Groups "android-webview-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-webview...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/android-webview-dev/cbb23daa-bc8d-4ca8-aa73-777e520021f3n%40chromium.org.

[Serhii Virchenko]

Thank you very much for the help!