Closed oderayi closed 8 years ago
Thanks for your question and posting the solution :)
Yes, the normal setWebViewClient(...)
from the WebView
class can be used.
There was some effort to extend the WebView
class but at the same time keep all the behaviour and available methods the same. So you should be able to use all things that a normal WebView
exposes.
Thank you very much!
I had to do this:
webView.setWebViewClient(new WebViewClient(){
@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
view.loadUrl(url, getExtraHeaders());
return true;
}
});
to get my custom headers to show up at my backend.
Normally I would have used the webView.addHttpHeader
method, but for some reason, I did't see the custom headers at my backend.
You might have to look at it.
Thanks again!
This looks perfectly fine and is a clever solution!
Indeed, the values from addHttpHeader(...)
are only used when calling loadUrl(...)
, i.e. for your initial request. Do you feel that this should be changed?
I think the design of addHttpHeader
is pretty good because I don't have to implement a WebViewClient
callback to add custom headers.
My point is: I used it at first, but it seem not to work so I went the custom WebViewClient
way.
Calling addHttpHeader
is pretty more convenient but it seem not to be working.
Yes, the issue is that the values from addHttpHeader(...)
are only used when you call loadUrl(...)
.
This is typically your first request -- where you set the page from code.
Whenever the user follows a link or redirect then, loadUrl(...)
will not be called. You see?
So maybe we should incorporate your fix with shouldOverrideUrlLoading(...)
into this library. It seems that will help.
Setting the headers there seems to work every time. But we have to check against side effects and unexpected problems this could cause, of course.
Yeah, very good. I think it will also be nice to have a switch to enable or disable the sending of the headers on every request just in case it is not desirable in some other scenarios (overheads and what not).
In my scenario, I want to have the headers sent with every request to different the requests by device and version at my backend.
Thank you.
Great, we'll leave this issue open and implement a fix as soon as possible :)
Probably, we don't even need a switch, because looking at the method names and documentation, it really is a bug. So the behaviour that you requested should really be what everyone actually wanted in every use case.
Otherwise, one may call removeHttpHeader(...)
after the initial request to remove the headers again.
Hi, I have the same problem. I imported it in android studio, but don't recognize any function... i have a folder in my project called Android-AdvancedWebView and 3 file: Android-AdvancedWebView.iml Android-AdvancedWebView.jar build.gradle
@scheccia1 Thanks, but doesn't really look like you have the same problem described in this thread. Your problem is that you simply can't get the library working, right? Can you try copying the AdvancedWebView.java
source file to a package im.delight.android.webview
in your own source code instead?
Excuse me,I thought I had answered to other iussue where there was a logcat, and you suggested to install jar.
@scheccia1 No problem! So what about copying the source code instead of including the JAR? Does it work?
@oderayi and everyone interested: This issue has been resolved now: The fix is in https://github.com/delight-im/Android-AdvancedWebView/commit/e90fc8243ca68a23088eb4f12dd53317873d4c4c and can be used by updating your dependency (see README). Sorry for the long delay!
@scheccia1 You can include this library via Gradle now (instead of JAR).
How do you manipulate request URL before it is sent? My guess is that I need to do override a method in the WebViewClient but I have no way of doing that since you do not expose the WebViewClient.
Is there a workaround?
Thanks
EDIT: Found "setWebViewClient" method.