I have a service worker going fine in Chrome desktop and Chrome mobile, and I can tell exactly what is happening via the amazing DevTools in Chrome desktop (monitoring Chrome mobile remotely via USB). My service worker is based very closely on this example. The page reloads fine without a network connection, and from the Network tab of DevTools I can confirm that resources are being cached and served by the service worker as expected.
But I am also loading the same page in a WebView and I'm struggling to determine whether the service worker is actually registering properly and operating as it should. I can't see a way of debugging this in the same way as you can with DevTools in Chrome desktop/mobile.
What is certain is that the page doesn't reload without a connection when it is in the WebView, so some resources aren't being cached. This is despite the fact that service workers seem to be supported in WebView.
Looking around the place for possible steps or settings I might be missing to get it working as it does in Chrome, I came across ServiceWorkerController and ServiceWorkerWebSettings, but cannot find any documentation or examples for these (other than the basic docs linked). A search on StackOverflow for these terms gives zero results.
Is there a working example somewhere of a WebView that loads a page with attached service workers? Any idea how to use the above two classes... are they actually necessary?
This is only a partial answer, but hope it helps some anyways:
From what I can tell, the ServiceWorkerController is the Java implementation of ServiceWorker for WebView, which is separate from the Javascript implementation. The two do not seem to be tied together in any way.
The Java implementation is a singleton which persists and affects all WebViews in an application, and its only method is to intercept requests via shouldInterceptRequest. It is very similar to WebViewClient, the latter of which has more functionality and only affects the WebViews it is attached to (via setWebViewClient).
The link you posted does seem to indicate that WebViews do support the Javascript version of ServiceWorker. Did you by any chance miss enabling Javascript through WebSettings.setJavascriptEnabled? Also, ensure that you are targeting minimum SDK version 21 as ServiceWorkers are only enabled in Android 5.0 and higher. I am interested to know if you or anyone has managed to get a Javascript ServiceWorker functioning inside a WebView as well.
Related
I need an application which will listen when some application starts downloading files (it will be evaluated like malicious behavior).
I was trying to do this with BroadcastReceiver and Intents, when I was filtering the "android.intent.action.DOWNLOAD_COMPLETE" (in xml) and show it into Toast, when some item was downloaded to the device, but it was not working for me.
I found now that there is exist a DownloadListener, which contains a onDownloadStart(..) method.
Do you think, that this can solve my problem?
Short of a custom version of the OS, you can't. At best, you could get a subset of requests that use DownloadManager. But most downloads don't use that- they just make direct HTTP requests. There's no way to track those from another application. If you were to use a custom version of the OS you could, but to get everything you'd pretty much need to be built into the Linux networking subsystem.
The title says it all. I would like to know about everything what the WebView is asking for. Some weird limitations like not knowing about XHR POST are not acceptable. In other words, something like iOS have in NSURLProtocol. That one is application-wide hook. I don't need such level of control, WebView-instance-specific hook would be good enough. Now, i know that nothing like that exists on Android out of the box. I know about shouldOverrideUrlLoading and shouldInterceptRequest, but it's largely unusable. I need to know about requests (method, HTTP version, headers, you know) not just merely the URL strings. Moreover the intercepting is awkwardly synchronous. What happens if shouldInterceptRequest call is blocked because i need to ask a different server for related resource? It appears to me being designed just for a local resource caching.
On the other hand, i am willing to throw anything at the problem. Some kind of native library, hooking into low level internals? Extending Chromium interfaces with help of an existing project (pwnall, mogoweb)? Reflecting into the existing webkit class privates? Application-specific proxy? Any insights appreciated. I have read through two dozens of existing SO questions. They all either suggest a partial hack (like working around XHR POST deficiency with JavaScript) or it goes unresponded altogether, very often.
Try with inspeckage:
https://github.com/ac-pm/Inspeckage
It needs Xposed and root access to work. I've been able to see WebView requests from apps. Im figuring out how to recreate them with Python's requests module.
Hope that helps.
If I understand your goal - try:
WebView.setWebContentsDebuggingEnabled(true);
Open Chrome and go to url chrome://inspect/#devices
for details:
https://developers.google.com/web/tools/chrome-devtools/remote-debugging
https://developers.google.com/web/tools/chrome-devtools/remote-debugging/webviews
(re-post from the PG google group)
I know there's been a lot of conversation on this in the past, but I've been researching it for the past few days and couldn't seem to find a definitive answer (or even what it would entail).
I was wondering how plausible it would be to embed a snapshot build of the Chrome webview (or even the Gecko webview) into a Phonegap app and to use that in place of the native webview that PhoneGap uses. The problem is twofold - 1) Android's native browser/webview is terrible and 2) Each phone seems to have idiosyncratic bugs/differences, which having one set snapshot to build against would fix.
I've seen answers ranging from "Oh, yeah, just build the source and drop it in" to "You'd need a full team of Java devs to hack the PhoneGap API core to get it to work". Does anyone have an answer of what it would entail, how much time it would take, if it's even plausible, etc? I suppose the biggest concern is - given we can get a snapshot build of the Chrome webview, does that break any of the connections to the PhoneGap APIs? Are they tied specifically to the native webview?
Any and all thoughts are appreciated. Thanks!
Chrome has the ability to be embedded by use of the Content Module. In theory (I have never done it) you can build this and embed it into your Application and use that instead of a WebView - it has the advantage of being an up to date Chrome and multi-process. It loses value in that it can't be used pre-Jellybean.
What are the key differences between Android, iOS and Blackberry OS in terms of level of accessibility by application developers (i.e. access to the video input, sound input, phone functionalities, to which extent, etc.)?
PS: Assume latest version of each OS.
EDIT: Can someone turn this into a wiki so we can compile answers from people that don"t necessarily have experience in all 3 plaforms.
I'm not familiar with BlackBerry, but on Android and iOS you can access just about anything. Until recently iOS had some restrictions about camera access (see this), but I belive those have been solved. Because Android is open-source, you can theoretically go as deep as you want as far as accessing the hardware, but you may or may not be able to get any deeper through the standard Android API than you can through the iOS API.
On Android, you can do a lot more to override default functionality. For example, you can create your own launcher screen or phone application. The iOS approval process wouldn't allow these kinds of applications.
API hardware access really isn't an issue on either platform, the bigger concern is overriding default software (almost never possible in iOS) and what types of applications iOS allows.
Each platform has its own nice and bad parts. I have been working on both Android and BB. I wish I could take only nice parts from both to create a platform of a dev dream! :)
For instance, I could take these features from BB:
The greates feature I like in BB is the simplicity of the application architecture - you can always count on your main UIApplication instance - OS never kills it.
Also I do like the simplicity the Dialog class provides - it is very easy to implement business logic related to user choice - while Dialog screen is shown the code execution just stops and waits for user input.
From Android I'd take the following:
Network communication. On BB this is a real nightmare (BES, BIS, WIFI, Direct TCP without APN, Direct TCP with APN, WAP, WAP2, Unite - who's next? :)).
For file manipulations you just use a native/usual Java API.
Nice looking UI components are available right out of the box.
I should add I'm not happy with GPS related stuff on both platforms, however maybe it is due to GPS hardware limitations rather than API creators.
Thanks!
BlackBerry is a pain, once I made a project for it (the JDE version was 4.7 back then) and it didn't had an ArrayList. WTF?
I have a web application to be hosted on android device. I am currently using the emulator available with android sdk. My application will serve both static as well as dynamic data. I am currently using jetty version 6.1.22. I wanted to ask what will be a better option to be used.
1. Jetty webserver with stripped off code.
2. I-Jetty.
My application uses following features-
ResourceHandler to serve static resources.
A Generic servlet to serve synchronous data requests.
An extension to CometServlet to serve asynchronous data requests.
I am looking forward to following criteria for comparison.
Application size. Size of apk which will contain the code.
Memory and CPU usage under a maximum load of 30 requests/sec. These are short bursts which occur very few times in app-life cycle. The average load would be approximately 5 requests/sec.
Ease of maintenance. Including important upgrades of Jetty in application.
Any other side-effects which I probably am missing out at.
I too have been searching for information on embedding the i-Jetty server in an application. Like the original poster, I need to serve both static and dynamic resources. I found the following post to be a helpful start:
http://puregeekjoy.blogspot.com/2011/06/running-embedded-jetty-in-android-app.html
I notice that in searching for answers about embedding a web server in an Android app that many responders, rather than providing a helpful answer, chide the original poster for wanting to do such a thing "in a phone". They then proceed to give all the reasons not to. There are more Android devices out there than just phones. My project involves just such a device. Thanks for all the helpful answers on this and other sites that guided me in my efforts. I hope the link I provided helps other searchers.
There are good reasons for embedding a web server in your app. May not be the best way but you have to do it when Android ties your hands. An example is when you want to decrypt video on the fly at runtime and use the media player to play it. Android media player does not allow me to feed it an in-memory stream as would come from a decryption pipe.
In this case, one solution (help me think of others please!) is to embed a web server that would serve up the stream - because Android does accept a stream from a URL!!
The other solution would be port some native library over and write a JNI interface to it. Too much work and unstable at best.
The point is, there are valid enough reasons out there.
It you need to decrypt video or serve content, you might consider just writing a simple web server yourself that can specifically handle your application's needs without any bloat. Adding an existing web server or web container might be more than you need. It very much depends on your application's needs though.
I have a web application to be hosted
on android device.
Why? It won't be usable, except maybe on a WiFi LAN. It won't be able to run terribly long, because services cannot run forever. Etc.
Whatever technical problem you think you're solving by using a Web server on Android can be better solved by other means.
I wanted to ask what will be a better
option to be used. 1. Jetty webserver
with stripped off code. 2. I-Jetty.
Arguably "neither", not only due to the technical issues, but that Greg Wilkins (creator of Jetty) does not like Android much. Of the two, though, i-jetty is at least regularly tested on Android.
Memory and CPU usage under a maximum
load of 30 requests/sec. These are
short bursts which occur very few
times in app-life cycle. The average
load would be approximately 5
requests/sec.
While running, battery life will suck, because you are going to keep the CPU and WiFi running all of the time to support the Web server, let alone the load.