Preface
There will be some problems when developing the loading effect of webview. Here we record some common problems and design a set of loading solutions to solve related problems.
1. Selection of loading
The reason for developing loading effect is that when the webview loads the page, it sometimes takes time, resulting in no display of content and no prompts, and the effect is not very good. Therefore, you need to add loading effect in the place where the webview is used. In fact, the better experience is to add EmptyView. I mainly use loadingView as an example.
There are basically two ways to develop loading. One is to use window, that is, the pop-up windows such as Dialog. The pop-up window pops up when loading and close the pop-up window after loading. Some people may encapsulate some loading pop-up windows and reuse them here.
The advantage of this method is that if you encapsulate it, it can be reused directly, saving a lot of code. The disadvantages are also obvious. Whether the pop-up window is in a situation where interaction is not allowed. If there is a problem with this process, it will never be possible to interact with the page.
Another method is to directly overwrite a LoadingView on the upper layer of the webview. The webview inherits FrameLayout, which means you can directly addView.
The advantage of this method is that the above problem will not occur, because the page where my webview is located is closed, its loading will disappear along with it, and the display effect will be better. The disadvantage is that you may do some special webviews separately, which leads to more code.
It is not said which method is better to implement, it mainly depends on the usage scenario and specific requirements.
2. Issues about loading display timing
The idea of loading is to display it at the beginning of loading and close it after loading is completed. Then it is more important to choose the starting time and ending time.
Most people will directly use the onPageStarted callback of WebViewClient as the starting point and use the onPageFinished callback. They think it's enough to just write this way, it doesn't matter, anyway, the webview will take action.
This idea can indeed be displayed normally under normal circumstances, but what about in a weak network? What about in a complex network environment? Some people may also encounter some such situations. The loading show is written in onPageStarted. When loading, the screen will be white-screen before starting to display loading. However, the white screen time is very short, so it doesn't matter. But have you ever thought about what this white screen will be enlarged into in a complex and problematic network environment in a normal network environment?
This loading process is actually roughly divided into two stages, from loadurl to the onPageStarted of WebViewClient and from onPageStarted to onPageFinished from WebViewClient
So my approach is to start loading when loadurl, rather than the onPageStarted callback of WebViewClient.
This is the beginning time, and there will be no problem with the end opportunity. It may be true. Sometimes you will find a phenomenon that after loading, your H5 content and loading will be displayed at the same time for a period of time before closing loading (I encountered it a few years ago. The test was not reproduced when I wrote this article. I don’t know if the version update fixed this problem)
So how should I solve this problem?
When encountering this problem, it means that the callback time of onPageFinished is after the page is loaded, so it is not trustworthy. We know that in addition to this method, BaseWebChromeClient also has a method onProgressChanged to indicate the loading progress. Of course, you will have problems with this progress, because it will not callback 100 to you every time, and it may sometimes give you 96, and it will be gone. My previous approach was to double judgment, to determine whether the progress is returned first >85 or onPageFinished is called first. As long as there is a call, I will close loading
3. Experience optimization
Of course, it is not enough to handle the timing of the display closing. Think about what happens if you show loading in loadurl. That's right, even if the network speed is fast and the page lets loading flash by, the experience caused by this is very bad, so we need to do a delay display. My personal habit is to delay by 0.5 seconds. Of course, delayed display will also have delayed display problems, such as what to do if you close the page when the delay is 0.3 seconds, and I can't let it display after 0.2 seconds.
Say it shows, then close it. Whether it is the onPageFinished method or onProgressChanged, can you guarantee that it will definitely have a callback? These codes are not controllable. Will there be situations where neither exceptions nor callbacks are thrown. Maybe some people say no. I have used it for so many years and have never had such a problem, but since it is not our controllable code, it is absolutely correct to add a layer of insurance.
In fact, this is also simple. Just set the logic of timeout. I personally define the 10-second timeout time. If loading is not closed after 10 seconds, I will manually close and display the error page of the emptyview. This timeout time is quite practical. The above mentioned is the choice of loading. If your loading is made into a view, even without this logic, it will not have much impact. At most, it will keep turning. However, if you are made by Windows, without timeout processing, and no callbacks, then your window will keep showing the page stuck.
4. Final design effect of loading
Based on the above situation, I wrote a demo. First of all, I chose to use the view based on the view, so I need to write a custom view.
public class WebLoadingView extends RelativeLayout {
private Context mContext;
// 0: Normal state; 1: loading status; 2: Display loadingview status private AtomicInteger state;
private Handler lazyHandler;
private Handler timeOutHandler;
public BaseWebLoadingView(Context context) {
super(context);
init(context);
}
public BaseWebLoadingView(Context context, AttributeSet attrs) {
super(context, attrs);
init(context);
}
public BaseWebLoadingView(Context context, AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
init(context);
}
private void init(Context context) {
= context;
state = new AtomicInteger(0);
lazyHandler = new Handler(());
timeOutHandler = new Handler(());
initView();
}
private void initView() {
(mContext).inflate(.demo_loading, this, true);
}
public void show() {
if ((0, 1)) {
(new Runnable() {
@Override
public void run() {
if ((1, 2)) {
setVisibility();
}
}
}, 500);
(new Runnable() {
@Override
public void run() {
close();
}
}, 10000);
}
}
public void close() {
(0);
setVisibility();
try {
(null);
(null);
} catch (Exception e) {
();
}
}
}
The code should be easier to understand, so I will not introduce it too much, and then display it in the loadurl of the custom webview
@Override
public void loadUrl(String url) {
if (webLoadingView != null && !(url) && ("http")) {
();
}
(url);
}
When writing this, there is a place to pay attention to, that is, this loadUrl will be executed when adjusting the method, so it is necessary to judge that loading is displayed when loading the web page.
Summarize
Let’s summarize a few key points. The first one is for third-party things (webview is also similar to third-party, and there are really many pitfalls). We cannot control its processes, or we cannot control its life cycle, so we need to encapsulate a set of process logic to make it convenient for the caller to use.
The second problem is the version problem. There may be different effects reflected in different versions, which need to be paid attention to.
If you want to perfectly solve these loading-related problems, the best way is to look at the source code. You know how it is implemented and why there is still a period of time before onPageStarted appears. Then look at the source code between loadUrl and onPageStarted callbacks and see what operations it does. I personally didn't read the source code, so I can only talk about it briefly here.
The above is a detailed discussion on the usage effect of the Loading of Android Webview. For more information about Android Webview Loading, please follow my other related articles!